SDV Guide
digital.auto
  • Welcome
  • SDV101
    • Part A: Essentials
      • Smart Phone? No: Habitat on Wheels!
      • Basics: What is a Software-defined Vehicle
      • MHP: Expert Opinion
      • Challenges: What sets automotive software development apart?
      • SDV Domains and Two-Speed Delivery
    • Part B: Lessons Learned
      • Learnings from the Internet Folks
        • Innovation Management
        • Cloud Native Principles
          • DevOps and Continuous Delivery
          • Loose Coupling
            • Microservices & APIs
            • Containerization
            • Building Robust and Resilient Systems
      • Learnings from the Smart Phone Folks
    • Part C: Building Blocks
      • Foundation: E/E Architecture
        • Today`s E/E Architectures
        • Evolving Trends in E/E Architectur
        • Case Study: Rivian
      • Standards for Software-Defined Vehicles and E/E Architectures
      • Building Blocks of an SDV
        • Service-Oriented Architecture
          • The SOA Framework for SDVs
          • Container Runtimes
          • Vehicle APIs
          • Example: Real-World Application of SDV Concepts
          • Ensuring Functional Safety
          • Event Chains in Vehicle SOAs
          • Vehicle SOA Tech Stack
        • Over-the-Air Updates: The Backbone of Software-Defined Vehicles
        • Vehicle App Store: The Holy Grail of Software-Defined Vehicles
      • Summary: Building Blocks for Software-Defined Vehicles
    • Part D: Implementation Strategies
      • #DigitalFirst
      • Hardware vs Software Engineering
        • The Traditional V-Model in Automotive Development
        • Agile V-Model, anybody?
        • Key: Loosely Coupled, Automated Development Pipelines
        • The SDV Software Factory
      • Implementing the Shift Left
        • Simulation and Digital Prototyping
          • Early Validation: Cloud-based SDV Prototyping
          • Detailed Validation: SDVs and Simulation
        • Towards the Virtual Vehicle
          • Case Study: Multi-Supplier Collaboration on Virtual Platform
          • Long-Term Vision
        • Physical test system
        • De-Coupled, Multi-Speed System Evolution
        • Continuous Homologation
        • Summary and Outlook
      • Enterprise Topics
        • Variant Management
        • Engineering Intelligence
        • Enterprise Organization, Processes, and Architecture
        • Incumbent OEMs vs EV Start-ups
  • SDV201
  • ./pulse
    • SDV Enabling
      • SDV Business & Investment Enablement
      • SDV Culture
    • Lean Sourcing
      • LeanRM
        • Why so many Requirements?
      • SCM for SDVs
    • SDV Systems Engineering
      • LeanSE
      • SDVxMBSE
    • Digital First
    • Loose Coupling
      • API-first
      • Freeze Points
    • Automation and Engineering Intelligence
    • Continuous Homologation
    • Build / Measure / Learn
    • Community & Meetups
  • Glossary
Powered by GitBook
On this page
  1. SDV101
  2. Part C: Building Blocks
  3. Building Blocks of an SDV
  4. Service-Oriented Architecture

Example: Real-World Application of SDV Concepts

PreviousVehicle APIsNextEnsuring Functional Safety

Last updated 8 months ago

SDV Guide

  • Legal Notice
  • Disclaimer
  • Privacy Policy

(c) 2025 Dirk Slama

CtrlK

So how does all of this play together? How are container runtimes and vehicle APIs helping us build a service-oriented architecture (SOA) for Software-Defined Vehicles (SDVs)?

In the following, we will be looking at two use cases: An app for a mobile mechanic performing repairs on-site, and a passenger welcome app. Both will share an API to open the vehicle door, i.e. first unlocking the door and then physically opening the door via a motor.

Let’s see how the components interact. We have an off-board cloud runtime, an on-board edge container runtime, and deeply embedded signal-oriented environments in the vehicle. Connecting these elements are two key API layers: the vehicle-to-cloud API for external communications and the on-board hardware abstraction layer (HAL), possibly utilizing standards like COVESA VSS.

Now, consider a real-world use case involving mobile maintenance or repair services, similar to what Tesla and other EV startups offer. Suppose a service technician needs to access a vehicle for maintenance, even when the owner is not present. Using a mobile app, the technician can send a request to unlock the car remotely. The cloud runtime processes the request through the vehicle-to-cloud API, which relays the command to the on-board container runtime. The appropriate service is triggered, and the car door unlocks and opens.

Next, consider another use case: a passenger welcome sequence designed to enhance the emotional connection between the car and its owner. When the driver approaches the vehicle, the car recognizes the owner through an on-board app. Using stored driver preferences, the vehicle automatically adjusts the seat, triggers a light sequence, and opens the door—all through the same on-board API.

What makes this architecture efficient is that both use cases reuse the same door control API. In the first scenario, the API is accessed externally by the service technician’s mobile app, while in the second, it’s triggered internally by the on-board application running the welcome sequence. This demonstrates the power of modularity, service reusability, and API-driven development in building scalable and feature-rich SDV platforms.