Understanding Automotive Operating Systems

Safety vehicle operating systems primarily target classic vehicle control fields, such as power systems, chassis systems, and body systems. These operating systems have extremely high requirements for real-time performance and safety, and their ecosystem development has matured.

Safety vehicle operating systems are mainly real-time operating systems (RTOS), with the primary application object being the ECU. The basic requirement for safety vehicle operating systems is high real-time performance, as the system needs to complete resource allocation, task synchronization, and other specified actions within a specified time. Embedded real-time operating systems have advantages in high reliability, real-time performance, interactivity, and multi-channel capabilities, with system responses typically in the millisecond or microsecond range, meeting the high real-time performance requirements.

Currently, mainstream safety vehicle operating systems are compatible with OSEK/VDX and Classic AUTOSAR automotive electronic software standards. Among them, the Classic platform is based on the OSEK/VDX standard, defining the technical specifications for safety vehicle operating systems.

② Intelligent Driving Operating Systems

With the development of intelligent and connected technologies, intelligent vehicles’ perception fusion, decision planning, and control execution functions have brought about more complex algorithms and generated large amounts of data, requiring higher computing and data communication capabilities. The safety vehicle operating systems based on OSEK/VDX and Classic AUTOSAR software architectures can no longer meet the future development needs of autonomous vehicles. The AUTOSAR organization has introduced the Adaptive AUTOSAR platform to address the needs of more complex domain controllers and centralized computing platforms.

Adaptive AUTOSAR defines an operating system based on the POSIX standard, providing standardized platform interfaces and application services for POSIX-compliant operating systems and different application needs, primarily to adapt to the development needs of automotive intelligence. The Adaptive AUTOSAR is still in its early stages, and its ecosystem construction has yet to gain widespread recognition from Tier 1 suppliers and OEMs.

Intelligent driving operating systems mainly target the intelligent driving field and are applied in intelligent driving domain controllers. These operating systems have high requirements for safety and reliability, as well as high performance and computing power. Such operating systems are maturing globally, but their ecosystems are not yet complete.

③ Intelligent Cockpit Operating Systems

Intelligent cockpit operating systems primarily provide control platforms for automotive infotainment services and human-machine interaction within the vehicle. They are the operational environment for achieving cockpit intelligence and multi-source information integration, and their real-time and reliability requirements are not stringent.

Mainstream models’ intelligent cockpit operating systems include QNX, Linux, and Android. Among traditional intelligent cockpit operating systems, QNX holds a significant market share. In recent years, the entertainment and information service attributes of intelligent cockpits have become increasingly prominent, leading many OEMs to favor open-source Linux and Android, which has a wealth of mature information service resources in the mobile domain, making them rising stars. Additionally, a few foreign models have also adopted Win CE as their intelligent cockpit operating system.

As people’s demand for vehicles transitions from mere transportation tools to intelligent mobile terminals, intelligent cockpit operating systems need to support diverse applications and services while possessing rich ecological resources.

2. Overview of Mainstream Automotive Operating System Solutions at Home and Abroad

② Volkswagen Centralized Software Architecture

Volkswagen has formed a large team to develop its automotive operating system, vw.OS, to accelerate the application of autonomous driving technology. vw.OS adopts a service-oriented software architecture based on Adaptive AUTOSAR, with the centralized software architecture illustrated in the figure above.

The design features of Volkswagen’s new generation EE architecture mainly include:

• High-performance processors and high-speed networks

• POSIX-compatible kernels (Linux/QNX, etc.) + Adaptive AUTOSAR

• Decoupling of application software and I/O functions, reducing the complexity of the entire system and dependencies between applications

• Efficient and rapid development of user functions

• Service-oriented communication

③ Huawei MDC Intelligent Driving Computing Platform Architecture

Huawei MDC (Mobile Data Center) is positioned as a computing platform for intelligent driving. The platform integrates Huawei’s over 30 years of research and development and manufacturing experience in the ICT field, based on CPU and AI processor chips, equipped with intelligent driving OS, compatible with AUTOSAR, and supporting smooth evolution from L2 to L5, combined with a complete toolchain that allows customers or ecological partners to develop intelligent driving applications for different application scenarios.

The main features of Huawei’s MDC intelligent driving computing platform architecture include:

• Provides hardware and software solutions that are highly decoupled and can be independently upgraded; the hardware upgrade path and software upgrade path are independent of each other;

• Good compatibility with mainstream sensors, supporting data access from mainstream GNSS, IMU, cameras, LiDAR, and millimeter-wave radar, and supporting pre-fusion of camera and LiDAR point clouds;

