Automotive industry

A service-oriented architecture for the automotive industry

What you will learn:

  • Signal-oriented vs service-oriented data transmission.
  • The vital role of middleware in service-oriented architecture.
  • How does the “Real-Time Drivers” software support AUTOSAR middleware?

The pace of change in the automotive industry is at an unprecedented level. Not only are cars rapidly switching from fossil fuels to electric, but the vehicle itself is also playing an increasingly important role in advanced driver assistance systems (ADAS) to improve driving comfort, l efficiency and safety.

In our previous article, we explained the shift from conventional electrical and electronic (E/E) architecture within the vehicle to domain and zone architectures. Here, software takes precedence over hardware in defining the vehicle and its key components. This will require a redundant Ethernet backbone for the E/E architecture and domain-based middleware (such as AUTOSAR) to enable Service Oriented Architecture (SoA) implementation.

Service Oriented Architecture

With the move to zonal architecture, an enormous amount of sensor data is produced and transferred around the vehicle. In this case, even the highest bandwidth Ethernet backbone can be challenged, especially with video streams from a dozen or more cameras.

The simplistic approach is signal-oriented data transmission. In other words, once the sender sees a need, the data is transmitted. Data is sent when values ​​are updated or changed, regardless of whether a receiver on the network currently needs the data. Sending “blind” data can result in unnecessary data transmission, which can hamper overall performance and even delay critical signals, such as emergency braking or collision avoidance.

On the other hand, service-oriented data transmission operates on an “on-demand” basis, in which a sender transmits data only when at least one receiver in the network needs that data. There is no unnecessary loading of data on network infrastructure or connected nodes using this methodology.


SoA is a way of designing software in which participating components provide and consume services using a predefined protocol over a network. Here, the architecture relies heavily on the middleware used. Scalable service-oriented middleware over IP (SOME/IP) provides service-oriented communication over a network.

Among the various middleware functions supported by SOME/IP are inter-ECU client/server serialization, remote procedure calls (RPC), service discovery (SD), publish/subscribe (Pub/Sub), and the segmentation of User Datagram Protocol (UDP) messages. Its ability to coexist with legacy systems, high data throughput, and low transport overhead are just some of the benefits of using this protocol.

Based on the SOME/IP protocol and following many of the same principles, AUTomotive Open System Architecture (AUTOSAR) is an open and standardized middleware resulting from a worldwide partnership of companies involved in the automotive sector. Initially (in 2003), membership was driven by German automakers and Tier-1s including BMW, Continental AG, Daimler AG, Robert Bosch GmbH, Siemens VDO and Volkswagen. Since then, the group has continued to grow and now includes Ford Motor Company, Groupe PSA, Toyota and General Motors.

AUTOSAR Adaptive, for example, eliminates the need for applications to adapt to new APIs or semantics beyond those needed for other network bindings, such as SOME/IP. Indeed, the data distribution service (DDS) network link of the communications management functional cluster enables service-oriented communications over DDS.

Software “Real time pilots” for AUTOSAR

As modern cars move to software-defined vehicles, automotive software has become the main development challenge. Tackling the cost and complexity of automotive software development, NXP has released real-time driver (RTD) software that supports all S32 automotive processors with Arm Cortex-M or Cortex-R52 cores.

The RTD software includes a high-level interface for AUTOSAR and a low-level interface for non-AUTOSAR architectures. RTD offers full IP coverage with ISO 26262 security compliance up to ASIL D for AUTOSAR 4.4, including multi-core and security support. Using NXP’s S32 configuration tool or AUTOSAR partner toolchains, the RTD software is highly configurable.

RTD supports all new and existing S32 families within the Software Enablement Platform via a set of production-grade safety-compliant software drivers that aim to simplify the development of AUTOSAR (and non-AUTOSAR) applications . Using a common codebase and software API maximizes software reuse across processor platforms, and including the production license in silicon expands AUTOSAR access for mass market developers.

Additional add-on software for the S32 platform includes Hardware Security Engine (HSE) firmware designed to anticipate future OEM requirements and an Inter-Platform Communication Framework (IPCF) — middleware for managing communication and resources in multi-core systems/ BONE. Additionally, the new Security Software Framework (SAF) is available under license and contains security libraries for fault detection and reaction mechanisms, providing a basis for ISO 26262 compliance.