The automotive operating system has become increasingly important with the development of automotive intelligence. In a previous article titled “Overview of Automotive Operating Systems 101“, I briefly introduced what an automotive operating system is. Clearly, for operating systems, this is something that has been played with in the IT computer world for decades, but when it comes to automobiles, it seems not so simple; it appears to be a new category that has attracted a large amount of manpower and funding. Therefore, this article organizes related articles to take a look.
-
Why is the automotive operating system complex?
-
What issues should be considered in the development of automotive operating systems?
-
What are the future trends for automotive operating systems?
I hope to provide some knowledge and information to help everyone understand automotive operating systems.
Complex Automotive Operating Systems
The operating system provides an interface between computer hardware and applications. By following the rules and programs of the operating system, applications are restricted in their use of hardware. The operating system also includes services that simplify application development and execution. These services include managing all hardware resources that applications will use—loading programs into memory, communicating with sensors and actuators, storing results, and many other functions.
Thus, the scope of operating systems is very broad, ranging from input and output running on a single chip to interactive systems running on multiple chips or heterogeneous chips (such as the Qualcomm chip mentioned in “Intelligent Cockpit of Li Auto L9, Driving Technology, and Supply Chain“).
The current complexity of automotive operating systems is reflected in—multiple ECUs; luxury cars can have more than 150 ECUs, and the Tesla Model Y has as many as 26 ECUs, various conflicting demands, and the continuously evolving new ECUs. Therefore, the complexity of automotive operating systems is reflected in several aspects:
The Capability Range Requirements of Automotive Operating Systems are Extensive:
-
Single-task and multi-task operating systems; some systems require timeliness, while others need to run multiple programs simultaneously.
-
Single-user and multi-user operating systems can support one or multiple users online. In the future, cars will need to operate like computers, with different users logging in to have different modes and applications.
-
Integrated kernel and microkernel operating systems; microkernels have a modular structure.
-
Hypervisor operating systems can support multiple systems running concurrently.
-
Functionally safe certified operating systems, ISO26262 and ASIL rating certifications.
Different Requirements for Operating Systems from Multiple Control Units (ECUs)
-
Currently, cars can have dozens of ECUs, and compared to computers or mobile phones, the complex application requirements are greater, for example, the entertainment system and intelligent driving ECUs have different requirements.
-
Some ECUs require functional safety, often needing real-time responses.
-
Some need to integrate multiple ECUs, such as the collection of ECUs in domain control.
Multiple Control Units (ECUs) Lead to Multi-Ecosystem Support for Operating Systems
-
Software platform ecosystems to support operating systems.
-
Software development support ecosystems, various options to support ECU software development.
-
Chip processor support, whether the system supports multiple chip platforms for operation.
ECU Software Development: Traditional, Modern, Coexisting
-
Integrated development environments, traditional ECU software creation methods.
-
Network-centric development platforms, growing software creation methods.
-
Functionally safe software development, emerging software creation methods.
Emerging ECU Demands Continue to Arise
-
Cybersecurity software and hardware, forming operating systems, embedded and cloud software.
-
OTA real-time software upgrades, operating system support, embedded and cloud software
-
Vehicle networking and ECU data extraction, operating system support, embedded and cloud software.
Therefore, the complexity of automotive operating systems, along with the history and development of the automotive supply chain, is difficult to eliminate in a short time. However, in the long term, it should simplify, requiring a development process of several decades.
Development of Automotive Operating Systems
Developing operating systems is currently a major project that OEMs are quietly competing over, but evidently, there are many types of automotive operating systems. Generally, when we talk about automotive systems, we often hear the following:
Operating System Kernels, the operating system kernel includes all the critical functions that manage hardware and software. Operating systems can generally be divided into two types: monolithic kernels and microkernel operating systems. Monolithic kernel architectures include all core operating system functions in kernel space—all system calls and operating system services are concentrated in one place. Linux is the leading monolithic kernel operating system.
Microkernel operating systems have almost the least amount of software and can provide the necessary mechanisms to implement the operating system. Additional operating system services are organized as layered services that can be activated by the microkernel as needed. This means that microkernel operating systems have a modular architecture. The advantage is that microkernels have a smaller code space and can be more secure than monolithic kernel operating systems. Modular operating system structures are better suited for most automotive ECUs. QNX is the leading microkernel operating system, with Huawei’s HarmonyOS being used in certain application branches.
Hypervisor Virtual Machines, hypervisor virtual machine managers are small software platforms used to manage multiple operating system platforms and their applications.Virtual machines have been used in the computing industry since the 1960s and are a key technology in IT data centers. It is not a new technology, but modern smart cars have a wide application of hypervisors due to the need for security and open ecosystems, such as the instrument and central control systems in car displays that often run hypervisors, as shared in “Is Apple’s Latest Next-Generation CarPlay an Automotive Operating System?”
Functionally Safe Operating Systems, many ECUs require operating systems with functional safety certifications. This means that they need to have ISO 26262 certifications with various Automotive Safety Integrity Levels (ASIL). The standard defines four ASILs: ASIL A, B, C, and D. ASIL D has the highest integrity requirements.All AUTOSAR-based operating systems—such as Vector’s Microsar operating system, ETAS’s RTA-OS, and Elektrobit’s EB Tresos safety operating system—have functional safety ratings. There are also three other commonly used products in automotive ECUs: Green Hills Integrity RTOS, Wind River’s VxWorks, and BlackBerry QNX.
Functionally safe operating systems generally manage a small range of ECUs and cannot manage ECUs with large complex software code, such as infotainment systems and advanced driver-assistance systems (ADAS) ECUs and autonomous vehicle (AV) ECUs. However, QNX is an exception; it is a leader in the infotainment field and has many applications in ADAS and AV domain control, such as the code running in XPILOT of Xpeng’s autonomous driving and the intelligent cockpit Xmart OS.
The demand for high-performance operating systems in infotainment has opened the door for Linux versions, making it the most popular infotainment operating system in the past five years. A downside of Linux is the lack of functional safety certification. When developing systems that require functional safety applications, hypervisor virtual machines come into play to help run a safety function. Currently, many automotive organizations are researching Linux, so in the near future, there will be more and more functional safety versions.
The most challenging aspect of developing automotive operating systems is theoperating system ecosystem and development support, the key to the success of an operating system is a large supporting ecosystem. The more software platforms support the operating system, the more successful it will be. This is why Huawei’s HarmonyOS may or may not succeed; it is not about whether Huawei can create the system, but whether it can create an ecosystem in the future, which is the most important factor. Think about how widespread the Android ecosystem is.
The operating system ecosystem must first be able to run on various chips, which means there must be a chip ecosystem. Currently, most automotive ECUs are based on ARM’s IP-based microprocessors, so systems are primarily focused on ARM’s architecture IP.
Additionally, all MCU application software must run through the operating system, which means a successful operating system should have good software development ecosystem support. Currently, the complexity and workload of in-vehicle processors are continuously increasing. Traditional ECU software development was initially completed using software development kits (SDKs) from multiple vendors.
In the era of software-defined vehicles, SDKs have been replaced by integrated development environments (IDEs), which offer better functionality and have expanded to web-based IDE systems, allowing OEMs to achieve data interoperability between vehicle and cloud. The Eclipse IDE has become the most popular software development system in the automotive and many other industries. Eclipse is managed by the Eclipse Foundation, a non-profit company founded by IBM in 2001.
As the call for software-defined vehicles grows stronger, web-centric software development is rapidly evolving, disrupting traditional automotive software development. For example, Amazon AWS is particularly active. AWS is building partnerships to meet the demand for better software development that includes SaaS functions. Microsoft Azure and other companies are experiencing similar growth.
Automotive operating system development also needs to focus onemerging ECU demands, and the operating system needs to integrate support for emerging technology demands. For example:
-
Cybersecurity is crucial; all operating systems will make security a core feature. Additional hardware, software, and cloud-based cybersecurity are becoming standard for software-defined vehicles and require as much support as possible, including support from the operating system.
-
OTA software updates are also becoming increasingly important and can utilize additional support from operating system services. The capabilities of embedded software and cloud functionality for OTA platforms are increasing.
-
ECU data extraction is the third category, which is part of extending the functionalities of connected vehicles. It can also benefit from operating system services and new functionalities.
Finally, automotive system development needs to consider cost, operating system cost factors, as many factors determine the cost of developing an operating system:
-
The licensing cost of the operating system, which includes the operating system kernel, middleware, and library software, such as mathematical, floating-point, graphical, etc. The Linux kernel operating system is an open-source code and a free software platform. In most cases, Linux middleware and some libraries require licensing fees.
-
The size of the operating system will affect the amount of hardware required to run its applications. The total code size will affect the maximum permanent storage size required. In the disk era, this was not a big problem as most hard drives were large enough. Today, permanent storage is mainly NAND chips or eMMC modules, which often increases the additional costs of the operating system size.
-
The operating system’s footprint is the amount of RAM required to run the operating system and its applications. Similarly, the size of the operating system’s footprint will affect the memory costs of the system.
-
Another factor is hardware costs, where the operating system may affect MCU costs. Large operating systems may increase the required MCU performance, which could raise hardware costs.
Therefore, considering the costs, one might find why building a completely new automotive operating system from scratch is a very difficult task. Based on Linux operating systems, the free operating system kernel will provide sufficient cost savings and is currently a better path for automotive operating system development.
Trends in Automotive Operating Systems
From the complexity of automotive operating systems seen above, it can be understood that in the medium to short term, there will still be a large variety of ECUs in cars, so multiple systems are the trend. Automotive OEMs need various operating systems to cover a wide range of ECU capabilities and functions.
Thus, the best practice for current automotive operating systems is tochoose a multi-system integration approach based on the complexity of the ECU control unit or processor, combined with its safety and ecosystem requirements. Generally, automotive systems are categorized based on ECU complexity into two types – low complexity and high complexity.
For low-complexity ECUs, the systems running on them are basically lightweight. Based on the historical development of the automotive supply chain, they are primarily AUTOSAR-based operating systems, which are a class of operating systems based on classic AUTOSAR rules, generally used for vehicle diagnostics, communication, motion, and other basic automotive control. Common systems include Vector’s Microsar OS, ETAS’s RTA-OS, Elektrobit’s EB Tresos Safety OS, and Green Hills Integrity RTOS, which all have the highest safety and security certifications and are also widely used in aviation and aerospace.
For high-complexity ECUs, also known as HPC (High-Performance Computing) units, or integrated into domain controllers, the high-performance chips from Qualcomm, NVIDIA, NXP, Texas Instruments, etc., mentioned in the previous article “Six Mainstream In-Vehicle Chips for Intelligent Driving” belong to this category. This mainly involves two hot topics in modern smart vehicles: intelligent driving and intelligent cockpits. The focus of demand for these two aspects is entirely different; intelligent driving requires safety and stability, while intelligent cockpits require open interaction and ecological applications.
Complex integrated ECUs mainly use QNX, Linux versions, and Android as operating systems, prioritizing QNX when functional safety is required. For example, in intelligent driving, QNX has higher safety and security certifications than Linux versions, and it is likely to maintain this ranking—even if some Linux versions obtain ISO 26262 certification. QNX’s microkernel architecture makes the operating system more secure, and QNX has undergone decades of industry validation, so the vast majority of intelligent driving systems on the road use QNX, such as those from NIO, Xpeng, and other brands based on NVIDIA chip solutions.
However, Linux has surpassed QNX to become the most popular operating system favored by OEMs. In fact, the previous articles “Through the Lens of Mercedes MB.OS: How It Achieves Software-Defined Vehicles” and “The Three Steps of Volkswagen’s Path to VW.OS and the Unhappiness Behind Its MEB ID Series Intelligence” have mentioned that they are developing their own operating systems, most of which are based on the Linux core, primarily because Linux is the mainstream enterprise-level system in the IT industry and has a rich open-source development ecosystem. Therefore, in the era of software-defined vehicles, Linux is rising jointly in vehicle and cloud environments.
Of course, whether OEMs are really developing systems is uncertain. Developing operating systems is a daunting task, and the lifecycle of an operating system may last 30 to 40 years, with regular updates and continuous technological improvements. Linux has been in development for about 30 years, while QNX has been around for nearly 40 years.Developing automotive operating systems requires a lot of technical expertise, but the supply is limited, and it takes years of development.Thus, when automotive companies talk about “developing automotive systems,” it should be more about application changes and adaptations. Collaborations like AGL, formed by Toyota, Nissan, and NVIDIA, and GENIVI (now renamed COVESA), formed by BMW, General Motors, etc., are defining rules for Linux system development.
Currently, the most famous application of Linux is Tesla’s system, which is likely a variant of Linux called Ubuntu. Those familiar with IT servers might be well aware of Ubuntu. Tesla, as mentioned above, uses Linux Ubuntu, and whether it meets automotive-grade standards is not strictly regulated. However, it can be confirmed that there will be more automotive-grade Linux versions in the future. General Motors’ Ultifi software-defined vehicle platform will adopt Red Hat Linux for both vehicle and cloud applications, expected to launch in 2023. Mercedes’ Linux-based operating system is expected to be deployed in 2024, while Volkswagen plans to do so in 2025. Thus, the Linux series, with its open-source nature and perfect integration of data in software-defined vehicles, is the route that many OEMs are pursuing or wish to pursue.
Another area for entertainment interaction isAndroid, which needs no introduction. With its perfect application and development ecosystem, it has basically reached its peak in the entertainment system. Whether for new forces or traditional European and American car companies, they have basically installed or modified an Android system in their in-car systems to realize various connected applications. Currently, many applications from new forces are ported to the Android platform, such as video apps, music apps, etc.
However, many OEMs have mixed feelings about Android. If Android unifies the automotive operating system market, OEMs fear they will merely become hardware manufacturers, missing out on the sovereignty of future software-defined vehicles. This is why Tesla initially did not consider Android, and others adopting Android systems also initially avoided Google’s application market.
Reference Articles and Images
-
Perspectives on Automotive Operating Systems – Egil Juliussen
-
Overview of Functional Safety Measures in AUTOSAR – autosar pdf Downloadable
-
Automotive OS – eletrobit pdf Downloadable
-
Free Software Automotive stack(s) that run on available hardware -Jeremiah C. Foster pdf Downloadable
-
automating next generation mobility – zf pdf Downloadable
-
software defined vehicles a forthcoming industrial evolution – Deloitte pdf Downloadable
-
preview – The Software-Defined Vehicle Enabling the Updatable Car – SBD pdf Downloadable
-
Software Defined Vehicle – Bosch pdf Downloadable
-
Red Hat Software Defined Vehicle and In-Vehicle OS – Red Hat pdf Downloadable
*Reproduction and excerpting without permission is strictly prohibited – Obtain reference materials by:
Joining our Knowledge PlanetVehicle to download a wealth of reference materials including the above references.
-
Why Did Geely, a Car Manufacturer, Team Up with Meizu, a Phone Manufacturer?
-
BMW’s Pure Electric Priority New Strategy “Neue Klasse” 2025
-
Intelligent Cockpit of Li Auto L9, Driving Technology, and Supply Chain
-
From Security to Automotive: Leapmotor
-
How Mercedes MB.OS Achieves Software-Defined Vehicles
-
Interpretation of Lucid’s (New Force in Luxury Electric Vehicles) Investment Roadshow
-
New Forces in Electric Vehicles: Rivian and Its Full Lifecycle Ecosystem