• Good compatibility with mainstream middleware software, supporting core components of commonly used deep learning frameworks such as Caffe and TensorFlow (chip, operating system kernel) that are independently controllable;

• Huawei is the only manufacturer in the industry with both CPU and AI chip research and development capabilities, and the MDC platform hardware integrates powerful SoC chips with CPU and AI computing capabilities, providing scalable heterogeneous computing power for intelligent driving;

• Functional software is based on SOA architecture, adhering to AUTOSAR specifications, defining the calling framework for basic algorithm components of intelligent driving and the software interfaces between components; upper-layer application scenarios can flexibly choose different combinations of algorithm components to achieve specific application functions.

④ NVIDIA Autonomous Driving Platform Architecture

NVIDIA is a global leader in artificial intelligence computing, leveraging its advanced hardware chip development advantages to provide a complete hardware platform and basic software platform centered on industry-leading high-performance safety chips, as shown in the figure above. NVIDIA’s computing platform hardware is currently at the Xavier stage, with the next generation platform Orin released but not yet on the market. Xavier is the first automotive-grade system-on-chip produced by NVIDIA, which employs six different types of processors.

Based on the Xavier chip, NVIDIA provides DRIVE AGX Xavier for autonomous driving development, with a computing power of 30 TOPS, targeting L2+ and L3 autonomous driving; the provided DRIVE AGX Pegasus uses two Xavier system-on-chips and two Turing GPUs with a computing power of 320 TOPS, targeting L4 and L5 autonomous driving. The NVIDIA Drive system software layer integrates third-party RTOS + AUTOSAR, with a Hypervisor layer, and third-party mass production RTOS solutions have passed ASIL D certification.

⑤ Baidu Apollo Open Platform Architecture

Baidu Apollo is a software platform that relies on third-party IPC for its computing platform hardware. The architecture of the Apollo open platform is shown in the figure above. Baidu has independently developed two auxiliary hardware units, ASU (Apollo Sensor Unit) and AXU (Apollo Expansion Unit). The ASU is used to collect data from various sensors and transmit it to the IPC via PCIe; additionally, the IPC’s control commands for the vehicle must also be sent to the CAN via the ASU; the AXU is used to meet additional computing and storage needs, connecting to existing hardware platforms in the form of GPU and FPGA.

The main features of Baidu Apollo include:

• End-to-end development of software and hardware for connected cloud control (V2X)

• Well integrated with cloud services, including many of Baidu’s other products, such as basic Baidu cloud services, online simulation products, high-precision maps, and Duer OS, benefiting from each other

• Due to its open-source nature, the core algorithm modules have undergone extensive optimization on GitHub and have been fully productized

• Mainly focused on the development of system software, including customized and optimized operating systems, system middleware, and algorithm function modules, with most hardware adopting third-party solutions

• Products do not involve additional development adaptation to the AUTOSAR architecture and do not require changes to existing ECUs/MCUs in vehicles.

① Safety Vehicle Operating Systems

Safety vehicle operating systems have developed earlier abroad, and a series of standardization efforts have already been undertaken, while domestically, the current state is mainly one of following.

Europe developed the open system standard OSEK/VDX for distributed real-time control systems in automotive electronics in the 1990s, which mainly includes four parts: operating system specifications, communication specifications, network management specifications, and OSEK implementation language. However, with the upgrading of technology, products, and customer demands, the OSEK standard gradually cannot support new hardware platforms.

In 2003, nine companies, including BMW, Bosch, Continental, Daimler, General Motors, Ford, PSA, Toyota, and Volkswagen, as core members, established an organization for automotive open system architecture (referred to as the AUTOSAR organization), dedicated to creating a standardized platform, independent of hardware, with a layered software architecture, formulating various vehicle application interface specifications and integration standards. It provides methodological guidance for application development to reduce the complexity of automotive software design, improve flexibility and development efficiency, and enhance reusability across different automotive platforms. AUTOSAR is based on OSEK/VDX but covers a broader scope.

As of now, the AUTOSAR organization has released Classic and Adaptive platform specifications, corresponding to safety control and high-performance autonomous driving. The Classic platform is based on the OSEK/VDX standard, defining the technical specifications for safety vehicle operating systems. The software architecture of Classic AUTOSAR is illustrated in the figure below, characterized by a function-oriented architecture (FOA) that employs a layered design to decouple the application layer, basic software layer, and hardware layer.

Classic AUTOSAR Layered Software Architecture (R20-11)

