The evolution of the automotive EE-architecture to zonal architecture with central compute supports the trend towards further software integration in cars. This minimizes the overall number of electronic control units (ECUs) in the car and reflects the requirements of the AI-enabled software-defined vehicle (SDV), especially regarding software updates and maintenance.
The software integration trend is already happening now in the application space, with virtualization being used in two automotive generations in cockpit and advanced driver-assistance systems (ADAS) for rich operating systems (RTOS, Linux, Android) that are integrated into one high performance system-on-chip (SoC). To further consolidate this functionality, the automotive industry is also embracing real-time software integration. Within this blog, we will provide some insights on the evolution of this integration trend.
There are several options when it comes to real-time software integration, which vary based on the application demands and architecture evolution of the OEM. However, the two key options are the following:
Within this blog post, we will focus on the separation-based methods. We will also deep-dive into the evolution of the Armv8-R PSMA based evolution of software deployment.
To start with, it might be good to clarify some general terms.
When the term “virtualization” is used, this implies that the guest operating system is not aware that it does not have access to the full underlying hardware. From Arm’s perspective on VSMA based systems (e.g. Cortex-A78AE), this is the case. Therefore, a hypervisor will ensure that what the guest accesses from a virtual machine will be mapped with help from the System Memory Machine Unit (SMMU) through to the real physical addresses. In the case of PSMA based systems (e.g. Cortex-R52+), the systems only include Memory Protection Units (MPUs), so there is no address translation. Based on this, guests need to be aware that they run in such an environment and setup in a way that means they only access the resources which they are setup for. Therefore, from an academic perspective it is correct to speak of the EL2 functionality in PSMA systems of a separation kernel, instead of a virtualization kernel. The key advantage of the PSMA system is that it is deterministic, with the processors and system IP ensuring that you can get a full understanding of the code execution.
So, when it comes to real-time software integration, we first need to understand which type of software should be consolidated. We have already summarized this within a joint ETAS/Arm white paper called ‘Best practices for Armv8-R Cortex-R52 software consolidation’ and started to differentiate between different classes of real-time software. This differentiation should help to finally assess which integration method is best.
Within this white paper, we refer to real-time software as classic AUTOSAR stacks, as those are predominantly used in the automotive industry currently. However, the whole principles also apply to other operating systems (e.g. FreeRTOS, Zephyr, Greenhills uVelosity, eSol).
For the Armv8-R32 Cortex-R52+ based software integration, the following evolution steps are reflected in the automotive industry:
The hardware separation integration option is needed to further optimize the hardware usage and allow automotive platform development to scale, so all car segments can be served. Furthermore, software from different suppliers can be integrated (even non-AUTOSAR compliant code).
Now let’s have a closer look at these enhanced hardware separation options:
A reference software architecture for this integration looks as follows:
The classic AUTOSAR operating system spans across two cores (therefore this occupies a cluster), and the GIC is a shared resource per cluster. For such software architecture, the Armv8-R Exception Level 2 (EL2) hypervisor / separation kernel can host the following functions:
This integration scenario is the starting point for the Armv8-R EL2 usage in SOP 2025 projects. There are lead software partners that implement these kinds of solutions, more to follow in a separate note.
The reference software architecture for this integration scenario is similar to the cluster pinning, except that each instance of the OS is mapped to a single core instead of a cluster:
The key update of this CPU pinning architecture is that classic AUTOSAR or a real-time software stack is pinned to a CPU. As the GIC is a shared cluster resource in Armv8-R, this system IP needs to be virtualized in software. Of course, further adaptations and enhancements are needed for PSCI / SCMI, and the sharing of devices needs to be tailored to this upscale integration.
The final integration scenario is that virtual machines (VMs) are scheduled on a CPU core:
An integration in such software architecture needs further refinement to the aspects outlined in the previous chapter ‘CPU pinning’.
When it comes to the different integration scenarios, the Armv8-R device virtualization principles should be reflected, especially when it comes to sharing of devices within the software architecture. This is discussed in more detail in this whitepaper.
There are several software integration architectures viable in the automotive industry. Depending on the application requirements, the industry can choose between closely coupled options (mainly derived from classic AUTOSAR) and hardware separation supported integration options. One general unique selling point with the Cortex-R52+ software enablement is that the software bring-up and tooling can be re-used in multiple ECUs in the car. This is because the CPU is being used in homogenous microcontroller designs and heterogenous SoCs as a safety island. Based on the level of investment and software enablement, high-end real-time compute on Armv8-R Cortex-R52+ must be a strategic decision for the automotive industry.