A Service-Oriented Architecture for the Automotive Industry

What you'll learn:

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

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

In our previous article, we explained the shift from conventional electrical and electronic (E/E) architecture within the vehicle to the domain and zonal architectures. Here, software is taking 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 the service-oriented architecture (SoA) to be implemented.

Service-Oriented Architecture

With the move to the zonal architecture, a huge amount of sensor data is being produced and transferred around the vehicle. In this case, even the most high-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, data is transmitted. Data is sent when values are updated or changed, independent of whether any receiver on the network currently needs the data. Sending “blind” data can lead to needless data transmission, which may impede overall performance and even delay time-critical signals, such as emergency braking or collision avoidance.

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

Middleware

SoA is a way of designing software in which the 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 (RPCs), service discovery (SD), publish/subscribe (Pub/Sub), and segmentation of User Datagram Protocol (UDP) messages. Its ability to coexist with existing systems, high data rate, and low transportation overhead are just a few benefits of using this protocol.

Based on the SOME/IP protocol and following many of the same principles, AUTomotive Open System Architecture (AUTOSAR) is open and standardized middleware from a global partnership of companies involved in the automotive business. Initially (in 2003), membership was driven by German carmakers and Tier-1s, including BMW, Continental AG, Daimler AG, Robert Bosch GmbH, Siemens VDO, and Volkswagen. Since then, the group has continued to expand 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 necessary for other Network Bindings, such as SOME/IP. That’s because the Data Distribution Service (DDS) Network Binding of the Communications Management functional cluster enables service-oriented communications over DDS.

"Real-Time Drivers" Software for AUTOSAR

As modern cars transition to software-defined vehicles, automotive software has emerged as the central development challenge. Tackling the cost and complexity of automotive software development, NXP released Real-Time Drivers (RTD) software that supports all S32 automotive processors featuring Arm Cortex-M or Cortex-R52 cores.

NXP’s Real-Time Drivers (RTD) software helps simplify AUTOSAR and non-AUTOSAR application development. It supports all S32 automotive processors that integrate 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 comprehensive IP coverage with ISO 26262 safety compliance up to ASIL D for AUTOSAR 4.4, including mult-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 package of production-grade, safety-compliant software drivers that aim to simplify AUTOSAR (and non-AUTOSAR) application development. The use of a common code base and software API helps maximize software reuse across processor platforms, and the inclusion of the production license in the silicon broadens AUTOSAR access for mass-market developers.

Additional complementary 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/OS systems. In addition, the new Safety Software Framework (SAF) is available under license and contains safety libraries for fault detection and reaction mechanisms, providing a foundation for ISO 26262 compliance