> For the complete documentation index, see [llms.txt](https://www.sdv.guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.sdv.guide/sdv101/part-c-building-blocks/building-blocks-of-an-sdv/service-oriented-architecture/example-real-world-application-of-sdv-concepts.md).

# Example: Real-World Application of SDV Concepts

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.

<figure><img src="/files/Ejx1BtIfwcxSBgUiqJZ0" alt=""><figcaption></figcaption></figure>

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**.

<figure><img src="/files/7XJn7xZGImyarmDjlDqO" alt=""><figcaption></figcaption></figure>

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.

<figure><img src="/files/yS4rGobGLOx6Ay0pTCR8" alt=""><figcaption></figcaption></figure>

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**.

<figure><img src="/files/2BDnOamAnhaAfTgpVvCW" alt=""><figcaption></figcaption></figure>

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.