Overview of In-Vehicle Middleware Solutions

Introduction

In the era of software-defined vehicles, the role of middleware has become increasingly important. As E/E architecture gradually centralizes, the automotive software system has seen a coexistence of multiple operating systems, leading to a sharp increase in system complexity and development costs. To enhance the manageability, portability, configurability, and quality of software, it is necessary to define a set of architecture, methodology, and application interfaces, thereby achieving standard interfaces, high-quality seamless integration, efficient development, and managing complex systems through new models. This is what we refer to as “middleware.” In the automotive industry, there are numerous OEMs and suppliers, each OEM having different suppliers and models, and each supplier supplying to more than one OEM. The existence of middleware allows the same products to be reused across different models or enables compatibility between products from different suppliers, significantly reducing development costs. Therefore, it can be said that middleware plays a key role in the trend of decoupling automotive software and hardware.

01

AUTOSAR: The Most Widely Used

Standard Specification for Vehicle Electronic Systems

Currently, AUTOSAR has two main platforms: Classic Platform and Adaptive Platform, corresponding to traditional control vehicle electronic systems and high-performance in-vehicle electronic systems for autonomous driving, respectively. AUTOSAR (Automotive Open System Architecture) refers to the automotive open architecture, which is a cooperative development framework for automotive electronic systems jointly developed by global automotive manufacturers, component suppliers, and various research and service institutions. It establishes an open automotive controller (ECU) standard software architecture and standardizes the in-vehicle operating system standards and API interfaces. AUTOSAR consists of two major platforms:

1. Classic Platform (CP): The Classic Platform is AUTOSAR’s solution for traditional vehicle control embedded systems, with strict real-time and safety constraints. Architecturally, the Classic Platform can be roughly divided into microcontrollers, basic software layer, runtime environment layer, and application software layer from bottom to top.

2. Adaptive Platform (AP): The Adaptive Platform is a new automotive electronic system software architecture standard proposed by AUTOSAR for complex scenarios such as future autonomous driving and vehicle networking. The Adaptive platform modifies a large number of standards from the Classic platform, adopting an operating system based on the POSIX standard and developed with an object-oriented approach, capable of using all standard POSIX APIs, primarily aimed at meeting the current trends in automotive autonomous driving, electrification, and connectivity.

AUTOSAR Classic Platform Architecture

Data Source: AUTOSAR Official Website, Dongfang Securities Research Institute

AUTOSAR Adaptive Platform Architecture

Data Source: AUTOSAR Official Website, Dongfang Securities Research Institute

Compared to the Classic Platform, the Adaptive Platform is more suitable for the development of high-performance intelligent vehicles. With the advancement of communication technology, vehicles have begun to adopt Ethernet communication, which provides higher bandwidth for automotive ECUs, enabling large amounts of data to be transmitted in a short time. The AUTOSAR CP is designed for traditional in-vehicle communication technology CAN and does not well support Ethernet, making it difficult to support Ethernet-based communication. Furthermore, as the intelligence level of vehicles increases, advanced functions such as automatic parking, environmental perception, and path planning have a much higher demand for processor computing power than for multi-core requirements. Although AUTOSAR CP has been applied to traditional multi-core processing technology, it still cannot meet the ECU processing power demands of vehicles; from the perspective of processor and semiconductor technology, the only way to enhance performance is through multi-core parallel operation, and parallel operation and so-called heterogeneous computing exceed the coverage of CP. Due to the difficulties in supporting the development of high-performance intelligent vehicles in terms of communication speed and computing power, in 2017, the AUTOSAR alliance launched the AUTOSAR AP platform with stronger communication capabilities and more flexible software configurability. Specifically, the main differences between AUTOSAR CP and AUTOSAR AP are as follows:

1. Different supported chip platforms:AUTOSAR CP mainly runs on 8-bit, 16-bit, and 32-bit MCUs, corresponding to traditional body control, chassis control, power systems, etc. If it involves autonomous driving, AUTOSAR CP may not be able to achieve it; while AUTOSAR AP mainly runs on high-performance MPUs/SoCs above 64 bits, corresponding to high-performance electronic systems for autonomous driving, capable of better supporting multi-core, multi-ECU, and multi-SoC parallel processing, thus providing stronger computing power.

