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”.

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.