> 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/the-soa-framework-for-sdvs.md).

# The SOA Framework for SDVs

The SOA framework for SDVs encompasses both **on-board** and **off-board** environments, integrating **QM** (Quality Management) environments for agile application development and **ASIL** (Automotive Safety Integrity Level) environments for first-time-right safety-critical applications.

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

Here’s how the SOA Framework for SDVs is structured:

**1. Cloud Runtime**

At the heart of the off-board system, the **cloud runtime** enables scalable and agile development for microservices. It ensures seamless integration with on-board systems, allowing continuous updates, data processing, and application enhancement in a centralized environment.

**2. Vehicle-to-Cloud API**

The **vehicle-to-cloud API** acts as a bridge between on-board and off-board environments. It facilitates communication between vehicle systems and cloud platforms, ensuring that data and functionalities flow bidirectionally in a secure and efficient manner.

**3. Container Runtime**

To execute SDV functions on-board, a **container runtime** is essential. It provides the modular infrastructure needed for running microservices independently, ensuring scalability, fault tolerance, and agility. The container runtime supports parallel development and efficient deployment, allowing for quicker updates and testing.

**4. Signal-to-Service APIs**

At the core of SOA, **signal-to-service APIs** transform raw signals from sensors, actuators, and ECUs into higher-level services. This abstraction layer simplifies interaction with complex vehicle systems, enabling application developers to focus on creating functionalities without worrying about the underlying hardware complexity.

**5. Signal-Oriented Embedded Runtimes**

Embedded runtimes leverage signal-oriented designs to optimize real-time performance and ensure smooth operation of on-board systems. These runtimes interact with the signal-to-service APIs and containerized microservices, orchestrating critical processes in SDVs with minimal latency and high reliability.

## **On-Board SOA Building Blocks**

* **Endpoint ECUs**: These lower-level control units connect to sensors and actuators through local bus networks. They transmit data to zonal controllers.
* **Zonal Controllers**: Higher-end ECUs that host **signal-to-service APIs**, creating a bridge between hardware and software services.
* **Microservices**: SOA enables the development of lightweight microservices:
  * **Basic Microservices**: Simple, standalone services performing specific tasks.
  * **Composite Microservices**: Higher-order services that combine multiple basic services into more complex functionalities.

## **End-to-End Service Chains**

SOA supports the creation of **end-to-end service chains** that span on-board and off-board environments:

* In the **cloud**, microservices can access vehicle functions through vehicle-to-cloud APIs, interacting with sensors and actuators at the signal level via signal-to-service APIs.
* On-board, these APIs enable agile development for QM functionalities, with future support planned for ASIL A and B functionalities.

## **The Future of SOA**

SOA enables seamless communication across the vehicle, cloud, and external ecosystems, driving flexibility, scalability, and safety. As the architecture evolves, signal-to-service APIs will increasingly support safety-critical applications, pushing the boundaries of **software-defined vehicles**. This convergence of on-board and off-board services is central to building robust and future-proof SOA frameworks.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://www.sdv.guide/sdv101/part-c-building-blocks/building-blocks-of-an-sdv/service-oriented-architecture/the-soa-framework-for-sdvs.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.