Software-defined vehicles (SDVs) have a flexible platform that allows vendors to deliver vehicles with different characteristics as well as provide updates to improve performance and security. Thus, such a hardware platform can support different requirements and services based on the software installed and enabled on the platform.
SDV raises the complexity of automotive designs because of the nature of the system that includes more applications. Typically, the software runs on system-on-chip (SoC) processors, and multiple engine control units (ECUs) further increase the complexity of the system. Much of this software must meet stringent standards like ISO 26262, ASIL B, and ASIL D. This includes the operating system.
I talked with Dr. Moritz Neukirchner, Head of Software Architecture at Elektrobit, to get more insights into SDVs that utilize an automotive-grade operating system.
Before we get into the Automotive OS, we’ve seen a lot of talk about software-defined vehicles. How do you define the term?
In the past, it may have referred to simply having functions that heavily rely on software in a vehicle. Today, the definition is clear: It’s a vehicle in which you can change or update features and functionality by updating its software. Changes in technology—including high-performance processors, advanced cybersecurity capabilities, and cloud connectivity—make this possible.
We’ve also heard about carmakers and their Automotive OSes, like the VW.OS and MB.OS. How do these differ from the Linux and Android operating system or a real-time operating system like QNX? How do they work?
The Automotive OS we’re talking about is different than Android Automotive or the Blackberry QNX OS you may be familiar with. It’s not just an operating system. An Automotive OS is the harmonized software platform that will control all systems in a carmaker’s next-generation vehicles.
Software-defined vehicles require a complete overhaul of their software-hardware underpinnings. We see a reduction in the number of ECUs to fewer and more powerful controllers. In addition, each carmaker is creating a standard software platform for their SDVs—its “Automotive OS”—to centrally manage the software of a vehicle. This standardized/reusable approach represents a significant departure for the industry and will enable carmakers to bring more complex software features to market more quickly—even for vehicles that have already been sold.
To put it in the simplest terms, the Automotive OS abstracts the complex vehicle network of ECUs as a single device that can then be managed, supervised, and updated as one entity. The goal is to decouple lifecycles of software functions and the vehicle, thereby enabling what we refer to as a “software-defined vehicle.”
Why an Automotive OS? What function does it serve?
Traditionally, software was a part of an ECU that was tailored to meet a specific set of functionalities for a vehicle, say infotainment or power windows/door locks. 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 enable 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’s 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. That is, 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.
What specific software is in the typical carmaker’s OS?
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 lifecycle 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, eliminate domain-specific variants, and 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.
How much of this software does Elektrobit provide? Which software products?
We provide a broad line of software and engineering services that can help reduce the burden on carmakers as they tackle their Automotive OSes.
Our core products include the EB tresos and EB corbos lines, which form the foundation of the Automotive OS, along with our security software, EB zentur, and network-management software, EB zoneo. Our software supports both Classic AUTOSAR and Adaptive AUTOSAR, standards for E/E architectures that many automakers are adopting. Elektrobit is a founding member of the AUTOSAR consortium and has deep expertise in development and implementation.
We also recently announced an open-source version of EB corbos: EB corbos Linux—built on Ubuntu, based on interest from our customers in open-source options. On top of this, we offer EB cadian for OTA updates plus Argus IDPS (Argus being our security software subsidiary company).
We will continue to develop and refine products for the Automotive OS, as well as collaborate with partners on new value-added offerings.
Which OEMs is Elektrobit working with to enable their Automotive OSes?
We’re working with a number of OEMs, both established carmakers and some that are new to the business. One that we recently publicly announced is JLR, which is working with Elektrobit to enable its next-generation EVA Continuum electrical architecture. The new architecture will be featured in JLR’s full line of vehicles starting in 2024.
JLR selected Elektrobit as part of its initiative to drive standardization and predictability in the software platform for the new architecture, which will enable it to bring new vehicles quickly and efficiently to market. Using Elektrobit software and engineering services, JLR has been able to accelerate production of EVs and other next-generation cars.
Elektrobit software and solutions have enabled JLR to develop ECUs more easily, reducing both development time for innovative new features and hidden costs, without compromising quality, safety, and security.
There seem to be a lot of challenges for OEMs these days around making the transition to software. What are the issues?
The issues depend on the OEM. Some are dealing with technology issues, others with organizational ones. From a technology standpoint, one challenge is that we’re looking at a largely fragmented landscape, with many different suppliers.
One of the promises of SDVs is reduced time-to-market. Therefore, each carmaker is looking at ways to streamline and accelerate sourcing, development, and integration to get to production more quickly. This is where virtualization is important. As well as collaboration. New types of development practices.
In some companies, the challenges are more organizational than technical. Carmakers have operated in a siloed fashion for decades, with each ECU sourced from a different supplier. They’re rethinking everything. They’re looking the over-the-air, service-oriented architecture and ways to minimize or totally eradicate repetitive testing and qualification.
How important are partnerships and collaboration?
Partnerships and collaboration are extremely important, and we see this increasing.
We believe there is benefit in leveraging frameworks like SOAFEE, Eclipse SDV, as well as in embracing open source to accelerate innovation. We actively contribute to these projects and our products like EB Linux or EB hypervisor are based on open source.
However, while most of our customers are also embracing frameworks, standards, and more collaboration, they’re doing so as they create their own Automotive OSes. These platforms are built on top of established solutions and standards as AUTOSAR. And for this, many are looking to experts like Elektrobit to provide the expertise—we’ve been working with AUTOSAR since its inception—and software components for these.
How are the different types of carmakers—established OEMs versus upstarts—approaching SDV development?
Obviously, established OEMs are rethinking everything, so it’s both a technology and organizational challenge.
Tech companies getting into the automotive business and startups have their own challenges. They’re also looking to Elektrobit for expertise. An example of a great partnership to build a new-generation, software-defined vehicle, from the ground up, is our multi-year collaboration with Sony... and now Sony Honda Mobility (SHM).
Elektrobit created the innovative software architecture for the SHM AFEELA prototype, enabling SHM to leverage the entire Sony ecosystem to create a new level of user experience. Elektrobit developed the cockpit system, including software for the Qualcomm high-performance computing (HPC) processors and the software stack up to the UX design powering all cockpit displays.
In addition, Elektrobit provided integration services for the cockpit system encompassing all software and hardware components and applications from Sony and its partners.
