Interview: Vehicle OS as an Enabler for the Software-Defined Vehicle
Interview by the German online trade journal all-electronics with Dr. Günther Heling, Head of Embedded Software and Systems at Vector. What does Software-Defined Vehicle, SDV, actually mean and what role does the Vehicle OS play in this? What role does middleware play? Why is now the right time to standardize this software? A Vehicle OS represents a holistic ecosystem for automotive software. The projects that are currently being developed are based on different approaches and solutions. Is standardization desirable here, or is it perhaps already too late? And doesn't standardization contradict the need for a quick solution?
all-electronics: Dr. Heling, when it comes to software for vehicles, the buzzwords Software-Defined Vehicle, SDV and Vehicle OS are currently circulating. What is your opinion on the term Software-Defined Vehicle - has a common understanding already developed?
Dr. Günther Heling: The term Software-Defined Vehicle is used quite uniformly: It refers to a new generation of vehicles whose behavior is only partly defined by the mechanics and the installed hardware. Instead, the vehicle's behavior and range of functions are determined mainly by the software. The software is distributed between the vehicle and the cloud and is kept up to date over the lifetime of the vehicle. In the architecture of an SDV, two to five central computers, high-performance computers or HPCs for short, perform the competitively differentiated computing with high resource requirements at the top level. This is also where the exchange with complementary functions in the cloud takes place. At the next level, two to four zone computers transform service-oriented communication into signal-based communication and connect the large number of functional control devices. These are seen as intelligent sensors or actuators with only minor competitive relevance and can be imagined without OEM-specific characteristics.
Definition: Operating System in the Vehicle | Vehicle OS
all-electronics: The term "Vehicle OS" is rather misleading, however, since it is not an operating system in the true sense of the word. How do you define the term?
Dr. Günther Heling: The Vehicle OS is a central component in the SDV: On the one hand, it consists of runtime software in the vehicle and in the cloud. This runtime software, known as the SW base layer, provides the framework for the application software with its basic functions. There are different versions of the SW base layer in the vehicle: On the central computers, the associated SW base layer has the largest range of functions. For example, for the central collection of security-relevant data or for controlling software updates in the vehicle. The crucial factor is that all SW base layers in a vehicle and in the cloud are coordinated with each other. In other words, their functions complement each other and support efficient and transparent communication between the elements of the application software.
Secondly, in addition to the SW Base Layer, the Vehicle OS also includes a development environment called the SW Factory. The SW Factory supports the entire developer's journey with a high degree of automation in the areas of Continuous Integration (CI), Continuous Testing (CT) and Continuous Deployment (CD). Without a powerful SW Factory that supports development on all hardware platforms and all classes of ECU, it will not be possible to leverage the potential of a Vehicle OS.
The Chances for a Standardized Vehicle OS
all-electronics: If the Vehicle OS only provides basic functions, then there is no competitive differentiation. It is therefore obvious that different vehicle manufacturers and suppliers will use a unified Vehicle OS. This is not currently the case. How do you see the chances for a standardized solution, and how could this be achieved?
Dr. Günther Heling: This is indeed a critical point, since competitive differentiation should be expressed in the application functions beyond the Vehicle OS. On the other hand, the Vehicle OS represents the backbone of the software as a whole, and so it is understandable that vehicle manufacturers want to design and master this backbone. However, individual design can also be realized very efficiently through adaptable standard functions and functions developed specifically in individual cases on the basis of a standardized structure.
all-electronics: However, standardization often contradicts the need for fast and flexible solutions.
Dr. Günther Heling: Not necessarily. Standardization at an upper architectural level should succeed quite quickly and would already bring a great advantage. Currently, not even the term Middleware is commonly understood. The lack of a definition of corresponding interfaces makes it difficult to implement reusable software modules, such as those for collecting data in the vehicle or for updating an ECU network. With the high reuse rate made possible by standardization, we ultimately achieve the required high development speed.
Vehicle OS as Open Source?
all-electronics: An Open Source approach with the code-first idea could be a very good solution here...
Dr. Günther Heling: Basically, yes. Open Source always works well when there are many who have the same need and an organization professionally manages and administers the Open Source project. The challenge in this case is that the needs are somewhat different in detail, that the resulting software must satisfy the highest quality and security requirements, and that the users must be sure that the software will be maintained and expanded in the long term. The latter not only on one development line, but on all variants that are actively in use.
all-electronics: Currently, however, many Vehicle OS projects are already under development. Is it even too late to strive for standardization?
Dr. Günther Heling: I think that the time is just perfect: Through the current projects, initial experience is available and the goals that are being aimed for have already become much clearer. In addition, it is becoming obvious that many detached activities are not the answer to everything. And we should be aware that we are only at the beginning with regard to Vehicle OS. In addition, the conversion of ongoing projects is facilitated by the use of common core elements - such as the AUTOSAR platforms Classic and Adaptive or even a POSIX OS.
SW Factory as Part of the Vehicle OS
all-electronics: You mentioned that a SW Factory is part of a Vehicle OS. What is the reason for this close connection?
Dr. Günther Heling: A Vehicle OS crosses all domains - from infotainment, body, chassis and powertrain to ADAS and AD - as well as the two worlds in-vehicle and in-the-cloud. Short development cycles are required not only in each of these domains, but also across domains. Short cycles are only achievable with a high degree of automation in configuration, integration and testing. This includes classic build chains, but also ways of translating the various description languages used, for example, in application development, communication, virtualization, basic software configuration, testing and deployment into one another as automatically as possible. This is an enormous task that is currently occurring in many places at the same time. It seems to me that it would make sense to join forces here as well. This is all the more successful if the underlying SW framework, i.e. the SW base layer, has a uniform design. This results in a close connection between the SW base layer and the SW factory - and thus a Vehicle OS as a whole, including a powerful ecosystem.