On the Way to a Software-defined Vehicle

Today's luxury vehicles contain up to 100 different Electronic Control Units (ECUs) that communicate via several different bus systems, which in turn are interconnected with gateways and central computers. Car manufacturers are now beginning to replace a large number of individual ECUs with smaller more powerful control units, Figure 1. This will result in a more centralized E/E architecture in the future, consisting of a small number of so-called High-performance Computers (HPCs) surrounded by smaller ECUs for the peripherals.

Since these smaller ECUs are assigned to different zones in the vehicle, the term "zonal architecture" has become established [1]. HPCs enable the adoption of proven information technology standards from the IT sector, such as virtualization and software containers, into the vehicle. However, HPCs also require a powerful operating system, such as Linux.

Engineers have been using the principle of virtualization in cars for some time. Now the first companies are beginning to bring software containers into the vehicle. Furthermore, Linux is gaining in importance. The Linux operating system is not only the best technical basis for the "containerization" of software - automotive manufacturers particularly appreciate the openness of the code in terms of sources, which gives them flexibility and avoids vendor lock-in.

A uniform operating system can most certainly be based on Linux; it runs in the vehicle and also in the vehicle-related infrastructure such as charging stations and traffic light systems. In addition, Linux is established in the cloud and within data centers of car manufacturers, so that flexible distribution of software in containers would be permitted from the back end via the vehicle to systems in its immediate environment. Figure 2 illustrates this approach of a unified Linux-based platform that extends from the vehicle to an edge computing system and into the cloud, turning the slogan "build once, deploy anywhere" into reality. This promises full flexibility with higher standardization, but also better maintainability and portability of software. It also allows the application software to be abstracted from the underlying hardware.

But these advantages do not just happen, they must be worked out: The familiar Linux distributions are only suitable for use in vehicles to a limited extent. They have to be adapted to the special requirements of automobiles and road traffic. For example, boot times must be shortened, and real- time capabilities improved.

For Linux to be used for safety-critical applications, it must be qualified in accordance with ISO 26262 [2]. This is only possible with Linux up to a medium safety criticality. The Automotive Safety Integrity Level (ASIL), a scheme for risk classification, is divided into four levels, (A to D) and is comprised of several measures that must be complied with to reach a specific safety level. ASIL D represents the highest risk here, requiring the most measures. Safety experts believe that a maximum of ASIL B can be met with Linux. The Linux market leader Red Hat recently announced that it is currently developing an ASIL-B certified Linux distribution [3].

Why only ASIL-B? Here, too, the well-known sentence applies that quality cannot be tested into a software product post-release. Functional safety cannot be ensured by retrospective testing measures alone. Instead, architectural provisions must already be made in the software design. However, Linux was not developed to support applications used in safety-critical areas.

Experts expect new software technologies to help improve the high effort required to integrate onboard software into the vehicle: In "old" E/E architectures, one of the most important development tasks was to integrate the many ECUs. It was therefore a matter of integrating different hardware boxes that communicated with each other. In terms of effort, the software integration of the ECUs was comparatively moderate. The main work was to merge the different hardware devices into a unified, flawlessly functioning system. But this relationship is now changing: technologies, processes, methods, and tools that support software integration best are now the key to success [4].

Automotive manufacturers and their suppliers also have a lot to achieve in the field of processes, methods and tools: Agile development approaches have largely become established, and automotive software is also developed in this agile way. Nevertheless, traditional V-model-oriented development processes can still be found. This is because it enables the requirements of standards such as the aforementioned ISO 26262 [2] to be met. These two worlds must be reconciled.

Additionally, the area of Artificial Intelligence (AI) is taking a more central role for car manufacturers. AI development also follows a procedural model, with its tools, methods, and processes, in which data preparation and data management for machine learning are key.

Looking at the development of AI for driver assistance systems and automated driving, the data required comes from three different sources:

