Perspectives on Automotive Operating Systems | #linux | #linuxsecurity | #hacking | #aihp

An operating system (OS) is required to manage all hardware and software for computer–based systems, and is a key software platform for the automotive industry. This article focuses on giving tutorial information and some perspectives on automotive OS strategy.

Each OS has large variations in terms of functionality, program size, complexity, development effort, and hardware requirements, as well as life–time maintenance, support effort, and costs. An OS can range from simple control programs with a few thousand lines of code to tens of millions of lines of code for major OSes such as Linux, macOS, iOS, and Windows. Linux kernel code size varies by distribution company, with the GitHub version having about 28 million lines of code.

Wikipedia is a great source for information on OS history, technology, and products. There is detailed data on OS technology, but most of the content is focused on traditional computer systems ranging from mainframe computers and PCs to smartphones and tablets. There is general information on the leading auto OSes such as Linux and QNX but little context and information on automotive OS usage.

OS overview

An OS provides an interface between computer hardware and application programs. This restricts an application to use the hardware by following rules and procedures programmed into the OS. The OS also includes services that simplify development and execution of apps. These services include managing all the hardware resources the app will use — loading the program into memory, communicating with sensors and actuators, storing results, and many other functions.

There are also many additional software capabilities that are considered part of the OS, including so–called middleware, libraries, and other system software.

The OS capabilities and ecosystem are also important for developing the apps and software platforms that software–defined vehicles require. In other words, the best OS choice requires a large ecosystem and infrastructure to support the growing software–defined vehicles of the future.

The table below summarizes the requirements for automotive OSes.

There are many features of an OS that determine its capabilities. A single–tasking OS can run only one program at a time, while a multi–tasking OS can run multiple programs. A single–user OS has no facilities to distinguish users, but may allow multiple programs to run at the same time.

A multi–user OS extends multi–tasking to run programs from multiple users. This requires tracking what hardware and software resources each user is using. The system permits multiple users to interact with the system at the same time.

OS kernel

The OS kernel includes all the key functions for managing the hardware and software. There are two main approaches of organizing the kernel: monolithic kernel or microkernel OS. A monolithic kernel architecture includes all the core OS functionality in the kernel space — all system calls and OS services in one place. Linux is a leading monolithic kernel OS.

A microkernel OS has the near–minimum amount of software that can provide the mechanisms needed to implement an OS. Additional OS services are organized as layered services that can be activated by the microkernel as needed. This means the microkernel OS has a modular architecture.

The advantage is that the microkernel has a small code space and can be made more secure than a monolithic kernel OS. A modular OS structure is better for most automotive ECUs. QNX is a leading microkernel OS.

Hypervisor OS

A hypervisor is a small software platform for managing multiple OS platforms and their apps. It may also be called a virtual machine (VM) monitor, which is software that runs VMs.

Virtualization has been used in the computer industry since the 1960s and is a key tech for IT data centers. Hypervisors are important for combining infotainment and functional–safety functions such as a head–unit display for a backup monitor.

Functional–safety OS

An OS with functional–safety certification is required for many ECUs. This means ISO 26262 certification with various Automotive Safety Integrity Levels (ASILs). There are four ASILs identified by the standard: ASIL A, B, C, and D. ASIL D has the highest integrity requirements.

All AUTOSAR–based OSes — such as Vector’s Microsar OS, ETAS’s RTA-OS, and Elektrobit’s EB Tresos Safety OS — have functional–safety ratings. Three other products are commonly used in automotive ECUs: Green Hills Integrity RTOS, Wind River VxWorks, and BlackBerry QNX. You can learn more about functional–safety information in this article.

Functional–safety OSes cannot manage ECUs with large and complex software code such as infotainment systems and emerging domain advanced driver–assistance system (ADAS) ECUs and autonomous-vehicle (AV) ECUs. The exception is QNX, which is a leader in infotainment and is positioned well for ADAS and AV domain ECUs.

The need for a high–capability OS in infotainment opened the door for Linux versions and made it the most popular infotainment OS in the last five years. A disadvantage of Linux is its lack of functional–safety certification. The hypervisor OS has been the solution for Linux when functional–safety apps are needed as part of a Linux–based ECU.

It looks like Linux will have at least one functional–safety version in the near future. In May 2022, GM announced it will use Red Hat’s Linux version that is receiving functional–safety certification. GM plans to launch products in 2023. It is not clear if Red Hat has already received functional–safety certification, but it is likely that other Linux suppliers will try to get functional–safety certification. Google’s infotainment OS is making rapid progress and looks like a candidate for functional safety.

OS ecosystem support

A key to OS success is a large ecosystem of support. The more software platforms that support an OS, the more successful it will be. It is also important that the OS can run on leading microprocessor platforms and specific MCU implementations. However, because automotive ECUs are dominated by ARM–based microprocessors, this requirement is easily met.

All MCU application software must run via an OS, which means there should be good software development support for a successful OS.

OS cost factors

There are many factors that determine the cost of using an OS. This discussion assumes the OS is bought, not developed, by an auto OEM.

