COQOS Hypervisor SDK for real-time processors

COQOS Hypervisor SDK for real-time processors

OpenSynergy has developed a variant of its hypervisor to be used for automotive virtualization on microcontrollers. The new generation of microcontrollers, based on the architectures for processor cores such as Arm Cortex®-R52, Infineon TriCore™, and Renesas RH850/U2x, have built-in hardware extensions to make virtualization easier and more effective. COQOS Hypervisor SDK for real-time processors is one of the first hypervisors to take advantage of these virtualization extensions in microcontrollers.





What is special about COQOS for real-time processors?

  • specially developed for processors with features like Memory Protection Units
  • provides spatial separation using a dedicated memory protection unit (MPU)
  • high efficiency and performance as new MCUs are designed to support virtualization natively
  • developed as a Safety Element out of Context (SEooC) according to ISO 26262
  • freedom from interference up to the highest level ASIL-D between virtual machines
  • run on Cortex®-R52, Infineon TriCore™ and Renesas RH850/U2x,


Why use COQOS Hypervisor for real-time processors?
The enormous computing power of these new chips MCUs is designed to address the increasing complexity in the car. It forms the hardware-technical basis for the upcoming generations’ domain and zonal architectures. The separation of functions by hardware virtualization alone is not sufficient to fully exploit this enormous power. Additional virtualization technology is needed that not only enables the integration of numerous applications but can also run several operating systems side by side on which the various functions are located. COQOS Hypervisor SDK for real-time processors completely separates all software components from the hardware and enables the software components – i.e., both the operating systems and the applications running on them – to be completely independent and not influence each other, as well as being able to be updated in a modular way, are suitable for this.

How does it work?
The Hypervisor – the central component of the COQOS Hypervisor SDK – runs directly on the microcontroller and provides spatial separation between virtual machines by using a dedicated memory protection unit (MPU). Each virtual machine is isolated from the others as the key goal of the hypervisor is to ensure freedom from interference (as specified by ISO 26262) up to the highest level ASIL-D between virtual machines.
Virtualization technology enables therefore the integration of more complex software functions on domain controllers or zonal computers. It provides freedom from interference between these functions although they require different safety levels (QM, ASIL-A, -B, -C, -D).

Standard-based devices according to VIRTIO
COQOS Hypervisor SDK for real-time processors includes a large number of devices based on the open industry standard VIRTIO.  The entire functions of a domain (e.g., body, cockpit, ADAS) can run together and simultaneously on a single ECU. Thanks to the high performance of microcontrollers, the number of integrated functions can still be expanded to a relevant extent. Future architectures will favor the spatial aggregation of functions, i.e., zonal computers because in this way the cabling throughout the vehicle is reduced. Thanks to the virtual devices that OpenSynergy offers on its COQOS Hypervisor SDK in addition to the hypervisor, the systems here communicate without additional hardware. Thus, physical CAN buses are replaced by VIRITO-CAN (a CAN implementation in shared memory instead of wires). The exchange between virtual machines is also possible via VIRTIO-vsock or VIRTIO-net depending on the application. The material savings through virtual devices can result in a vehicle weight reduction, as well as a cost-relevant reduction of the integration effort. For the development of these virtual devices, OpenSynergy has been an active member of the OASIS OPEN consortium since 2018 and specifies the most important devices according to the open VIRTIO standard.


Typical Use-case example – Zonal Computer

Main Features

  • Hardware assisted virtualization
  • Memory separation/protection
  • Multi-core support
  • Inter-VM communication
  • VM restart and update
  • Error reporting and recovery
  • AUTOSAR integrated configuration tool (at HV level)
  • ASIL-D based development (SEooC)

Target ECU/Application

  • Safety application:
    • Breaking System
    • ADAS (as a companion)
    • Power Train
    • Motor and Chassis Control
  • Real time:
    • Gateway
    • Body Control
    • Energy Management
    • Domain Control




Market Report

Strategy Analytics has stressed in its latest report that carmakers will focus on centralized architectures supporting their target of highly automated driving. It always becomes more apparent that the use of virtualization is finding its way into electric powertrain technology.

You may read the Strategy Analytics full report on Arm website.

Virtualization Extending the Mechanism of AUTOSAR

To a certain extent, classic AUTOSAR already provides such separation, even supporting several ASIL-levels, without the need of a hypervisor. AUTOSAR provides separation at the level of the operating system and the applications consist of individual software-components. However, in complex software systems, the configuration of AUTOSAR becomes extremely complex as the behavior of the operating system and the services in the basic-software needs to be defined centrally, which breaks modularity. AUTOSAR also requires all applications to follow the AUTOSAR standard, even to the same version. Finally, the result of the AUTOSAR development process is a monolithic system that does not allow for modular software updates.
The hypervisor adds an additional level of decoupling, supporting a critical first level of separation in development, configuration, integration and software update. Within one virtual machine, an AUTOSAR-based system (providing a second level of separation) will be used in many cases. Several virtual machines can run different systems with different AUTOSAR implementations or even non-AUTOSAR-compliant software.
In addition to these new requirements, which cannot be addressed by existing technologies such as the classic AUTOSAR standards, new generations of microcontrollers and real-time processors have built-in extensions that make running a hypervisor very efficient. The hardware extensions that have been available in application processors since many years, are now coming to microcontrollers and to the
SoCs that integrate them. One good example is the ARMv8-R architecture, which has added extensions for virtualization to the “R” (Real-Time) family, such as a second MPU (Memory Protection Unit) controlled by the hypervisor. This architecture is used in the Arm Cortex®-R52 core, which has been adopted by new controllers such as the NXP S32S.

Advantages over Non-hypervisor Method

The use of virtualization technology brings numerous advantages for the integration of software systems in the vehicle:

  • Virtualization makes it simpler to provide freedom from interference by enforcing temporal and spatial separation
  • Virtualization allows independently developed software partitions to run on the same ECU. The software partitions may use different software stacks.
  • Virtualization allows consolidation of software from multiple legacy ECUs into a newer, more powerful ECU.
  • New functions, and the introduction of multi- and many-core systems increase software complexity. Analyzing real-time behavior becomes more difficult. Because the hypervisor enforces strict timing protection, temporal interference between software components in different virtual machines is avoided, allowing for an easier understanding of the system decomposed to partitions at the function level.
  • Virtualization allows for new workflows in software development where different suppliers can develop software for different virtual machines in parallel, thus allowing OEMs a more flexible approach as well as reducing hardware costs.
  • Having independent and modular software updates can lead to a significant reduction in the effort needed to requalify software partitions, especially when the changes are small.

Webinar: How to virtualize your Arm Cortex-R52 multicore microcontroller - A tutorial on COQOS Micro SDK on NXP S32S


By loading the video, you agree to Vimeos's privacy policy.
Learn more

Load video

Webinar: How to virtualize your Arm Cortex-R52 multicore microcontroller - A tutorial on COQOS Micro SDK on NXP S32S


By loading the video, you agree to Vimeos's privacy policy.
Learn more

Load video


    Your Request Whitepaper COQOS Micro SDK

    Thank you for your interest in our subsequent technical documents. We offer you the possibility to download the document and would be pleased to send you further information regarding the whitepaper at the e-mail address provided. By providing your email address, you confirm that we may contact you regarding this matter.

    You can revoke this consent at any time with effect for the future. Please send us an e-mail to datenschutz[at] Further information on data protection can be found in our data protection declaration.