The preparation of all this data is time- consuming. If the data comes from test vehicles, synchronously recorded CAN bus, camera, lidar, and radar data, stored in Solid-state Drive (SSD) systems specially designed for vehicle operation, need to be removed from the vehicles and taken to copying stations which are then connected via broadband to the cloud or directly via WAN/LAN to the company's own IT infrastructure. The many terabytes are transferred and then copied for so-called labeling at other locations in low-wage countries. There, labels needed for machine learning are tagged onto the material. Experts estimate that more than 200 h of manual labeling is required for 1 h of video material. This labeled material is then used for AI development, verification, and validation. In many cases, all of this happens in the cloud. However, at the latest when the hardware directly from the vehicle comes into play, development and testing activities shift back to the R&D lab, such as for Hardware-in-the-Loop (HiL) testing. HiL test racks are complex and adapted to specific hardware. To supply such HiL stations with data sufficiently and rapidly, this type of data is kept available locally for quicker processing.

Here, engineering IT is now challenged in particular, to ensure high productivity of the development teams employing hybrid and AI-based solutions for data management: "Hybrid" to dynamically enable scaling of computing power and data storage from the local data center to private and public cloud solutions and to allow engineers easy access to their data - regardless of where this data is located. "AI-based" to largely automate labeling and efficiently classify the unstructured data.

A software-defined vehicle is highly networked and constantly communicates with other vehicles, with the surrounding infrastructure, and with the cloud or the OEMs' back end systems. The expansion of 5G technology now enables more and more data to be exchanged at the edge. For this to be realized effectively, not only must a stable 5G radio network be available, but back end systems should also be designed with equivalent performance in vehicle-to-back end communication.

The back end must not only communicate with thousands of vehicles in parallel, but the expectation is that it must respond quickly. Low latency resilience is essential for autonomous driving applications. Car manufacturers are deploying such back end systems in geo-dispersed regions to meet local regulatory requirements, but also to provide good coverage with low latency.

Increased connectivity will enable new software versions to be pushed to the vehicle wirelessly, hence over the air. This enables automakers to keep their vehicles up to date even after they have been sold. Creating the technical prerequisites for software updates in the vehicle is also necessary due to new regulatory requirements: OEMs must be able to patch security gaps (vulnerabilities) rapidly through software updates. This is based on UNECE Regulation R156 [6], which compiles the requirements for vehicle type testing. The technical requirements for meeting R156 are defined by the ISO 24089 standard [7], which is still in draft status.

The software-defined vehicle must be secured against hacker attacks. The fact that external attacks on vehicle electronics are conceivable has been known for well over ten years. At the same time, the number of technical possibilities, points of attack, and types of attack has equally increased in recent years. As a result, car manufacturers are upgrading to protect their vehicles, but this is a multi-layered and complex undertaking. It starts with protective measures in the vehicle electronics and extends to complete real-time monitoring of vehicle use by so-called Vehicle Security Operation Centers (V-SOCs). The security experts in the V-SOCs can then intervene when they detect an attack. They initiate appropriate countermeasures.

One of the main requirements of UNECE Regulation R155 [8], which applies to every automobile manufacturer, is the establishment and operation of a cybersecurity management system. For this purpose, it is imperative to have a holistic overview, not solely focusing on its development but also the production and operation of a vehicle up to the point of disposal. The technical requirements for compliance with R155 are defined in ISO 21434 [9], which was published in August 2021.

This should be an insight into the world of the software-defined vehicle. The development and operation of these automobiles is a major task for which many different challenges must be solved. No car manufacturer and no supplier can do this alone. It requires many highly specialized companies working cooperatively in an appropriate manner to master the tasks. At IBM, this is done in close cooperation with the entire industry as well as with renowned technology companies.

As a showcase project, the collaboration between IBM and Continental is a prime example: Here a modern solution for the development of autonomous vehicles in a co-location was pursued [10]. The goal was to increase the performance of Nvidia DGX systems for AI training by making more data available to the systems faster through parallel processing. Working with various implementation and hosting partners, Continental, through IBM's Spectrum Scale clustered file storage, built the systems so that 14 times more AI experiments are now possible compared to previously. This shows how important cross-collaboration is for efficiency in this area.