The AUTOSAR standard platform, by adopting an open architecture and vertical layering, horizontal modularization, not only improves development efficiency and reduces development costs but also ensures the safety and consistency of vehicles. The AUTOSAR organization has evolved to gain increasing recognition within the industry, with over 280 members from the automotive, parts, software, and hardware sectors. AUTOSAR has become the mainstream standard software architecture internationally, with companies like Vector, KPIT, ETAS, DS, and Elektrobit (acquired by Continental) and Mentor Graphics (acquired by Siemens) offering complete automotive software solutions based on the AUTOSAR standard platform. Additionally, automotive manufacturers such as BMW and Volvo have successively launched models based on the AUTOSAR standard platform.

The Japan Automotive Software Platform Architecture organization, or JasPar, was established in 2004, aiming to unite companies in horizontally customizing communication standards that consider both automotive software and hardware to achieve the generalization of automotive operating systems and improve the reuse rate of basic software. Members of the JasPar organization include the vast majority of Japanese automotive and supporting software and hardware product manufacturers.

Japan Automotive Software Platform Architecture Organization JasPar

Currently, domestic OEMs and component suppliers mainly use the Classic AUTOSAR standard for software development. OEMs such as FAW Group and Changan Group began utilizing Classic AUTOSAR standard tools for ECU design, development, and verification in 2009. In April 2011, SAIC Group, FAW Group, Changan Group, Chery Group, and some universities established the CASA Alliance, aimed at promoting and developing the AUTOSAR architecture in China. Currently, JAC Motors also primarily develops software and products based on the Classic AUTOSAR standard.

CASA Alliance Organizational Structure

In terms of products, PwC Software is the domestic operating system strategic platform of the China Electronics Technology Group, and as the leading unit, has undertaken major projects related to automotive electronic operating systems during the 11th and 12th Five-Year Plans. The automotive operating systems developed have been applied in mass production in key components such as body control modules (BCM), new energy vehicle controllers (VCU/HCU), and electronic steering systems (EPS), and have been utilized in mass production by Bosch’s advanced driver-assistance systems (ADAS).

Neusoft Ruichi has released the NeuSAR product, which is developed based on AUTOSAR, providing a system platform for next-generation automotive communication and computing architecture for OEMs developing autonomous driving systems and component suppliers, encompassing Classic AUTOSAR, Adaptive AUTOSAR, and a series of development system tools.

② Intelligent Driving Operating Systems

Intelligent driving operating systems are expected to become one of the core competitive advantages in the development of autonomous vehicles. The development trend and characteristics of intelligent driving operating systems are vertical layering to achieve decoupling between layers for easier and faster development and porting, as shown in the figure below.

Intelligent Driving Operating System Vertical Layering Diagram

Each layer has its responsibilities and different functions:

Operating System: Responsible for providing services such as thread creation for hardware;

Middleware/Development Framework: Responsible for interfacing with different operating systems and providing communication, resource management, and other services for upper applications;

Application/Function Software: The rest is its responsibility.

Currently, the intelligent driving operating systems commonly adopted in the industry are mainly Linux, QNX, and other RTOS (such as FreeRTOS, ThreadX, VxWorks, etc.).

The main characteristics of the three are compared in the figure below:

Comparison of Intelligent Driving Operating Systems

Linux was initially designed as a general-purpose operating system, but it provides some real-time processing support, including many real-time features from the POSIX standard, supporting multitasking and multithreading, and offering rich communication mechanisms. Additionally, the Linux community has real-time enhancement patches that add features such as interrupt threadization and priority inheritance to the existing RT features of the Linux kernel. Linux also provides scheduling policies that comply with POSIX standards, including FIFO scheduling, time-slice round-robin scheduling, and static priority preemptive scheduling. Furthermore, Linux offers memory locking features to prevent pages from being swapped out during real-time processing and provides real-time signal mechanisms that comply with POSIX standards.

QNX is a commercial real-time operating system that complies with POSIX standards, characterized by its suitability for distributed, embedded, and scalable hard real-time operating systems. QNX adheres to POSIX.1 (program interface) and POSIX.2 (shell and tools), and partially adheres to POSIX.1b (real-time extensions). The microkernel structure of QNX is a significant feature that distinguishes it from other operating systems. The microkernel structure of QNX keeps the kernel independent in a protected address space, while device drivers, network protocols, and applications reside in the program space.

Above the low-level operating systems, software middleware is also gaining attention in the intelligent driving field. The main goal of middleware is to provide common functionalities such as data communication, protocol alignment, computing scheduling, and modular packaging for upper applications, offering a standardized and modular development framework that achieves module decoupling and code reuse.