The first factor is the licensing cost of the OS, which includes the OS kernel, middleware, and library software such as math, floating point, graphics, and others. The Linux kernel OS is an open–source code and is a free software platform. In most cases, there are licensing fees for Linux middleware and some libraries.

The size of an OS will impact the amount of hardware required to run software with its applications. The total code size impacts the maximum permanent storage size needed. In the disk era, this was not much of a factor, as most hard disk drives were big enough. Today, the permanent storage is primarily NAND chips or eMMC modules, which can often add extra cost for OS size.

The OS footprint is the amount of RAM needed to run the OS and its applications. Again, the size of the OS footprint can impact the memory cost of the system.

Another factor is the hardware cost, where the OS may impact the MCU cost. A large OS is likely to increase the needed MCU performance, which could increase the hardware costs.

The reason for this discussion is to weigh all potential OS cost factors. It is too easy to assume that the free OS kernel of a Linux OS will provide enough cost savings to outweigh potential extra costs that a large OS will generate.

ECU software development

ECU software development is crucial to the automotive industry, and complexity and effort continue to grow. Traditional ECU software development was initially done via software development kits (SDKs) from multiple suppliers. SDKs have been replaced by integrated development environments (IDEs) that have much better capabilities and have expanded into web–based IDE systems. The Eclipse IDE has become the most popular software development system for auto and many other industries. Eclipse is managed by the Eclipse Foundation, a nonprofit corporation founded by IBM in 2001.

Web–centric software development is growing rapidly, with Amazon AWS being especially active. AWS is building partnerships to serve the need for better software development with SaaS functionality included. Microsoft Azure and others are also experiencing similar growth.

There is also a trend to provide software development systems focused on functional–safety applications. Apex.AI is a prime example of this trend.

Emerging ECU needs

The OS also needs to incorporate support for emerging technology needs. Cybersecurity is most important, and all OSes include security as a core function. Additional hardware, software, and cloud–based cybersecurity is becoming standard in software–defined vehicles and needs as much support as possible, including from the OS.

OTA software updates are also growing in importance and can use extra support from OS services. OTA platforms are increasing in capabilities from both embedded software and cloud functionality.

ECU data extraction is a third category that is part of the expanding connected–car functionality. It can also benefit from OS services and new functionality.

OS strategy perspectives

All automotive ECUs need a control program or OS that manages a variety of programs that control the hardware components and the applications each ECU is designed to accomplish. As the complexity of the ECU grows, the complexity of the OS increases. OEMs will need multiple OSes to cover the large range of ECU capabilities and functionality.

For simple ECUs, OEMs seem to favor an AUTOSAR–based OS. AUTOSAR capabilities have increased but cannot handle high–end ECU complexities such as infotainment and most domain ECUs. Both Green Hills and Wind River have an excellent OS with strong safety and security ratings and are good options.

The high–end ECUs primarily use QNX or a Linux version as the OS, with QNX favored when functional safety is needed. Linux has surpassed QNX as the favorite infotainment OS. QNX is becoming the favorite for domain ECUs, at least for ADAS and AV domain ECUs.

There have been numerous press reports that several OEMs, including VW and Mercedes–Benz, are talking about developing their own car OS. Does this mean they are considering a make instead of a buy decision? This strategy does not come without risk.

To develop an OS is a monumental task, and the OS may have a lifetime of 30 to 40 years with regular updates and continuous technical improvements. Linux has about 30 years of development, while QNX has nearly 40 years of development.

To develop a car OS will require a great deal of technological expertise, which is in limited supply, and will require multiple years of development.

GM’s strategy of using a Red Hat Linux with functional–safety certification is a much better approach to get its own OS for complex ECUs.

What would be the best long–term OS strategy? Best practice would be to start with the safest OS possible for two ECU categories — low complexity and high complexity. Why? Because cybersecurity issues will be the toughest problem the auto industry will face for decades, and the OS will make a difference.

For low–complexity ECUs, Green Hills has the highest security and safety certifications, including FAA certification for airplane use.

For high–end ECUs, QNX has higher security and safety certifications than the Linux version and is likely to retain this ranking — even if some Linux versions get ISO 26262 certification. QNX’s microkernel architecture makes for a more secure OS. New standards for AVs — ISO 21448, UL 4600, and IEEE P2851 — can use some helpful features in the OS, and QNX is likely to develop such features first.

This article was originally published on EE Times.

Egil Juliussen has over 35 years’ experience in the high-tech and automotive industries. Most recently he was director of research at the automotive technology group of IHS Markit. His latest research was focused on autonomous vehicles and mobility-as-a-service. He was co-founder of Telematics Research Group, which was acquired by iSuppli (IHS acquired iSuppli in 2010); before that he co-founded Future Computing and Computer Industry Almanac. Previously, Dr. Juliussen was with Texas Instruments where he was a strategic and product planner for microprocessors and PCs. He is the author of over 700 papers, reports and conference presentations. He received B.S., M.S., and Ph.D. degrees in electrical engineering from Purdue University, and is a member of SAE and IEEE.