Automotive real-time virtualization: An embedded hypervisor perspective

The automotive industry is witnessing unprecedented transformation, and safety-critical microcontrollers too are evolving rapidly. One of the key advancements is the introduction of embedded real-time virtualization technology, leveraged by Elektrobit’s EB tresos Embedded Hypervisor. This technology is designed to optimize resource utilization, enhance safety, and reduce costs. Introducing virtualization technology for automotive, safety-critical microcontrollers, and the software environment to leverage the possibilities of Elektrobit’s EB tresos Embedded Hypervisor.

What is EB tresos Embedded Hypervisor?

EB tresos Embedded Hypervisor is a separation kernel for real-time applications. It executes multiple Virtual Machines (VMs) on a single microcontroller and allows multiple operating systems (OSs) and AUTOSAR stack instances to be executed in parallel on a single microcontroller (MCU) using virtualization features of modern MCUs. It allows you to save hardware costs when consolidating. EB tresos Embedded Hypervisor is designed to deploy mixed-criticality applications. Key features include:

• Mixed-Critically Applications: Integrates quality management (QM) and safety applications in isolated VMs, ensuring Freedom From Interference (FFI).
• Efficient Communication: Provides controlled communication between VMs via shared memory, independent of the guest OS.

Benefits:

• Resource optimization: Utilizes Arm Armv8-R architecture cores’ compute capabilities by dedicating cores to VMs with real-time requirements while sharing others.
• Cost and Resource Savings: Deploying multiple applications on a single ECU reduces costs, cabling, weight, and energy.
• Legacy Application Integration: Minimal adaptation needed to migrate legacy ECUs into VMs.

For example, Quality Management (QM) applications and safety applications can be integrated in separated isolated VMs and leverage microcontroller hardware support to establish Freedom From Interference (FFI) among VMs.

In addition, to ensuring FFI between VMs, EB tresos Embedded Hypervisor also provides controlled, efficient communication between VMs via shared- memory technology, whilst remaining independent of the guest OS and guest bare-metal application.

Our customers will optimize resource utilization, that is, getting most out of the Arm cores’ compute capabilities, by executing VMs with real-time requirements on dedicated cores while other VMs efficiently share cores on the same microcontroller.

The compute power of Arm Cortex-R52+ cores for real-time applications in ECUs has advanced to a point where they can easily support multiple applications per Central Processing Unit (CPU) or a cluster of CPUs, meeting the stringent low-latency requirements of automotive safety-critical applications. Deploying multiple applications on a single ECU saves costs, resources, cabling, weight, and energy, all of which are crucial for sustainable modern vehicles.

While integrating legacy applications on a shared base software, virtual machines (VMs) enable the reuse of existing applications with minimal adaptation needed to migrate a legacy physical ECU into a VM. VMs are essential for the Software Defined Vehicle (SDV) because Software-defined means that you can change the key functions or nature of the vehicle by changing its software. You can re-define the value of the device. 

This makes these cores an ideal match for Elektrobit's EB tresos Embedded Hypervisor, as they offer enough resources to schedule two or more VMs on the same cores. This enables:

• Better resource utilization
• Better energy efficiency
• More applications per core/cluster

Figure 1 shows how EB tresos Embedded Hypervisor allows to assign VMs to Arm Cortex-R52+ cores. The integrator chooses whether a (the two dashed boxes on the left), or if it shares them with other VMs (the dashed box on the right). Fixed assigned cores avoid scheduling overhead and are therefore favorable for VMs containing applications with real-time requirements which do not leave room for VM scheduling overhead.

VMs that share cores maximize the utilization of cores in a time-multiplexed manner, provided the utilization of all VMs, plus scheduling overhead, does not exceed the available computation power of a core.

^{Figure 1: EB tresos Embedded Hypervisor enable bus-level separation and runtime hypervisor function in parallel on the same microcontroller}

Furthermore, VMs which are isolated via a separation kernel build a foundation to update applications on several (virtual) ECUs, independently of each other.

^{Figure 2: Independent binaries and controlled communication.}

Figure 2 shows that each VM is a separate binary file that can be flashed and overwritten independently. Previously, updating one Application Software Cluster required uploading a large binary file for the entire ECU. Instead, with the usage of a real-time embedded hypervisor, only the VM containing that cluster needs to be uploaded.

Additionally, these VMs can be built and integrated by separate teams independently, reducing the alignment overhead for software teams located in different time zones and locations. Figure 2 illustrates two individually built VMs, with the "hammer" shape between them representing the inter-VM communication library provided by the EB tresos Embedded Hypervisor. This library enables applications in different VMs to communicate across VM boundaries in a controlled, automotive safety-compliant manner.

Integration with Elektrobit’s FOTA solution

Elektrobit is in the process to further improve the cross-product integration between EB tresos.

Embedded Hypervisor and its Firmware Over The Air (FOTA) product, EB tresos OEM FOTA Handler. These two elements are integrated to enable easy software update experience on top of the fact that VMs represent a more granular building block as the foundation of updates.

The integration will enable the following ECU software update use cases:

• The FOTA client runs in each VM and updates only that respective VM, that is, the customer integrates VMs from external suppliers and therefore does not control the content of those VMs.
• The FOTA client runs in one dedicated VM which updates all the VMs and also the HV. In other words, our customer integrates VMs which are completely in the control of the customer. Therefore, VMs can be updated externally, eliminating the need to install FOTA clients in each VM.

Software updates need to be possible any time throughout the lifecycle of the ECU, e.g., during prototyping and development, at production, prior to the shipping date, and of course in the field when the end customer uses the car. While we identified these use cases, the software update strategy is by default dependent on the integration of the Elektrobit’s Hardware Security Module products, insight into this topic is in the following section.

Integration with Elektrobit’s HSM products

Numerous real-time software applications depend on cryptographic extensions, as with key management. These cryptographic services are provided through a Hardware Security Module (HSM), and Elektrobit has a dedicated product called EB zentur to support and offer these services. When multiple applications in several VMs on top of EB tresos Embedded Hypervisor are to be integrated, access to the HSM needs to be coordintated.

Figure 3 presents two VMs with Application Software Clusters that share the HSM. The figure is simplified and shows the communication paths of the applications through proxy modules and shared memory regions with the HSM. The Bus Separation Module of EB tresos Embedded Hypervisor is configured by the integrator in a static way, which then grants VMs with permissions to write and read from the HSM module in an isolated way.

^{Figure 3: Static & Dedicated ACM}

Virtual Machines vs. AUTOSAR CP Software Cluster

Do not be misled by the common misconception that AUTOSAR CP Software Cluster and hypervisor-based virtualization are competing technologies. They are complementary, serving different use cases. It is not surprising to see AUTOSAR CP Software Cluster implementations deployed inside VMs on top of the EB Embedded Hypervisor.

Within the table below we summarize a side-by-side comparison of both technologies:

Category	AUTOSAR Classic Platform (CP) Software Cluster	EB tresos Embedded Hypervisor
Use cases of AUTOSAR CP Software Cluster and hypervisors	•  Decouple development of independent applications and software clusters •  Individually update applications with little effort or costs •  Consolidate applications on the same ECU	•  Decouple development of independent applications and software clusters •  Consolidate mostly independent applications on the same ECU. •  Consolidate applications on different base software stacks, from different vendors, on the same ECU •  Decouple On-Board Diagnosis (OBD) and non-OBD applications to reduce homologation procedures •  Isolate applications and the stacks they run on from each other
Build result	built from base binary and the tightly coupled binaries of each cluster	One binary for the hypervisor and one binary per VM
Run applications on different base software stacks	All applications are executed on the same base software stack	In each VM a complete stack is executed with applications on top of it
Safety/freedom from interference between applications/VMs	Typically partitioned into QM and Safety partitions	VMs do not interfere with each other, thus mixed criticality is supported
Communication out of the box	Uses existing middleware and MCALs of the shared base software stack	•  Additional implementation effort. E.g. Ethernet communication integration and virtual switches like EB zoneo VSwitch •  Requires configuration of Embedded Hypervisor to pass CAN/LIN/Ethernet data into VMs (depends in general on the device assignment policies, compare here)
Update applications/VMs independently	Flash individually, but with some dependency on monolithic build (exception is the CP software clustering)	Integration with FOTA
RAM efficiency when used for application consolidation	•  Medium to high •  Scales with the number of interfaces that are used	•  Medium to low •  Adds base software footprint per VM
ROM efficient when used for application consolidation?	•  Medium to high •  Shares the same base software for all applications	•  Medium to low •  Adds base software ROM consumption per VM
Reasonable number of SwCluster or VMs?	1-8 SwClusters	2-3 VMs
Complexity to configure the technology	•  Interleaves integration, configuration, and deployment •  Requires base software and applications to be configured accordingly in advance. •  Software Clusters do not require the complete base software configuration	•  Splits integration, configuration, and deployment into digestible chunks •  Additional configuration per VM and per peripheral sensor & actuator interfaces is necessary
License costs for customers	License of the additional feature	Additional licenses: EB tresos Embedded Hypervisor itself

---

Category	AUTOSAR Classic Platform (CP) Software Cluster	EB tresos Embedded Hypervisor
		EB corbos Virtual Ethernet Switch
AUTOSAR compliance of the concept	Yes	No
Connections between SwClusters and between VMs	Flexible connections of interfaces after SW builds. However, configurations can be "fragile", e.g. Introduction of new interfaces could require RTE and all Software Clusters to be rebuilt	Interfaces are static, careful configuration of shared resources

Release outlook

Elektrobit’s EB tresos Embedded Hypervisor will be released in mass-production ready quality on the ST Microelectronics Stellar SR6G7 in October 2024. The safety-approved release is scheduled for January 2025, which will be included in an SOP (Start of Production) of an OEM in Q2 2025
Amongst other controller support, there is the Cortex-R52 based NXP S32Z27x on our roadmap, to be picked up in 2025 and getting it safety-approved released for mass-production in Q4 2026.

Resources:

• EB tresos Embedded Hypervisor, Elektrobit
• Classic AUTOSAR Basic Software (BSW), Elektrobit