Next, we will introduce two middleware solutions for autonomous driving: Adaptive AUTOSAR and ROS.

Adaptive AUTOSAR

Adaptive AUTOSAR Architecture Logical View (R20-11)

The AUTOSAR organization launched the Adaptive AUTOSAR (AP) architecture to address the development of autonomous driving technology, as shown in the figure above. Its main feature is a service-oriented architecture (SOA), where services can be dynamically loaded based on application needs, can be dynamically loaded through configuration files, and can be individually updated. Compared to Classic AUTOSAR (CP), it can meet more powerful computing requirements, is safer, has good compatibility, and allows for agile development.

The Adaptive AUTOSAR system is primarily suited for new centralized high-performance computing platforms to meet the high-speed communication needs between vehicle components and the high computing power requirements of intelligent driving. The AP platform adopts a service-oriented architecture, composed of a series of services, where applications and other software modules can call one or more services as needed, and services can be provided by the platform or remotely from other components, allowing OEMs to define their service combinations according to functional design needs.

The AP platform does not design a new operating system kernel; any operating system kernel that complies with POSIX PSE51 interfaces can be used. The AP platform focuses on the system service middleware layer above the operating system kernel, divided into platform basic functions and platform service functions. The three main support and evolution directions of the AP platform are: safety (including information security and functional safety), connectivity (including various new communication mechanisms inside and outside the vehicle), and upgradability (including OTA, flexible software design, and management, etc.). The AP platform still adopts the traditional standard design approach, with a new version released annually focusing on new feature releases.

ROS

ROS Architecture

ROS, as the earliest open-source robot software middleware, has been used in the robotics industry for a long time. The primary design goal of ROS is to improve code reuse in the field of robot development. ROS is a distributed process (or “node”) framework, where these processes are encapsulated in easy-to-share and publish packages and functionality packages. The entire intelligent driving system shares strong similarities with robotic systems, and ROS’s open-source nature, rich open-source libraries, and toolchains have particularly found extensive applications in intelligent driving research, with many autonomous driving prototype systems featuring ROS, such as AUTOWARE. Baidu Apollo initially also used ROS until version 3.5, when it switched to its self-developed vehicle middleware CyberRT.

During its development, ROS has had two versions: ROS1 and ROS2. ROS1’s communication relies on a central node’s processing, which cannot solve reliability issues like single-point failures. To better meet industrial-grade operational standards, the biggest change in ROS2 is the elimination of the Master central node, enabling distributed discovery of nodes and supporting publish/subscribe and request/response; it is based on DDS (Data Distribution Service), an industrial-grade communication middleware mechanism, supporting multiple operating systems, including Linux, Windows, Mac, RTOS, etc.

Although ROS2 has made significant improvements based on ROS1, it still has a long way to go for complete automotive applications, and some companies, such as APEX.AI, are also attempting to modify ROS for automotive-grade applications.

③ Intelligent Cockpit Operating Systems

Currently, there are no unified international standards in the field of intelligent cockpit operating systems, which are mainly controlled by a few foreign software companies, including BlackBerry’s QNX, various customized operating systems based on Linux, and operating systems based on the Android open-source project (which is also based on Linux).

QNX CAR Application Platform

QNX is a commercial real-time operating system that complies with POSIX standards, primarily targeting embedded systems, characterized by high operational efficiency and reliability, and has nearly 40 years of experience in the industrial control field. It is widely used in automotive, rail transportation, aerospace, and other fields that require high safety and real-time performance. QNX is the world’s first intelligent cockpit operating system to pass ISO 26262 ASIL D safety certification, matching over 40 automotive brands globally and applied in over 60 million vehicles, making it the market leader in intelligent cockpit operating systems with a global market share exceeding 75%.

The development of intelligent cockpits and autonomous driving, along with Tesla’s rapid progress, has led major OEMs to pay increasing attention to automotive operating systems. However, the software-defined vehicles that automakers are currently working on mostly involve decoupling hardware and software to reduce manufacturing costs and enrich new vehicle functionalities, while the operating systems have largely remained at the stage of market research and learning from others.

Given the continuous blockade and suppression of Chinese high-tech enterprises by the United States, having self-controllable vehicle-mounted chips and operating systems is a necessary requirement from a national level. However, do we have sufficient time, human resources, financial resources, and technical capabilities to develop a new operating system? What if the development fails? Will the developed system be used solely for internal purposes? How can we achieve profitability? Will there be a place for it in the market? These are all questions that need to be considered.