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).
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.
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:
NXPS32S: COQOS Micro SDK
Webinar: How to virtualize your Arm Cortex-R52 multicore microcontroller - A tutorial on COQOS Micro SDK on NXP S32S