The evolution of automotive E/E architectures continues, with increasing demand for customer-facing functionality and the availability of more powerful hardware to implement these features. Previously, classic automotive E/E architectures distributed functionality across up to 100 Electronic Control Units (ECUs). However, adding more ECUs to a car is increasingly difficult to accomplish. All of the ECUs need space and power, and they contribute to the car’s weight. Not only is there a sheer number of them, but also the wires needed to connect everything which add up to more than 4 kilometers in total. Another challenge that comes with numerous ECUs and the increasing demand for more features is the requirement to update the software that runs on the ECUs. With a central E/E architecture, software updates are deployed through a single channel, a central ECU, which simplifies the update process compared to a distributed E/E architecture.
The demand for consolidation, such as running multiple functions on a single system while still maintaining barriers between the different applications, places substantial requirements on the hardware platform. As well as the software architecture of the whole system.
The answer to the growing need for zonal architectures is that the first designs were deployed in recent years. Arm was one of the pioneers in automotive with its Cortex-A CPU-based solution that made virtualization possible. An example is ICAS1 (In-Car Automotive Server), a central computing system used in Volkswagen’s electric vehicle platform, which powers cars like the ID.3. ICAS1 employs Elektrobit’s hypervisor which is based on the Kernkonzept L4Re Hypervisor for separating multiple software stacks.
Consolidation benefits from virtualization because it allows using existing software, almost, unmodified. This requires a suitable software layer between the hardware and the actual software functionality, a hypervisor.
ECUs are used in cars that operate in environments with humans so safety considerations are of paramount importance. Consequently, robust safety and security measures are implemented, for which real-time applications are essential. While the Arm Cortex-A series is designed for computationally intensive operations, the Cortex-R series excels in real-time applications.
Arm Cortex-R processors based on the Armv8-R architecture, such as the Cortex-R52+, introduce new virtualization capabilities, compared to the previous Armv7-R architecture. With the latest generation of Armv8-R based processors, Arm then goes one step further and combines virtualization with safety. By enabling virtualization on MPU-based processors, real-time conditions are met in the best possible way, and safety requirements are guaranteed to the highest degree. As it focuses on deterministic execution behavior and lock-step cores, the architecture covers both real-time and safety characteristics.
Another cornerstone for ECU consolidation is that Cortex-R processors provide a significant increase in compute capacity compared to previous ECU generations, by clocking up to 1 GHz, and being available in cluster configurations. This increase in capacity allows us to host multiple ECU software stacks from previous generations on one processor.
Thanks to its virtualization capabilities, the Armv8-R architecture can host multiple operating systems, such as classic AUTOSAR instances, on a single core, with the isolation necessary to comply with safety and security requirements.
Example of ECU consolidation. Each virtual ECU (vECU), depicted in the white boxes, runs the complete software stack as used originally on the separate ECU.
This is illustrated in the previous example, where features like the windshield wipers and battery management control, that were previously running on different ECUs, were stacked together into one powerful ECU. The underlying software layer must now ensure that those software stacks do not influence each other. The barrier must be so strong that even safety-related software components are executed and shielded from each other.
To control and orchestrate the separate software stacks, as well as the processor and the hardware, we need operating-system functionality. This can be provided by the L4Re Micro Hypervisor. It works as a software layer between the hardware and the software, isolating the software functions with a strong barrier.
The L4Re Micro Hypervisor provides an abstraction layer between the hardware and the software running on the top of it. By putting the software stacks in so-called virtual machines (VMs), the hypervisor isolates the software stacks while they continue to run in their existing environment, including the operating system they are implemented in. So, there is no need to revamp their software architecture. For example, a software stack previously running in the ECU controlling the wind shield wiper can be taken as a whole and with some minimal adaptations.
The processor architecture provided by Armv8-R and the hypervisor enable the isolation of software stacks from each other while keeping their safety and security functionality.
The abstraction layer implemented by the hypervisor has several benefits for the car and hardware manufacturers, and software providers. The most important advantages are:
All these benefits also reduce dependency on a specific hardware implementation, as well as development costs due to the re-implementation of functionality for a new hardware platform. Therefore, an abstraction layer facilitates the reuse of software components, helping to save time and resources, and ultimately accelerating the time-to-market.
A common interface for the abstraction layer also has the advantage of allowing parallel development. With interfaces independent of a particular hardware, the hardware does not yet need to be available when the software development process starts. Furthermore, software development can also happen in other environments, such as the cloud with its virtual appliances. A good example is the Arm Virtual Hardware (AVH) platform that offers virtual variants of hardware platforms.
Focusing on the role of the hypervisor and the interfaces it offers to the software component, we must first look at the hypervisor itself. Its tasks like that of the L4Re Micro Hypervisor, to provide a defined environment for the software stacks to run in, as well as to allow the necessary access to resources. Typically, this means access to hardware devices by means of their device memory and interrupts. However, if multiple VMs require service of the same device, the hypervisor is supposed to provide multiplexing capabilities for a device. So, each VM can use the device in a shared fashion.
A key challenge here is how the VMs access the multiplexed device. One option is the hypervisor emulating the hardware device which the VM expects, like it would have access to the real device. Although this is possible, implementing this emulation is cumbersome and error prone. A better approach is to use an interface specifically made for VMs and hypervisors: VirtIO.
VirtIO is the standard protocol for sharing resources between VMs and hypervisors. It is specifically made for this setting. VirtIO is already extensively used in virtualization in the server area, and the OASIS open group is focusing on the standardization of VirtIO drivers.
When using VirtIO, a VM does not need to have specific drivers for the platform it is running on, nor does the hypervisor need to provide emulation for the driver a VM might be using. While VirtIO is often used in servers, it is still new to the small-scale embedded space, although it has the same benefits here. The L4Re Hypervisor Family uses VirtIO as its primary device virtualization technology.
VirtIO enables flexibility in the deployment of software stacks that are hosted in VMs because they are moved far easier between different hardware platforms and hardware configurations. Such hardware-independent VMs allow the deployment of VM-based workloads more dynamically and flexibly, as the software-defined vehicle (SDV) envisions.
For more insights into device virtualization, refer to the Armv8-R device virtualization white paper from Arm.
Even more flexibility with Cortex-R82 and the L4Re micro hypervisor: not only embedded OSS, but also general-purpose OSS like Linux
In the Arm processor portfolio, the already mentioned Cortex-R52+ processor implements the Armv8-R Profile, which targets safety and real-time use cases by providing deterministic execution characteristics. The Cortex-R52 and Cortex-R52+ are the first to offer virtualization capabilities on the R Profile, enabling multiple independent software stacks to run on one processor. Cortex-R52 and R52+ are 32-bit processors.
They have a 64-bit variant, Cortex-R82AE: the newly introduced 64-bit Armv8-R-profile processor targeting automotive safety use-cases. One of the outstanding new features of the Cortex-R82AE is the ability to host both, general purpose operating systems, such as Linux, as well as RTOS systems, through providing support for both MMU and MPU based protection in a VM on exception level 1 (EL1). The hypervisor level (EL2) keeps using the MPU, providing deterministic memory access for the hypervisor, the real-time and safety applications, and the VMs.
The microkernel-based open source L4Re Micro Hypervisor supports the 32-bit Cortex-R52 and Cortex-R52+, as well as the 64-bit Cortex-R82AE. It acts as a host for VMs using either the MPU or the MMU, as well as native applications, called MicroApps, that run next to VMs.
L4Re MicroApps allow to implement small and trustworthy software components without the need to run a whole operating system including applications in a VM. The companion L4Re Hypervisor also extends the support to Armv8-A processors with the same flexible capabilities.
Figure 2: Example of a zonal ECU system using Arm Cortex-R82AE, which runs the L4Re Micro Hypervisor hosting two MPU-based VMs as well as a Linux VM.
L4Re MicroApps monitor the VMs and provide VirtIO services. In our whitepaper “MCU Virtualization - The L4Re Micro Hypervisor”, we specifically delve into virtualization on MPU-based processors for both 32-bit and 64-bits variants. We also show how the L4Re Micro Hypervisor’s virtualization capabilities help to build flexible and future-proof automotive systems, which enables the SDV.
Armv8-R based processors and MPU-based hypervisors, such as the L4Re Micro Hypervisor, provide a performant foundation for safe and secure zonal ECU implementations. The open source L4Re Micro Hypervisor is now available at https://github.com/kernkonzept.