2. Different definitions:AUTOSAR CP is not just “middleware,” but a complete “operating system” consisting of “OS kernel + middleware,” defining basic upper-layer task scheduling, priority scheduling, etc. In a distributed architecture, the chips are mainly MCUs, each MCU needs to run a set of AUTOSAR CP; for example, in the distributed architecture-based ADAS function, AUTOSAR CP is the most common “operating system.” Unlike AUTOSAR CP, which already includes an OS based on the OSEK standard, AUTOSAR AP is merely middleware running on POSIX standard-based OS such as Linux or QNX, thus it does not include an OS itself, further advancing the process of software-hardware decoupling.

3. Different architectures, communication methods, and connection methods:

(1) AUTOSAR CP adopts a FOA architecture, while AUTOSAR AP adopts a SOA architecture;

(2) AUTOSAR CP uses a signal-based static configuration communication method (CAN/LIN, etc.), while AUTOSAR AP uses a service-based SOA dynamic communication method (SOME/IP);

(3) In AUTOSAR CP, the connection relationship of hardware resources is limited by the wiring harness, while in AUTOSAR AP, the connection relationship between hardware resources is virtualized and not limited to the connection relationship of communication wiring harnesses.

SOA-based communication allows ECUs in AP to dynamically connect with other ECUs. Additionally, the service modules in AP are independent, providing higher security and deployment flexibility.

Comparison of Classic Platform and Adaptive Platform

Data Source: CSDN, Dongfang Securities Research Institute

For a considerable time to come, AUTOSAR AP will not completely replace AUTOSAR CP, as the application fields of the two are different. In some aspects, AUTOSAR AP has certain “disadvantages” compared to AUTOSAR CP, such as AUTOSAR CP’s latency can be as low as microseconds, and its functional safety level reaches ASIL-D, hard real-time; while the latency of AUTOSAR AP is in milliseconds, and its functional safety level is ASIL-B, soft real-time. This leads to different application fields: AUTOSAR CP is generally applied in scenarios with high real-time and functional safety requirements but lower computing power requirements, such as engine control, braking, and other traditional ECUs; while AUTOSAR AP is applied in scenarios with certain requirements for real-time and functional safety but higher computing power requirements, such as ADAS, autonomous driving, and in dynamic deployment scenarios seeking higher degrees of freedom in entertainment applications. Due to the long-term existence of SoC + MCU combinations, AUTOSAR AP will not completely replace AUTOSAR CP for a considerable time to come. The most common division of labor is to assign high-computing tasks to AUTOSAR AP and high-real-time tasks to AUTOSAR CP.

02

ROS2: Supporting

Middleware for Autonomous Driving Scenarios

ROS (Robot Operating System) refers to a set of open-source software frameworks and tools designed to help developers build robotic applications. It provides hardware abstraction, device drivers, function libraries, visualization tools, messaging, and software package management. The ROS system originated from the collaboration between Stanford University’s AI Lab’s STAIR project and Willow Garage’s Personal Robots Program in 2007, and it was promoted by Willow Garage after 2008. The initial intention of the ROS project was to provide a development environment and corresponding tools for the Willow Garage PR2 research robot. To allow this software to run on more robots, ROS provides a relatively complete middleware, tools, software, and a set of universal interfaces and standards for robotic development, enabling developers in the robotics industry to quickly develop system prototypes for testing and validation.

ROS2 has improved and enhanced some of the deficiencies of ROS1, making it more suitable for product environments. Since its launch, ROS has been widely applied in industrial fields, including research robots, industrial robots, wheeled robots, autonomous vehicles, and even aerospace unmanned devices. Its original functional design could no longer meet the demands for certain performance (such as real-time, safety, embedded portability, etc.) in mass applications, leading to the design and development of ROS2. The main differences between ROS2 and ROS1 include:

1. ROS1 is primarily built on Linux systems, mainly supporting Ubuntu; ROS2 adopts a new architecture, with a bottom layer based on DDS (Data Distribution Service, a data distribution/subscription standard designed for real-time systems), supporting real-time, embedded, distributed, and multi-operating systems. ROS2 supports systems including Linux, Windows, Mac, RTOS, and even bare-metal systems without operating systems.

2. ROS1’s communication system is based on TCPROS/UDPROS and heavily relies on the master node’s processing; ROS2’s communication system is based on DDS, eliminating the master node while providing an internal DDS abstraction layer implementation. With this abstraction layer, users do not need to focus on which vendor’s API is used for the underlying DDS, allowing developers to develop low-coupling function modules in parallel and facilitating secondary reuse.

