Embedded virtualization has become one of the critical technologies to handle the complexity of
functionalities in the car. It will become more relevant as much as vehicles become highly automated or even autonomous. Virtualization makes it possible to allocate a processor’s resources
to multiple safely separated applications and operating systems. It reduces the car’s hardware complexity and enables the OEM to take advantage of processors’ performance.
Reason #1: Virtualization helps to scale and manage complexity.
Virtualization allows heterogeneous systems to consolidate software running on different hardware on a single unified and integrated hardware piece. Virtualization enables integrating a greater richness of features on the same hardware, which can appear more complex.
However, typical development activities, such as application integration, HIL SW testing, and system integration, which used to be performed involving multiple hardware and tooling environments, can be simplified using a virtualization solution. Furthermore, when powered by the latest generation of SoCs, the type-1 hypervisor in COQOS Micro SDK provides enough headroom to integrate numerous combinations of virtual machines (with multi-physical core and/or multi virtual cores).
Reason #2: Virtualization has a limited overhead on CPU and memory utilization.
When adding virtualization to a system, some dedicated software needs to be executed to perform hypervisor functions like context switching or routing of interrupts. This activity has a cost, but with today’s hardware, this cost has become very reasonable.
The new generation of CPU design using Armv8-R ISA – especially the Arm-R52 design – includes HW-assistance virtualization features such as optimized MPU for faster context switching. These designs are now made available by SoC vendors like the NXP’s S32S.
Also, OpenSynergy’s event-based hypervisor architecture is only invoked when required. Consequently, in specific configurations, the virtualized application’s performance is practically the same for a bare-metal implementation of the same application.
In a type 1 virtualization architecture, the virtualized software’s memory size (including operating system, libraries, application logic, and data) dwarves the memory size virtualization software (hypervisor and device drivers) by multiple order magnitude.
Reason #3: Virtualization makes the safety case easier to demonstrate.
The hypervisor can be certified as a Safety Element out of Context (SEooC). OpenSynergy’s COQOS Hypervisor was the first automotive hypervisor certified to the latest release of the ISO26262 specification. This approach gives system architects great leverage to reuse the safety certification in their design and reduce their certification effort burden.
Also, by introducing safe isolation mechanisms between virtualized payloads, virtualization allows multiple lifecycles of software development running in parallel and at different paces.
Let’s take a mixed-criticality example: You have two pieces of software that are logically independent and require different levels of safety: A vehicle communication application (QM) and a motor controller application (ASIL-D). If you allocate them to two different virtual machines, the hypervisor can run them simultaneously on the same CPU. Now imagine that the vehicle communication application software requires some changes, for instance, because the vehicle architecture has changed slightly but that this change does not require any modification on the motor control logic. Usually, there is no need to entirely reprocess the safety case, as long as the virtualization architecture’s safety assumptions are unchanged.
Reason #4: Virtualization can increase security.
Virtualization has already proven to be put to good use in the IT world to isolate securely critical applications. The same principles apply in the automotive world as securely critical applications are tailored to virtualization use cases. Providing isolation between virtual machines is a key feature of the hypervisor that cybersecurity experts and system architects can leverage to protect against specific attacks.
According to the well-known concept of “layered” cybersecurity, the hypervisor provides an additional defense layer and can increase the system’s overall security.
Reason #5: Virtualization can address high criticality safety use cases up to ASIL-D.
One of the typical target application use cases for virtualization is electrification (Battery Management System, e-Motor control, etc.). Both the hardware (NXP S32S) and the software (OpenSynergy COQOS Micro SDK) are designed to cover these use-cases up to ASIL-D, which is the highest level of criticality for safety applications according to the ISO26262 standard.
When the developers started to implement virtualization in the automotive ten years ago, they began by addressing simpler problems such as non-critical applications, with best-effort scheduling requirements and looser memory protection considerations. Today’s hardware and software technologies allow far more ambitious approaches to make the best available silicon and achieve time and space determinism.
Reason#6: Virtualization is complementary to OS partitioning.
Virtualization extends the possibilities of partitioning beyond the operating system. In the AUTOSAR Classic platform world, system architects tend to think of partitioning in terms of memory partitioning (scalability class 3) and time partitioning (scalability class 2), both performed by the OS.
Virtualization brings partitioning to another level by considering similar partitioning between operating systems themselves, and even without an operating system.
Partitioning is a great way to apply “divide and rule” principles to complicated architecture problems, especially, it is widely used in functional safety for decomposition purposes. For instance, using hypervisor partitioning, a system architect can break down a monolithic ASIL-D solution and isolate subfunctions of lower criticality (QM or ASIL-B, for instance) in separate virtual machines so that the level of safety certification effort is proportional to the criticality. Using virtualization, system architects have another powerful partitioning technique under their belt to design increasingly complex critical systems.
Reason #7: Virtualization supports hard real-time automotive applications.
The newer generation of real-time microcontrollers, such as the ARM-R52 MPU based architecture, allows for the implementation of HW assisted virtualization. NXP and OpenSynergy have been working together to allow virtualization on the S32S using COQOS Micro SDK (see the demonstration video here).
Real-time scheduling is available and implemented; deterministic features have been tested with bare-metal virtual machines and real-time operating systems such as FreeRTOS and Classic AUTOSAR OS implementations.
OpenSynergy has already demonstrated that paravirtualization techniques could be implemented on former hardware architectures even when there is no built-in hardware support for virtualization. However, it comes at the expense of performance and reduces the usage of such techniques significantly.
ARM released its HW-virtualization-assisted Cortex-R52 specification in 2016, and the first implementations from different SoC vendors, including NXP S32S or STM Stellar are now getting available. Similarly, Renesas has announced that virtualization will be available in their next generation of microcontrollers, embedded in-vehicle electronics systems in the following years.
Reason #8: Virtualization can work together with the AUTOSAR methodology.
Even if the AUTOSAR methodology does not specify yet a standard framework dedicated to virtualization, it is compatible with the AUTOSAR methodology. Both systems tend to be very complementary. Members of the consortium have presented concepts for the virtualization of AUTOSAR in the last years.
In 2014 OpenSynergy presented concepts of AUTOSAR virtualization at the annual congress in Detroit. The following year, ETAS presented its vision at the 2015 edition in Tokyo, creating more momentum on the topic. Now that AUTOSAR classic platform has reached stability in the real-time multicore framework and that the effort for sharing devices across applications shows results, it’s high time to bring it to the next level via virtualization.
COQOS Micro SDK has already proven to effectively virtualize several classic AUTOSAR implementations from different vendors on multicore systems.
Reason #9: Virtualization brings a lot more than separation.
It’s a mistake to see virtualization as a simple architecture alternative. Virtualization brings unique features to basic software solutions, which can be difficult to achieve using other software techniques without involving higher complexity and cost: suspend of software execution, advanced safety supervision, modular boot, and advanced silent software update.
Not only can virtualization be an architecture technique to bring and isolate legacy code together with new code, but it is also a feature solution that allows for developing new innovative functions.
Reason #10: Virtualization enables low-cost solutions.
Especially if you look at the total cost, including development and manufacturing, on the development- side, virtualization can help reuse software assets and thus lower re-certification and re-qualification costs.
On the manufacturing side, virtualization can maximize your silicon usage and support the consolidation of the EE architecture of a system by bringing multiple functions on one single SoC and ECU. Virtualization is a powerful enabler to make innovative and computation-intensive vehicle functions in the electrification, autonomous driving, or connectivity domains financially sustainable.