Linux and software containers in the vehicle
More and more vehicle functions are implemented by software, the industry speaks of “Software Defined Vehicle” (SDV). Therefore, many OEMs are investing massively in new software platforms in the vehicle.
As part of their SDV strategy, OEMs are primarily focused in operating systems and middleware. In this context, Linux and software containers play an important role. In this articles, the advantages of these technologies are discussed, but also the challenges that must be overcome to bring these technologies into the vehicle.
What drives the development?
The amount of software in modern vehicles is growing exponentially. The abbreviation “CASE” for “Connected”, “Autonomous”, “Shared” and “Electrified” describes the properties of today’s vehicles that increase comfort and safety while reducing CO2 emissions. Since more and more software is being used in vehicles in ever shorter innovation cycles, car manufacturers are trying to significantly expand their own software development skills.
This goes hand in hand with a change in the electronics and electrics (E/E) architecture in the vehicle: So far, we have up to 100 different control units in luxury vehicles (ECUs), which are connected to one another via various bus systems and exchange data. These bus systems are in turn integrated using gateways. The high number of control units is historical: if a new function was implemented using mechatronics instead of mechanics, then a dedicated control unit, dedicated sensors and actuators were installed for it. It was only over time that sensor data and actuators began to be used across control units and to integrate several functions into one control unit.
Now, however, manufacturers are replacing many individual ECUs with a few but very powerful computing units, so-called high-performance compute units (HPC). These are still surrounded by a few ECUs that perform data pre-processing and less complex control tasks in the periphery. These ECUs are arranged in zones, so that one also speaks of a “zonal architecture” [1].
HPCs need a powerful operating system that not only provides the classic operating system functions, but also offers newer options for virtualization and containerization of software that are known from the IT world.And so, the automotive industry is finding more and more interest in using Linux, probably the most successful open source operating system in the IT industry, which turned 30 last year [2].
Linux in Vehicles?
One of the success factors of Linux is because Linux is open source. Lower costs, fewer errors and thus higher quality are usually cited as the greatest advantages of open source over proprietary products. But the lack of vendor lock-in, a larger number of users and programmers trained in them, and faster innovation cycles also make open source interesting. There are also companies like Red Hat [3], Suse [4] and others that offer technical support and ongoing updates for Linux. Most of these companies also provide access to a broad ecosystem of suppliers of certified hardware and software.
Linux as an operating system in vehicles is not entirely new. Some have been using Linux in the infotainment area for a long time. The GENIVI initiative, which was supported primarily by European and US companies, and which is now continued under the name Connected Vehicle Systems Alliance (COVESA) [5], is well known. But AGL, Automotive Grade Linux [6], found friends too. Finally, Google Android, which is often used in the infotainment sector, is also based on Linux. Regardless of the infotainment domain, the industry is now considering using Linux in other domains as well, including the safety relevant autonomous driving domain.
What needs to be done now
Unfortunately, the well-known Linux distributions are currently hardly suitable for the use in vehicles because they are not designed for the special requirements in vehicles. For example, the boot times are too long, which means that the system does not start up quickly enough. Many experts also complain about the insufficient real-time capabilities of Linux. And so, there are several functional and non-functional improvements that must be programmed and tested first. This also includes a comprehensive “roll-back” functionality that restores the original status in the event of a failed update, or secure recording (“logging”) of messages and their encryption. The even greater effort, however, lies in the qualification of the Linux system for the automotive regulations, above all the fulfillment of the requirements of ISO 26262 [7].
The ISO standard 26262 regulates how manufacturers and suppliers must develop safety-relevant E/E systems in vehicles to minimize the risk of E/E malfunctions that could endanger road users. This is also referred to as so-called functional safety, which is defined in the standard as “the absence of an unreasonable risk due to hazards caused by the malfunctioning of electrical or electronic systems“. The standard, which came into force in 2011 and which is available in a second revised edition since 2018, introduces different risk classes, which are defined by the so-called ASIL, Automotive Safety Integrity Level, A, B, C and D. ASIL A represents the lowest level and ASIL D the highest level of risk and hazard.
Linux and functional safety
In April 2021, the Linux market leader Red Hat publicly announced its intention to develop an ASIL-B certified operating system for vehicles [8]. In this announcement it was stated that the company exida [9], one of the leading experts in the certification of open source, is supporting this. Together, a procedure is to be implemented that ensures continuous certification. This not only certifies a specific version, but also all later updates.
There is a good reason why they only aim for the ASIL-B level: Functional safety cannot be ensured by subsequent test measures alone; rather, architectural precautions must already be taken in the software design: A well-known example of this is a requirement contained in ISO 26262 for “freedom from interference (FFI)”. This describes the absence of cascading errors between individual components that could lead to the violation of safety requirements [10]. Since Linux was not developed with the aim of being used in security-critical areas, there are nested, recursive structures in several Linux components that access shared hardware resources. In such designs, cascading errors cannot be ruled out and freedom from interference is not guaranteed. While extensive testing can still provide some level of confidence in the correctness of such recursive structures, it is not sufficient for ASIL-D.
Software Container in Vehicles
Software containers are a proven means of packaging software to make it executable regardless of the environment. This means that software packed in a container has everything it needs to run in the container, a file system, system libraries, a runtime environment. The software in the container therefore has its own configuration and environment. What initially sounds like a lot of overhead is surprisingly lean and many times faster than for example virtual machines, which each contain their own entire operating system. Linux as an operating system offers the possibility to run software containers. This can be done, for example, with the program “podman” [11], a container engine for running containers on Linux.
But how can a manufacturer keep many software containers up to date over the years, in different vehicle models, in different markets, import new versions or add new containers? Beside the question of how the transmission into the vehicle is technically implemented, there must be a way to securely distribute software containers as IT objects in the vehicles and to put them into operation, all as autonomously as possible and without human intervention.
The open source project “Open Horizon” [12] offers a solution for this: Open Horizon is a platform for managing containerized workloads. As of 2020, Open Horizon is part of the Linux Foundation Edge (“LF Edge”), which hosts all open source projects related to Linux edge computing.
Based on Open Horizon, IBM has developed the IBM Edge Application Manager (IEAM) [13]. This has a backend component that takes over the central control and connection to all vehicles and the IEAM agents which are running in the vehicles. The so-called “onboardig”, the installation and device/vehicle-specific configuration, is fully automated. The software containers are distributed, managed, operated, and monitored on the HPCs of the vehicles via the backend component with the help of the agents. Which containers, which versions, are distributed and put into operation when and how is stored as a set of rules by means of so-called “policies”. Even if the agents on the HPCs lose the connection to the backend, they continue to run autonomously.
Build Once, Deploy Anywhere
What are the advantages of using Linux and software containers? Let’s look at figure 1: We have a uniform Linux operating system with the ability to run software containers on it. We have this ability in the vehicle itself, in the infrastructure surrounding the vehicle and of course in the backend systems. This means that we can flexibly distribute software in the form of software containers. This corresponds to the principle “build once, deploy anywhere”. We can develop and test software in the backend and then use this software in the vehicle relatively easily. For vehicle-to-infrastructure communication, we can move software from the backend into the infrastructure, such as in intelligent traffic light systems, in so-called road-side units, or telco equipment such as MECs (Mobile Edge Computing) units.
Figure 1: Flexible distribution of software using a uniform operating system and middleware layer
This represents an unprecedented level of flexibility. The associated standardization through the abstraction of the application software from the underlying hardware, operating system and middleware layers leads to better maintainability and portability of software.
Success through collaboration
At IBM and Red Hat, we work closely with the entire industry to make the development and operation of “Software Defined Vehicles” successful. The development of an ASIL-B certified Linux operating system at Red Hat is in full swing, which can be followed in the Linux Automotive Special Interest Group [14]. And some companies are playing an active role in this: General Motors and Red Hat, for example, announced their cooperation in May 2022. GM intends to use the future Red Hat In-Vehicle OS in its Ultifi software platform [15].
Work in the various consortia is picking up speed too: The “Scalable Open Architecture for Embedded Edge (SOAFEE)” project [16], which was started by ARM in September 2021 and which several companies have joined, is worth mentioning here. The Eclipse Software Defined Vehicle Initiative [17], which was founded in March 2022, is pursuing a similar goal. Projects founded earlier also show progress, such as ELISA [18], a Linux project dedicated to the use of Linux in safety-critical systems.
With this article I wanted to share some thoughts on the subject of “Linux and containers in vehicles”. Let’s hope that the automotive industry will even more than before jointly promote such open source initiatives in order to master the growing expenses for vehicle software development and maintenance.
About the author
Hans Windpassinger is within the “Global Manufacturing Industries” team in IBM Technology responsible for the topic “Connected Products & Services”. One of his focal points is the “Software Defined Vehicle”.
Literature
[1] Burkacky, O. et al, McKinsey: Rewiring car electronics and software architecture for the ‘Roaring 2020s’, online: https://www.mckinsey.com/industries/automotive-and-assembly/our-insights/rewiring-car-electronics-and-software-architecture-for-the-roaring-2020s, accessed 13. August 2022
[2] Heise online: Linux wird 30: Erfolgsfaktoren damals und heute, online: https://www.heise.de/hintergrund/Linux-wird-30-Erfolgsfaktoren-damals-und-heute-6193046.html, accessed 13rd of August 2022
[3] Red Hat, Inc.: Our Company – Building a better foundation for the future of IT, online: https://www.redhat.com/en/about/company, accessed 14th of August 2022
[4] SUSE Software Solutions Germany GmbH: Innovate Everywhere, online: https://www.suse.com/company/about/, accessed 15th of August 2022
[5] Connected Vehicle Systems Alliance (COVESA): About COVESA, online: https://www.covesa.global/about-covesa accessed 14th of August 2022
[6] Automotive Grade Linux: About Automotive Grade Linux (AGL), online: https://www.automotivelinux.org/about/ accessed 15th of August 2022
[7] International Organization for Standardization: ISO 26262:2018 Road vehicles — Functional safety, Part 1 – Part 12, zu beziehen über https://www.iso.org/, accessed 12th of August 2022
[8] Red Hat, Inc.: Red Hat Sets Sights on Delivering the First Continuously Certified Linux Platform for Road Vehicles, online: https://www.redhat.com/de/about/press-releases/red-hat-sets-sights-delivering-first-continuously-certified-linux-platform-road-vehicles, accessed 15th of August 2022
[9] exida.com LLC: Who we are, online: https://www.exida.com/Company/About, accessed 16th of August 2022
[10] ZVEI – German Electrical and Electronic Manufacturers’ Association: Best Practice Guideline – Software for Safety-Related Automotive Systems, 2016, online:
https://www.zvei.org/fileadmin/user_upload/Presse_und_Medien/Publikationen/2016/August/Software_for_Safety-Related_Automotive_Systems__Best_Practice_Guideline_/Software-for-Safety-Related-Automotive-Systems-Guideline-ZVEI-Stand-2016-12.pdf, accessed 15th of August 2022
[11] podman: Manage pods, containers, and container images, online: https://podman.io/, accessed 12th of August 2022
[12] LF Edge: Open Horizon, online: https://www.lfedge.org/projects/openhorizon/ accessed 15th of August 2022
[13] IBM Cooperation: IBM Edge Application Manager, online: https://developer.ibm.com/components/ibm-edge-application-manager/, accessed 11th of August 2022
[14] Automotive SIG, The CentOS Automotive SIG, online: https://gitlab.com/redhat/automotive/automotive-sig/, accessed 14th of August 2022
[15] General Motors: Newsroom: General Motors and Red Hat Collaborate to Trailblaze the Future of Software-Defined Vehicles, online: https://news.gm.com/newsroom.detail.html/Pages/news/us/en/2022/may/0510-redhat.html accessed 16th of August 2022
[16] Scalable Open Architecture For Embedded Edge (SOAFEE) – Special Interest Group (SIG), online:https://soafee.io/about/charter/ accessed 15th of August 2022
[17] Eclipse Foundation: Eclipse Software Defined Vehicle Initiative, online: https://sdv.eclipse.org/ accessed 14th of August 2022
[18] The Linux Foundation Launches ELISA Project Enabling Linux In Safety-Critical Systems, online: https://www.linuxfoundation.org/press-release/the-linux-foundation-launches-elisa-project-enabling-linux-in-safety-critical-systems/ accessed 16th of August 2022
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