3. ROS1 relies on roscore at runtime, and once roscore encounters issues, it can cause significant system disasters. Additionally, due to its large installation and runtime size, it can burden many low-resource systems; ROS2 transmits data based on DDS, which uses a decentralized communication framework based on RTPS, thus removing the dependency on roscore, enhancing system stability and reducing resource consumption.

4. ROS2 introduces QoS (Quality of Service) principles, mainly supporting the real-time, integrity, and historical traceability of communications. This significantly enhances the framework’s functionality, avoiding issues where high-speed systems are difficult to apply. ROS1 lacks a QoS mechanism, making it difficult to guarantee the stability and quality of topics.

ROS2 Enhances Applicability in Product Environments Compared to ROS1

Data Source: CSDN, Dongfang Securities Research Institute

1. AUTOSAR AP is strictly a middleware that shields specific processor and computer OS-related details from the ECU function implementation layer, providing basic services required for interaction with vehicle networks, power systems, etc.; ROS2 serves as an application framework for robot development, providing a universal middleware framework and commonly used software modules (ROSPackage) between applications and OS, and can be referred to as an operating system in some sense.

2. AUTOSAR AP is a standard that defines standard interfaces for applications but does not define implementation details; the interaction interfaces between platform components need to be implemented by AUTOSAR AP suppliers; ROS2, on the other hand, prioritizes code, with each version having complete code implementations and defined application-oriented standard API interfaces.

3. AUTOSAR AP is designed from the outset for ASIL-B applications; ROS2 is not designed according to ASIL standards, and its functional safety solutions require replacing the underlying components with those that meet ASIL requirements, such as RTOS and commercial toolchains (compilers). For instance, Apex.AI’s Apex.OS, developed based on ROS2, has passed the highest level of ASIL-D certification, effectively implementing a set of AUTOSAR AP specifications based on the architecture of ROS2.

03

Major Middleware in the Industry: CyberRT and Iceoryx

CyberRT

CyberRT is middleware developed by Baidu Apollo, officially released in Apollo 3.5. Initially, Baidu used ROS1, but during usage, they gradually discovered that ROS1 had issues where “if ROS Master fails, communication between any two nodes would be affected,” leading them to seek a communication middleware “without intermediate nodes” to replace ROS1. At that time, ROS2 had not yet been released, so they developed CyberRT independently. CyberRT, similar to ROS2, also uses an open-source version of DDS at its core; to solve the issues of ROS1, CyberRT removed the master mechanism and replaced it with an automatic discovery mechanism, which is consistent with the automotive network CAN. Additionally, the core design of CyberRT moves scheduling and tasks from kernel space to user space. Compared to other middleware solutions, a significant advantage of CyberRT is that it is specifically designed for autonomous driving, including foundational libraries, communication layers, data layers, and computation layers.

CyberRT Architecture

Data Source: CSDN, Apollo, Dongfang Securities Research Institute

Iceoryx

Iceoryx is a middleware solution launched by ETAS, a subsidiary of Bosch. ETAS was established in 1994 and is a wholly-owned subsidiary of Bosch. Bosch has long held one of the top three market shares in the mass production of ADAS, making their need for efficient data transfer in autonomous driving even more pressing. In July 2020, ETAS launched Iceoryx (Ice Antelope) middleware for advanced autonomous driving applications. Iceoryx is an inter-process communication (IPC) middleware suitable for various operating systems, currently supporting Linux, macOS, and QNX, and is compatible with both ROS2 and AUTOSAR AP interfaces to meet different development stage needs.

Iceoryx Compatible with AUTOSAR and ROS2

Data Source: BOSCH, Dongfang Securities Research Institute

Traditional data transmission involves copying data, consuming a significant amount of memory and causing delays. As a large amount of perception data related to autonomous driving needs to be rapidly circulated within the system, inter-process communication (IPC) needs to play a role. For example, in Linux systems, information is transmitted or exchanged between different processes. Due to the independent address spaces of different processes, data is constantly copied back and forth when passing data, establishing and releasing stacks, wasting and occupying a large amount of system resources and causing unintended delays.

Iceoryx’s Zero-Copy Communication Mechanism

Data Source: The Eclipse Foundation, Dongfang Securities Research Institute

