Overview
This article explains the drivers behind the SOA trend in automotive electrical/electronic (E/E) architectures, defines what SOA means in this context, summarizes its benefits, and outlines practical implementation approaches for vehicles.
Why adopt SOA in vehicles?
Enable new features for existing vehicles and shorten time to market
Traditional in-vehicle controllers connect via legacy buses to exchange signals and messages. Signal routing and publication/subscription relationships are typically static and hard to change. If a new node is added later, updating routing tables and service relationships is difficult. Even if an OTA update delivers new application software to a controller, how will that new software discover and obtain the required information from other nodes?
Require an architecture that supports flexible function governance
OTA enables online updates, but OTA is only a delivery mechanism. The underlying electrical/electronic architecture and software platform must be able to support function updates. If a newly added function conflicts with existing system architecture, drivers, or communication models, it will not be deployable. A design that supports flexible, composable functions is required.
Vehicles as part of the Internet of Things
Vehicles will increasingly participate in Internet, IoT, and energy IoT ecosystems. They must be open, networked, and capable of autonomous adaptation. Use cases such as automated driving, V2X, and edge computing demand an E/E and software platform that can accommodate those requirements. Existing E/E architectures struggle with these challenges, which motivates SOA-based solutions for vehicles.
SOA is more than SOME/IP
Service-Oriented Architecture (SOA) originated in IT and is primarily an architectural strategy rather than a specific technology. OASIS describes SOA as a paradigm for organizing distributed systems under different administrative domains. The core SOA goals are clear:
- Build flexible, evolvable platform systems
- Loose coupling between services; stateless interactions where possible
- High cohesion within services; services designed for reuse and flexible recomposition
- Standardized service communication
Implementing SOA in vehicles emphasizes three aspects: Service-Oriented Communication (SOC), Service-Oriented Reuse-shared Design (SORS), and Service-Oriented Software Architecture (SOS). In the automotive domain, SOME/IP largely addresses SOC. However, SOC alone does not achieve SOA's goals: service design and a supporting software architecture are equally important. Therefore, equating SOA with SOME/IP underestimates the scope of the transformation.
Figure 1. SOA schematic
Implementing vehicle SOA (v-SOA)
v-SOA applies SOA concepts to vehicles. In IT, SOA is commonly implemented over Ethernet. In-vehicle Ethernet has matured over recent years, and China-developed next-generation models using in-vehicle Ethernet have entered production. Leveraging in-vehicle Ethernet is a practical way to implement SOA. Below we describe v-SOA implementation through SOC, SORS, and SOS.
SOC: Service-Oriented Communication
SOC standardizes communication and enables dynamic relationships that bridge information silos. SOME/IP, defined in AUTOSAR, is a middleware protocol family designed for the vehicle environment and implements service-oriented communication. SOME/IP enables interoperability across heterogeneous systems and can fulfill SOC requirements; other transport protocols (for example, DDS) may also be used when prerequisites are met.
Communication behavior: SOME/IP adopts RPC-style mechanisms and a client-server model. SOME/IP Service Discovery lets a client dynamically discover and subscribe to services from servers. Clients can use Request-Response or Fire&Forget models to access services. Servers can push subscribed content to clients using Notification patterns. With Ethernet switching, nodes can forward at layer 2 and dynamically establish service providers and consumers without extra components. For example, a high-definition map server may offer lane data as an offered service; an ADAS controller can subscribe to the lane EventGroup, the server acknowledges the subscription, and then the server publishes lane data to the ADAS controller. In another example, an HU (head unit) requests memory status from a DVR: the DVR acts as server, the HU as client; the DVR responds to the request with the current state.
Figure 2. SOME/IP communication example
Service interface description: A unified service interface description is essential for cross-system communication. SOME/IP specifies serialization rules and data types; during system design, teams should define service interfaces and addressing information consistently based on SOME/IP data types.
SORS: Service-Oriented Reuse-shared Design
Many current vehicle E/E architectures remain highly distributed: Ethernet-capable nodes hang off gateways with no domain controllers, zonal controllers, or centralized high-performance nodes. While SOC can operate in that distributed model, implementing full SOA is difficult because functions are overly fragmented and resource-constrained nodes rarely have spare capacity to host future functions. This limitation motivates next-generation E/E architectures (for example, domain or zonal architectures) that move logic upward into high-performance, resource-rich central nodes.
Figure. Distributed E/E architecture
Figure. Next-generation E/E architecture
SORS is realized on these next-generation intelligent, networked architectures. The goal is to design services with high cohesion and low coupling so they can be reused and recomposed, with clear boundaries. Implementation responsibility typically lies with the vehicle OEM's E/E architecture team during concept and system design. The architecture team should lead or participate throughout requirements development, function definition, function implementation, subsystem design, and component design so that SORS is reflected in the final implementation.
Design approaches: There is no single standard for SORS; two practical approaches appear in industry:
- Bottom-up: Inventory endpoint hardware capabilities and identify common service candidates. For example, a combined ambient/light-and-rain sensor can provide both illumination intensity and rain detection. Such hardware can be abstracted into a single "ambient and rain" service. Continue exploring upward to identify additional hardware-provided functions and their data for service extraction.
- Top-down: Start from vehicle functions and business flows. For example, vehicle theft authentication involves multiple steps and algorithms (randomization, authentication algorithms). Extract those algorithms into reusable algorithm services. By decomposing functional chains into a service library, it becomes possible to recompose services to reproduce original functionality.
SORS-driven design greatly simplifies future feature additions. Under traditional models, new features often require OEM planning, long development cycles, or even new hardware platforms. With SORS, the OEM analyzes available software and hardware resources during platform/model development and builds a reusable service library. The OEM or authorized third parties can then assemble new functions quickly from the service library and deploy them via OTA.
SOS: Service-Oriented Software Architecture
SOS refers to the software architecture that supports service-based systems on ECUs. AUTOSAR Adaptive Platform (AP) is a middleware example that embodies service-based architecture principles: the ARA runtime environment is split into Foundation and Service layers.
Figure. AP software architecture schematic
Foundation components include:
- CM (Communication Management): node-to-node and inter-process communication
- EM (Execution Management): process lifecycle and execution control
- REST: external connectivity via RESTful interfaces
- PHM (Platform Health Management): platform health management
- TimeSyn: time synchronization
Service components include:
- SM (State Management): supervises state transitions of function groups and processes
- DM (Diagnostic Management): diagnostics and flashing at AAP granularity
- NM (Network Management): network management
- UCM (Update and Configuration Management): application updates, AP self-update, and OS update management
AP is a middleware intended to run on POSIX-compliant operating systems. Applications (AAP) run in the ARA runtime and are managed, scheduled, and configured by AP.
Relation to AUTOSAR Classic Platform (CP) and other OSes: CP and AP are both part of the AUTOSAR family. CP has been widely used for embedded ECUs where a single function-per-box and strict timing requirements are common. CP's modular architecture combined with AUTOSAR OS meets many real-time embedded needs.
However, next-generation architectures require some nodes to process large volumes of data and execute intensive, high-frequency compute workloads. These nodes require abundant software and hardware resources and must meet automotive safety requirements. CP and conventional OSes (for example, Android) are not always adequate for these scenarios. AP targets HPC (High Performance Controller) class ECUs by providing unified management of subordinate OS instances and resources, keeping scheduling, state, and resource consumption under control to meet safety and determinism requirements. With rich resources, solutions might use multi-core heterogeneous architectures, hypervisors, and virtualization so CP, AP, and non-AUTOSAR systems can coexist in an HPC, depending on functional requirements.
