OpenSynergy has developed a variant of its hypervisor to be used for automotive virtualization on microcontroller. This product, called COQOS Micro SDK, is the first hypervisor to take advantage of the virtualization extensions in microcontrollers. The hypervisor adds an additional level of decoupling, supporting a critical first level of separation in development, configuration, integration and software update.

Why Virtualization on Microcontrollers?
Embedded virtualization, already in production on application processors, in vehicle domains such as connectivity and infotainment, is now coming to microcontrollers and real-time processors. The reason is that domain controllers running on a microcontroller or real-time processor need to integrate an ever-increasing amount of software. This software is often developed according to different functional safety levels or sourced from different suppliers so that freedom from interference must be insured.
New MCUs are designed to address the problem of this increasing complexity. They carry-over the design of the predecessors with features like Memory Protection Units, and low interrupt latency to address the high integrity requirements of mission-critical software.
They also provide more computing power by increasing the frequency, the number of cores and minimize latency. They provide better safety using hardware redundancy techniques such as lock-step CPUs. They eventually provide higher security by including advanced privilege control and hardware security modules.
In those architectures, the hardware is designed such that it can support virtualization natively: The Timer, the Interrupt Controller and the Memory Protection Unit. This affects the efficiency and performance of the virtualization because of the cost of context switching in terms of CPU cycles and the mapping of interrupts.

What is the benefit of the Hypervisor?
The Hypervisor – the central component of the COQOS Micro SDK – runs directly on the microcontroller and provides spatial separation between virtual machines by using a dedicated memory protection unit (MPU). Each VM 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 that cannot only use application processors. It provides freedom from interference between these functions although they require different safety levels (QM, ASIL-A, -B, -C, -D). Some upcoming generations 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. They will typically be used to run classic AUTOSAR-based systems or specialized real-time operating systems.

What is special in using virtualization with AUTOSAR?
AUTOSAR has contributed to making the software portable and now facilitates to the adoption of multicore system on chips. The beauty of virtualization is that you can combine the best of those worlds: 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. Read more in our special box “Benefit” below.

Developed as an SEooC and ISO 26262 compliant
OpenSynergy has developed the COQOS Micro SDK as a Safety Element out of Context (SEooC) according to ISO 26262. The SEooC approach means that OpenSynergy assumes certain safety requirements that its product fulfills.

Typical Use Cases
Typical application domains for COQOS Micro SDK are powertrain, chassis, body, gateway and ADAS control units, which implies the separation kernel must achieve a high safety level of ASIL-D. This requires temporal and spatial separation of virtual machines.
Concrete examples can be found in the body and powertrain domains. A single microcontroller runs functions that are safety-critical (such as power-management of the entire body domain), security-critical (such as unlocking the car) and functions that are neither (such as interior lighting). Ideally these functions can be developed independently and integrated easily. It enables a software update of uncritical functions (such as the interior lighting) without affecting safety relevant functions (such as managing power).


  • Provides Virtual Machines (VMs) for functional blocks, which:
    • have different requirements on real-time behavior
    • have different safety risk levels (ASIL)
    • are supplied by different vendors
  • Eases and accelerates the AUTOSAR integration and configuration challenge
  • Enables the integration of several functions on a single device (virtual ECU concept)
  • Supports independent modular software update.

Find more information about Multi-functional Body Controller and Powertrain here.

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.



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.