Automotive operating systems (OSes) are becoming increasingly popular in the industry. OEMs are announcing their own versions, such as VW.OS and MB.OS, and multiple open-source initiatives are defining the software-defined vehicle. However, there is neither a widely accepted definition of an automotive OS nor a consensus on the functionality that it provides or the concepts that it implements. It is not an operating system in the traditional sense.

In the automotive industry, software is claiming an increasingly large portion of value creation. A 2021 study by Berylls projected that the software market in automotive will triple by 2030. While this comes along with a significant increase in software complexity, the productivity gains cannot keep pace. This growing complexity puts high pressure on development cost and, more importantly, on development capacities. It reduces the ability to quickly innovate and iterate. EV startups and other new entrants are putting even more pressure on innovation cycles—with Tesla serving as the industry’s role model for rolling out new software functionality to vehicles that have already been sold.

To address this productivity issue, changes in architecture—in the way that software is sourced, built and maintained—is required. This is where the automotive OS comes into play.

What is the automotive OS?

An automotive OS is a software platform that abstracts the complex vehicle network of electronic control units (ECUs) as one device and then manages, supervises, and updates this device.

Applications and functions are built against the APIs of the automotive OS to ensure maximum portability and maintainability and form the ecosystem of the automotive OS.

Seeing vehicles as devices

Traditionally, software was a part of an ECU that was tailored to meet a specific set of functionalities for a vehicle. However, as the relevance of software grew, common software parts of these ECUs were standardized to allow for reuse and harmonization of system concepts and semantics. Standards, such as OSEK and AUTOSAR, emerged to allow for higher degrees of software integration and reuse across different OEMs.

Despite this standardization, each ECU is still sourced and built individually. As a result, there is a variety of middleware implementations and concepts used across different function domains within a single vehicle. This concept becomes limiting as the degree of software integration, interdependencies among functions and number of updates increase. To address these issues, architectural concepts, such as service-oriented communication and virtualization technology, were introduced. However, the required productivity gains have yet to be achieved.

The automotive OS aims to eliminate variants of middleware technology across different ECUs, i.e., to use the same implementation and harmonize system concepts and semantics on a vehicle level, resulting in a harmonized vehicle abstraction for a given vehicle platform.

The fourth value proposition is not as visible in the automotive software market yet. It is about separating the life cycles of the vehicle platform, the software platform and the function itself. This is the crucial point to bring an automotive OS to success.

Defining layers

To serve the value proposition, the automotive OS must go beyond established middleware technology. The automotive OS abstracts the complex network of ECUs as one device. It manages, supervises and updates this device.

The high-level architecture of the automotive OS includes four layers: the core software layer, the middleware layer, the platform services layer and the applications layer. The core software layer includes hardware-dependent software, such as operating systems and virtualization technology; the middleware layer manages application software and its life cycle on an ECU or partition; the platform services layer brings the control plane of the software platform to a vehicle-wide level; and the applications layer is where applications are executed.

Harmonizing these layers for a complete vehicle platform provides significant advantages in terms of development efficiency, software updates and software maintenance. The key is to eliminate variants of middleware technology across different ECUs, to eliminate domain-specific variants and to harmonize system concepts and semantics on a vehicle level. This on-board software is complemented by a cloud-based CI/CD and simulation and validation framework to enable scalability of software development processes across stakeholders.

The software platform ecosystem challenge

As mentioned earlier, the automotive OS’s fourth value proposition is about separating the life cycles of the vehicle platform, the software platform and the function itself. This means upgrading the software platform of a device that has already been sold, which enables new revenue streams by selling new software functions to owners of existing devices. When that software platform is upgraded, time and resources no longer have to be dedicated to maintaining older versions of software. This decoupling of the life cycle of the software platform from that of the hardware platform also reduces the number of software platforms to concurrently maintain.

Additionally, decoupling the life cycle of software applications from that of the software platform permits the integrator to update the software platform without dropping compatibility to existing applications, creating an ecosystem of apps and reducing maintenance efforts. This concept is essential for creating an ecosystem of functions.

Bottom line

Software is becoming the defining factor for innovation in the automotive industry. With this, software complexity is rising and crippling innovation speeds and development productivity.

The automotive OS is the industry’s best bet on getting this complexity to be manageable. It aims to harmonize software across the vehicle, to reduce the notoriously high number of variants, to harmonize development practices and interfaces and to make maintenance tractable.

In the long run, the promise of the automotive OS is to create an ecosystem of functions that can be developed and maintained independently of the underlying vehicle, such that innovation cycles of hardware and software can be uncoupled.

By: DocMemory
Copyright © 2023 CST, Inc. All Rights Reserved