One concrete example can be found in the body domain. Such a domain controller will run, on a single microcontroller, 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 should be possible to do a software update of uncritical functions (such as the interior lighting) without affecting safety relevant functions (such as managing power).
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.
OpenSynergy has been developing a variant of its Hypervisor for microcontrollers since several years. This product is called COQOS Micro SDK. It is the first hypervisor to take advantage of the virtualization extensions in the ARMv8-R architecture and will support the next generation of microcontrollers built on that architecture.
How does virtualization work on MCUs?
The central component of the COQOS Micro SDK is the hypervisor. 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. This requires temporal and spatial separation of virtual machines.
The hypervisor ensures spatial separation between virtual machines by using a dedicated memory protection unit (MPU). The hypervisor is responsible for allocation of exclusive memory regions to a virtual machine, and for enabling virtual machines to access peripheral devices. When the hardware includes two MPUs (per each core), a real-time operating system running inside the virtual machine may use the first-stage MPU for protection inside the virtual machine. To ensure complete separation, the memory space must also be protected from interference by bus masters other than the processor (non-core bus masters), such as direct memory access (DMA) controllers. For this, most SoC manufacturers provide their own custom methods of limiting the accessible memory regions.