Why SOA is taking the lead in SDVs
Software-defined vehicle programs scale features across domains, ECUs, and product generations. This makes signal-centric integration increasingly expensive. Every new feature adds more “wiring”: more signals, more routing rules, more integration effort, and more opportunities for hidden coupling.
At the same time, the underlying vehicle topology is changing. Instead of dozens of function-specific ECUs talking mostly over classic buses, many programs move toward a central compute approach with one or more HPCs (High-Performance Computers) for software-heavy functions, combined with a zonal architecture.
- Zonal controllers sit close to sensors/actuators (short wiring, local I/O aggregation).
- A high-bandwidth backbone (often Ethernet) connects zones to the HPC(s).
- Software functions can be consolidated, moved, or updated without redesigning the entire communication matrix.
With zonal controllers and HPCs, function placement becomes fluid. If your interfaces assume a fixed ECU location, they will hinder functional clustering, redeployment, or OTA-driven evolution. SOA shifts integration from “where” to “what”: consumers bind to service contracts, so software can evolve independently of the underlying zones/HPC topology.
Named programs moving toward a central compute appraoch include: BMW’s Neue Klasse, Volkswagen/CARIAD’s High-performance E/E architecture, Stellantis’ STLA Brain, Volvo’s “Superset” tech stack, and Mercedes-Benz’s MB.OS chip-to-cloud stack.
From signals to services: architectural implications
Signal-based designs encourage implicit coupling: a receiver must know exactly which signal, where it lives, and how to interpret update rates and validity.
Consider a simple data item like VehicleSpeed in an AUTOSAR Classic architecture. It is typicially model as Sender/Receiver signal at the RTE level then “wired” through several configuration layers until it finally appears on a bus message. When you add a new consumer (another ECU/function) you often have to update not only the application, but also the communication configuration and network description, even though the feature change looks small.
That is exactly the kind of integration friction SDV programs try to avoid: when the meaning of data is buried in configuration and network descriptions instead of being defined by a clear service contract. AUTOSAR Adaptive is the new AUTOSAR standard aiming to standardize how software components can communicate via service-centric design.
Services move the semantics into the interface: A provider declares what it offers (data + operations). A consumer binds to that contract, not to a specific ECU or a specific signal layout. Service availability can be dynamic (startup dependencies, optional features), and consumers can react accordingly.
For example, a Window Controller app can subscribe to a VariantConfig service and only expose rear-window child lock or remote window closing if the vehicle configuration says those optional functions are present.
In SDV programs, this typically leads to two practical consequences:
- A service boundary becomes a reuse boundary. If the service contract stays stable, the implementation can move or be replaced with contained impact.
- Cross-domain functions become composable. Features are built by consuming multiple services rather than by tapping into a growing signal list.
SOME/IP in that picture
SOME/IP (Scalable service-Oriented MiddlewarE over IP) is an AUTOSAR-defined middleware protocol for service-oriented ECU-to-ECU communication over IP, typically Automotive Ethernet. It gained traction with the move to Ethernet to support higher-bandwidth and more software-driven use cases, and it is commonly used to complement or replace signal-centric communication when a clearer service contract and more flexibility are needed.
The key idea is still simple: devices offer services, and other devices discover and consume them dynamically. SOME/IP Protocol or Transport layer defines the message framing and the interaction types (methods, events, fields); SOME/IP‑SD (Service Discovery), another stack on top, complements it by handling dynamic service availability. It is widely adopted in both AUTOSAR Classic and Adaptive (and beyond). In practice, many teams prototype or integrate using the open-source vSOMEIP stack (Linux), maintained under COVESA’s vSOMEIP project. Today, SOME/IP shows up in typical SDV “backbone” use cases: In‑Vehicle Infotainement services, ADAS/sensor data exchange, centralized compute/zonal architectures, and ECU-to-ECU service communication.
Communication model: what is exchanged
SOME/IP communication is message-based. Instead of “wiring signals”, participants exchange messages that clearly state which service/instance is addressed and which interface element is used.
Most interactions can be understood with just two primitives:
- Call style (Request/Response): a consumer sends a request and the provider returns a response.
- Notify Style (Publish/Subscribe): a consumer subscribes, and the provider publishes notifications to all subscribers.
These primitives enable three interaction types: Methods, Events, and Fields. The later reflect the three most common integration needs in vehicles as well as the patterns software engineers already know from distributed systems.
- Methods: “Do something / give me an answer.” Methods follow the familiar client–server Remote Procedure Call (RPC) idea: explicit commands/queries with clear success and error handling.
- Events: “Something happened / here is the latest update.”. Events follow publish/subscribe messaging: efficient fan-out for updates and notifications.
- Fields: “This is state.” Fields borrow from property/state semantics: a clean way to model “current value + change events” without forcing every consumer to reconstruct state from a stream of events
At a practical level, the interface is identified by IDs that both sides agree on:
Basic flow of the independent building blocks
How Methods, Events, and Fields map onto the building blocks
A method uses (B): a consumer sends a request addressed to a METHOD_ID, and the provider returns a response. You may also use a “fire-and-forget” variant where no response is expected.
An event uses (C): consumers subscribe an event group and requests an Event based on EVENT_ID within the group, and the provider publishes notifications whenever it has something to announce.
A field combines both worlds. Reading or writing the state (getter/setter) uses (B), while observing state changes uses (C) through a field-change notification carried like an event.
This mapping is what keeps the overall model simple: once you understand the call style and the notify style, the three interaction types become a matter of intent and contract design, not a new protocol to learn each time.
The three interaction types pseudo-code examples
Methods – request/response operations
Use a method when the client wants to trigger a defined operation and get a result (or an error). Think commands, queries, transactions, diagnostics.
In the example pseudo-code below, Client calls a method from Server that doubles a given value (5.5)
Events – publish/subscribe notifications
Use an event when the provider publishes updates asynchronously to one or more consumers. This fits status updates, sensor-style data, and “something happened” notifications.
In the example pseudo-code below, Server sends notification upon speed value exceeding a certain limit to the Client which displays it.
Fields – state + get/set + change notification
Use a field when you expose state. A field makes the “current value” explicit via getter method, optional updates explicit via setter method, and still supports observation (field-change notification).
In the example pseudo-code below, Client gets the current Temperature, then sets it and is being notified of changed value.
Conclusion
SOME/IP maps well to SDV integration because it matches how teams want to collaborate: via explicit service contracts and a small set of interaction types. If you design the interface intentionally (Methods vs Events vs Fields), the rest of the stack becomes significantly easier to evolve and test.
A practical way to keep contracts clean is to choose the interaction type based on intent. If a consumer needs to trigger an operation and get a result, use a method (clear request/response and error handling). If you need to distribute updates to one or many consumers, use an event (publish/subscribe fan‑out). If you are exposing state that consumers must be able to read reliably, and optionally write, model it as a field (getter/setter plus change notification as one concept). As a rule of thumb: whenever consumers need a well-defined current value, prefer a field over a pure stream of events; it avoids every consumer rebuilding state and resynchronization logic on its own.