Iceoryx still requires validation and continuous optimization in more mass-produced models. Iceoryx is open-source and follows the Apache-2.0 license, allowing any individual or team to use the source code for free. Iceoryx depends on POSIX API, and due to slight differences in APIs across different operating systems, minor modifications may be needed when porting Iceoryx to another POSIX-based operating system. However, if ASIL-B or ASIL-D level functional safety certification is needed, related safety services must be purchased from Bosch. Currently, the biggest challenge for Iceoryx is the need for OEMs to quickly implement it in mass-produced vehicles to truly test its value. Additionally, as the types of perception information for autonomous driving continue to increase, how to efficiently allocate and manage memory blocks for laser point cloud data, camera RGGB frames, 3D millimeter-wave radar target information, 4D millimeter-wave radar point cloud information, and vehicle signal data is also a prerequisite for achieving true “zero-copy,” which requires continuous refinement and optimization in actual projects.

04

Other Communication Middleware:

SOME/IP and DDS, etc.

Based on whether the source code is open, communication middleware can be simply divided into closed-source and open-source:

1. Closed-source communication middleware mainly includes Vector’s SOME/IP, RTI’s DDS, etc.;

2. Open-source communication middleware mainly includes OPENDDS, FASTDDS, CycloneDDS, etc.

SOME/IP

Strictly speaking, SOME/IP is not a specific product but a technology standard. In 2011, BMW designed and proposed SOME/IP, which stands for Scalable Service-oriented Middleware over IP. To break it down, it communicates in a server-client service form, and the service possesses high scalability. In traditional Ethernet, the OSI model divides Ethernet into seven layers, while in the automotive industry, OSI layers 5-7 are collectively referred to as the application layer, thus the in-vehicle Ethernet has only five layers. The SOME/IP protocol is an application layer protocol that runs on top of TCP/UDP transport protocols (above layer four of the in-vehicle Ethernet), serving as an Ethernet communication middleware to achieve data interaction between the application layer and the IP layer, making it independent of the operating system while also compatible with both AUTOSAR and non-AUTOSAR platforms. Therefore, SOME/IP can operate independently of hardware platforms, operating systems, and programming languages.

SOME/IP is a service-oriented transport protocol

Data Source: CDSN, Dongfang Securities Research Institute

SOME/IP operates above layer four of the in-vehicle Ethernet

Data Source: CDSN, Dongfang Securities Research Institute

SOME/IP supports communication interaction between AUTOSAR CP, AUTOSAR AP, and non-AUTOSAR platforms. After BMW designed the SOME/IP protocol, it was incorporated into the official AUTOSAR standards and widely used in in-vehicle Ethernet with the release of CP specifications, thus it can be said that AUTOSAR CP has promoted the widespread use of SOME/IP. With the high platform scalability of the SOME/IP protocol, data interaction between different platforms can be achieved, and the unified SOME/IP communication mechanism is a prerequisite for communication between different platforms. To run SOME/IP on different software platforms and achieve SOA architecture communication mechanisms on the entire vehicle Ethernet, the AP specifications also introduced SOME/IP, making it relatively easy for AUTOSAR systems to implement SOME/IP communication between CP and AP. To facilitate better interaction between non-AUTOSAR software platforms and in-vehicle CP and AP ECUs, the GENIVI system has also developed an open-source vSOME/IP software source code for interaction with CP/AP. However, since vSOME/IP is open-source, its performance may be slightly inferior, thus requiring unified specifications to impose constraints for deeper secondary development. Currently, the largest commercial SOME/IP product supplier globally is Vector, while the open-source vSOME/IP is maintained by the GENIVI Alliance.

AUTOSAR has promoted the widespread use of the SOME/IP protocol

Data Source: CDSN, Dongfang Securities Research Institute

DDS

DDS (Data Distribution Service) refers to a data distribution service, which is a distributed communication specification published by OMG. OMG (Object Management Group) was established in 1989 and is an international, open, non-profit technical standards alliance, driven by vendors, end-users, academic institutions, and government agencies, with over 30 years of history. OMG working groups formulate enterprise integration standards for various technologies and industries, developing technical standards that provide real value for thousands of vertical industries, including Unified Modeling Language SYSML, UML, and middleware standards CORBA, DDS, etc. DDS was first applied in the US Navy systems to solve compatibility issues for massive software upgrades in complex network environments aboard ships. With the introduction of DDS into ROS2 and AUTOSAR, it has been widely applied in fields such as aviation, aerospace, shipping, defense, finance, communication, and automotive.

