> 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="https://392531723-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FRqBHYU6DD895ydQm5PcS%2Fuploads%2Fx5lpZCdHq5EkccESqGNS%2Fimage.png?alt=media&amp;token=f71b4dfa-2e69-4a3f-a833-a8ed794760b6" 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="https://392531723-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FRqBHYU6DD895ydQm5PcS%2Fuploads%2FJ5BMvpiQmLCd2oHRywxs%2Fimage.png?alt=media&amp;token=5f1f4edc-ba56-4b73-b26d-4d5fd1dea9cf" 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="https://392531723-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FRqBHYU6DD895ydQm5PcS%2Fuploads%2FjQKYZ7Njr6lbubGaN0t2%2Fimage.png?alt=media&amp;token=1a25c578-9b8d-495a-908b-8e791b5061b7" 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="https://392531723-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FRqBHYU6DD895ydQm5PcS%2Fuploads%2FtbE9vyjOmeOkkUJWuDy8%2Fimage.png?alt=media&amp;token=8531f950-8278-4a25-97b2-44df3ed1de00" 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.