DDS adopts a publish/subscribe model, providing various QoS (Quality of Service) strategies to ensure real-time, efficient, and flexible data distribution, meeting the application needs of various distributed real-time communications. DDS defines the data transmitted in a distributed network as “topics,” and the data producers and receivers as “publishers” and “subscribers,” respectively, forming a data-centric publish-subscribe transmission model (Data-Centric Publish-Subscribe, DCPS). Each node has no master-slave relationship logically, and the communication can be point-to-point, point-to-many, or many-to-many, establishing connections under QoS control and automatically discovering and configuring network parameters.

DDS adopts a publish/subscribe model

Data Source: DDS Foundation, Dongfang Securities Research Institute

Currently, DDS has been introduced into multiple in-vehicle middleware platforms. In 2018, DDS was first introduced into AUTOSAR AP as an optional communication method. In March 2018, RTI, the main provider of DDS, announced that the latest version of AUTOSAR AP (version 18-03) had completed network binding with the DDS standard. Additionally, the standard specification of AUTOSAR CP does not support DDS, but it can be integrated with DDS with some modifications. As mentioned earlier, both ROS2 and CyberRT use open-source DDS as their underlying layer, making DDS the most important communication mechanism. Correspondingly, SoC chips aimed at autonomous driving, such as Xavier and Orin, have also reserved DDS interfaces.

Differences Between SOME/IP and DDS

SOME/IP and DDS are currently the two most commonly used types of communication middleware in autonomous driving, and they share some common features:

(1) Both are service-oriented communication protocols;

(2) Both adopt a data-centric publish/subscribe model.

However, SOME/IP and DDS also have many differences, with the main distinctions as follows:

1. Different main application fields: SOME/IP is specifically developed for the automotive field, defining a communication standard tailored to automotive needs, with a longer history in the automotive sector; DDS is an industrial-grade strong real-time communication standard with strong adaptability to various scenarios, but it requires specific trimming when used in automotive/autonomous driving fields.

2. Differences in flexibility and scalability: Compared to SOME/IP, DDS introduces many built-in standard features, such as content- and time-based filtering, reliability independent of transport, persistence, liveliness, delay/deadline monitoring, and extensible types. When building a communication framework with AUTOSAR AP and DDS, this framework not only remains compatible with existing APIs and applications but also provides significant benefits in reliability, performance, flexibility, and scalability.

3. Strong coupling between subscribers and publishers: In SOME/IP, prior to normal data transmission, subscribers need to establish a network connection with publishers and inquire whether the publisher provides the required service, which maintains a certain level of coupling between nodes. Under the DDS standard, each subscriber or publisher only needs to subscribe or publish sensor data within its program without concerning itself with any connections. Therefore, the decoupling of service subscribers and publishers is more thorough in DDS.

4. Different service policies: A better QoS is the most important feature of the DDS standard compared to SOME/IP. SOME/IP has only one QoS, while RTI DDS and open-source DDS have over 50 and 20 QoS options, respectively, covering nearly all foreseeable intelligent driving scenarios.

5. Different application scenarios: From the perspective of application scenarios, SOME/IP leans towards in-vehicle networks and can only be used in IP-type network environments; DDS has no special restrictions on transmission methods and can support non-IP-type networks such as shared memory, cross-core communication, PCI-E, etc. Additionally, DDS has comprehensive connected vehicle solutions, with its unique DDS Security and DDS Web features providing users with a one-stop solution for vehicle-cloud-mobile.

In commercial deployment, SOME/IP and DDS are in direct competition, but due to their differences in application fields, flexibility, service policies, etc., automakers can choose suitable communication middleware as needed, and the two can even coexist. This is why AUTOSAR AP supports both SOME/IP and DDS.

• Scenario Activities | Robotaxi & Unmanned Retail First Linkage Demonstration Area Boosts New Application Scenarios

• What Aspects Should Be Considered in Electrical and Electronic Architecture Design?

• A Brief Discussion on the Feasibility of Vehicle-Road Collaboration in Intersection Scenarios

• CODA: Extreme Case Dataset for Road Object Detection in Autonomous Driving

• Some Thoughts on Autonomous Driving Routes

• Weekly Report on the Autonomous Driving Industry (4.18)

• The Ministry of Industry and Information Technology Issued a Notice on Conducting Online Upgrade Filing for Automotive Software, Strengthening OTA Upgrade Supervision

• How Autonomous Driving Safety Can Validate Itself

• Growth-Oriented Vehicles | Zeekr 001 Major Upgrade, Leapmotor C11, Lynk & Co 09 Add Karaoke Functionality

• Automotive OTA Operations: Empowering the Personalized and Diversified Development of Future Vehicles Starting from Service Definitions