With the development of ICT technology, the computing power of a single SOC can undertake more services. The expansion of network bandwidth and characteristics such as low latency and differentiated services make the deployment of services and allocation of functions more flexible. For example: perception, fusion, planning, control, and execution can be decoupled. Automotive service functions can be separated or combined, and can be software-defined. The electronic and electrical architecture has transformed from a distributed architecture to a domain-centric architecture, and then to a central concentrated architecture, where dispersed ECU functions are integrated into domain controllers or even onboard central computers. This is multi-domain fusion.
There are various resource isolation technologies, ranging from hardware isolation at the hardware level to virtualization isolation, container isolation, process isolation, and so on. Hardware isolation has the best isolation, with the best performance and safety reliability of a single isolation domain. However, it has poor flexibility and configurability, cannot achieve hardware sharing, leading to poor resource utilization of the entire system, and cannot fully achieve the goal of software-defined vehicles. Container isolation and process isolation can achieve business isolation in a more lightweight manner, but they still exist within the same operating system, posing risks of resource interference and mutual security attacks, and cannot support the fusion of heterogeneous operating system service domains, affecting the inheritance of traditional services and hindering ecological development. Among many resource isolation technologies, virtualization is a safe, reliable, and flexible preferred solution, and is an important supporting technology for software-defined vehicles. A typical application scenario is shown in Figure 1:
Figure 1 Typical Application Scenarios of Virtualization
1. Technical Forms
Hypervisor, literally “supervisor”, is also known as Virtual Machine Monitor (VMM). As shown in Figure 2, Hypervisor is positioned above the SoC hardware platform, converting physical resources (such as CPU, memory, storage space, network adapters, peripherals, etc.) into virtual resources, allocating them to each virtual machine as needed, and allowing them to independently access authorized virtual resources. The Hypervisor achieves integration and isolation of hardware resources, allowing applications to share physical hardware like CPU while relying on different kernel environments and drivers to operate, thus meeting the diverse application scenario requirements in the automotive field.
Figure 2 Position of Virtualization in the System
In the automotive field, Hypervisor mainly performs the following tasks:
-
CPU virtualization: Providing VCPU resources and operating environment for virtual machines;
-
Memory virtualization: Responsible for allocating and managing hardware memory resources for itself and virtual machines;
-
Interrupt virtualization: When an interrupt or exception occurs, routing the interrupt and exception to the virtual machine for processing as needed;
-
Virtual machine device simulation: Creating virtual hardware components that virtual machines can access based on demand;
-
Hardware support BSP: Providing board-level support packages for Hypervisor running on SoC, such as serial port drivers;
-
Virtual machine resource configuration: Configuring and managing resources such as CPU, memory, and IO peripherals for virtual machines;
-
Virtual machine communication: Providing IPC, shared memory, and other communication mechanisms for virtual machines.
-
Virtual machine scheduling: Providing scheduling algorithms such as priority and time slices for virtual machines;
-
Virtual machine lifecycle management: Creating, starting, and stopping virtual machines;
-
Virtual machine debugging service: Providing console, logging, and other debugging functionalities;
-
Lightweight and Efficient. While Hypervisor brings the flexibility of software-defined capabilities, it also leads to an increase in the software stack layers, inevitably causing performance losses. The cost-sensitive nature of the automotive field necessitates a demand for reducing performance losses of CPU, storage, network, GPU, and other peripherals throughout the vehicle project, making the lightweight and efficient nature of Hypervisor crucial; -
Safe and Reliable. Compared to the emphasis on dynamic resource allocation and idle utilization in the internet field, the automotive field places greater importance on the real-time, reliability, and security of Hypervisor; -
Convenient Adaptation. In the automotive field, there is a rich variety of chip types and operating systems. A major characteristic of embedded virtualization is heterogeneity, and Hypervisor must possess the ability to quickly adapt to different underlying hardware and upper-layer operating systems.
2. Trends in Technical Development
2.1 Differentiation of Key Technologies in Cloud-Edge-End Virtualization
The earliest virtualization technology can be traced back to the 1960s when IBM developed virtual machine monitor software that divided computer hardware into one or more virtual machines, supporting simultaneous interactive access by multiple users to large computers. With the rise of general server computing power in the 21st century, cloud computing has flourished, and cloud virtualization as a foundational supporting technology has rapidly evolved. Later, computing power gradually sank from cloud to edge to end, accompanied by the emergence of edge virtualization and end-side embedded virtualization. Their typical architectures and key technology requirements are shown in Figure 3.
Figure 3 Typical Architecture and Key Technology Requirements of Cloud-Edge-End Virtualization
(1) Cloud-Side Virtualization
Its characteristics include a basically homogeneous hardware platform, with numerous nodes forming a cluster. The architectural design prioritizes throughput capacity, supporting multi-business concurrency. Virtualization must meet resource scheduling strategies for cluster load balancing and energy-saving, ensuring uninterrupted migration of services during cross-node virtual machine allocation. In the event of a virtual machine failure, it must ensure recovery from checkpoints to minimize business losses. Virtual machines should support elastic scaling of capabilities such as CPU computing power, memory, storage space, network, GPU, and peripherals, and should also support over-allocation to enhance the operational benefits of data centers.
(2) Edge-Side Virtualization
This is implemented on edge nodes for specific businesses using a general ICT architecture, supporting dynamic deployment of various services, typically seen in SDN and NFV. Its technical characteristics include: based on a general hardware platform, industry-customized management deployment platform, achieving software-hardware decoupling, software definition, and on-demand deployment of multifunctional nodes with elastic networking, generally adopting 1+1 or N+1 redundancy to ensure high availability of services. In 5G telecommunication network elements, it is necessary to consider the end-to-end real-time requirements of 5G services, necessitating design considerations for Hypervisor, virtual machines, and communication protocol stacks.
(3) End-Side Virtualization
The typical characteristic of end-side virtualization is heterogeneity, with significant differences in chip architecture and processing capabilities. Generally, it is a single-chip solution without cluster or primary-backup virtual machine migration, thus emphasizing high security and high reliability per node, such as function safety ASIL level requirements, while also having stronger real-time and determinism requirements. Additionally, end-side resources are more limited and cost-sensitive, thus requiring Hypervisor to be lightweight and high-performance.
2.2 Trends in Virtualization Models
Hypervisor can be divided into two main categories: one is Type 1 bare-metal, where the Hypervisor runs directly on the hardware device, also known as Bare-Metal Hardware Virtualization; the other is Type 2 hosted, also known as Hosted Virtualization. Figure 4 shows the layered architecture of the two types of Hypervisors.
Figure 4 Type 1 and Type 2 Hypervisors
Type 2 Hypervisors require the host operating system to manage resources such as CPU, memory, and network. Because there is a host operating system between the Hypervisor and the hardware, all operations of the Hypervisor and VM must go through the host operating system, which inevitably leads to latency and performance loss. Additionally, security vulnerabilities and stability issues of the host operating system can affect the VMs running on it. Therefore, Type 2 Hypervisors are mainly used in scenarios with low performance and security requirements, such as personal PC systems.
Type 1 Hypervisors do not rely on host operating systems and possess basic operating system functions. They are designed to be simpler, running directly on hardware, with a smaller overall codebase and architecture, requiring fewer memory and storage resources, meeting the functional safety level requirements for autonomous driving vehicle control systems, and being suitable for formal verification. Therefore, automotive operating systems are more suitable for using Type 1 Hypervisors.
With the development of microkernel operating system technology, many Hypervisors designed based on microkernel operating systems have become very lightweight, including only the basic, immutable functions such as CPU scheduling and memory management. Device drivers and other variable components are kept outside the kernel. There is a debate in the industry over whether this type of Hypervisor should be classified as Type 1 or Type 2. Overall, microkernel Hypervisors are smaller, more stable, and have better scalability, making them more suitable for embedded virtualization scenarios.
2.3 Collaboration Technology Route between Hypervisor and Virtual Machines
(1) Full Virtualization
The original virtualization was achieved through software simulation of a computer system with complete hardware functionality running in an isolated environment, providing virtual hardware devices for Guest OS use. The advantage is that Guest OS does not perceive the external real hardware environment and does not need modification. However, since every access to fully virtualized hardware in Guest OS leads to a trap into the Hypervisor, this results in poor performance of the virtualized hardware, generally used only for simulating simpler hardware like serial ports. Hardware simulation can be done directly in the Hypervisor or by passing requests to other VMs for simulation, such as using QEMU in a specific VM.
(2) Hardware-Assisted Virtualization
Intel was the first to propose hardware-assisted virtualization technology, where hardware directly provides shared functionalities, supporting access by multiple Guest OS, reducing latency and performance loss caused by software virtualization technologies. Intel has proposed technologies such as Intel VT-x, Intel VT-d, and Intel VT-c, targeting processors & memory, IO, and networking, respectively. As ARM’s computing power increases, advancing from mobile to edge and even cloud computing centers, ARM is continuously enhancing its hardware-assisted virtualization technologies, such as stage 2 page table translation and virtual exceptions.
(3) Para-Virtualization
In the developmental stage where hardware-assisted virtualization technology is not mature or powerful, or for sharing and reusing some complex peripherals, para-virtualization technology can be adopted, where Guest OS collaborates with the Hypervisor. This technology is generally applied to IO device virtualization, implementing front-end drivers in Guest OS and back-end drivers in Hypervisor or Host OS. The front-end driver in Guest OS sends requests to the back-end driver through communication mechanisms provided by the Hypervisor, and the back-end driver accesses the hardware driver. This involves the integration of different vendors’ Guest OS with different vendors’ Hypervisor ecosystems.
Virtio is currently the most popular I/O para-virtualization solution. Virtio is an open protocol and interface managed by the OASIS standards group, enabling virtual machines to access IO devices in a standardized manner. Virtio was officially standardized in March 2016, with version V1.1 released in 2020. The Virtio standard adopts a universal and standardized abstraction model, supporting an increasing number of device types, achieving high performance, widely applied in cloud computing, and has high open-source activity, with stable front-end driver code already available in operating systems like Linux. Most commercial and open-source Hypervisors have supported the Virtio standard.
Virtio is a commonly used implementation of para-virtualization technology in the automotive industry, as shown in Figure 6. A virtual device bus, Virtio-bus, is created within the Guest OS, enabling bidirectional communication between the front-end driver and back-end virtual devices mounted on the Virtio-bus that comply with the Virtio standard. Virtio provides a comprehensive Virtio bus and device control interface, including virtio-net, virtio-blk, virtio-console, virtio-input, etc.
Figure 6 Virtio Virtualization Implementation Model
-
Using virtio-blk Technology to Achieve Block Device Sharing
Block devices are storage devices that use caching mechanisms for read and write, managed by the operating system where the Hypervisor is located. The virtio-blk driver is a block device driver compliant with the Virtio standard, and vdev virtio block is the back-end virtual block device. The virtio blk driver performs read and write operations on the physical block device through this vdev device and obtains execution results.
-
Using virtio-net Technology to Achieve Inter-System Communication
Virtio-net implements point-to-point communication between multiple systems. The virtio-net driver inside the Guest system communicates with the virtio-net device in the system where the Hypervisor is located via virtqueue, achieving full-duplex communication for control and configuration instructions and data exchange between multiple systems. It is suitable for data transmission outside of audio and video streams, with good stability, but the complex control logic of virtqueue affects real-time performance to some extent.
-
Using Virtio Technology to Achieve Touch Sharing
Touch devices are character-type devices that report touch coordinate data to the driver through the virtio-input driver and vdev-input. The device side reports touch coordinate data to the driver through virtqueue.
3. Real-Time Technology
Real-time performance is a key performance indicator of embedded real-time operating systems. The real-time performance of the Hypervisor is fundamental to the real-time performance of the entire system. If the Hypervisor cannot timely schedule the Guest OS to run, the Guest OS cannot achieve good real-time performance metrics. The main indicators for measuring the real-time performance of the Hypervisor include interrupt latency and scheduling latency. Interrupt latency starts from the moment a hardware interrupt occurs to the moment the virtual machine receives the interrupt injected by the Hypervisor. The longest delay time under various stress conditions is the interrupt latency. Scheduling latency is the time from when a high-priority virtual machine process is ready to when that high-priority virtual machine process is scheduled to run. The longest delay time under various stress conditions is the scheduling latency.
After interrupt virtualization, when external interrupts occur, the Hypervisor receives and injects them into the virtual machine as quickly as possible, ensuring that the time for the Hypervisor to handle interrupts in the virtual machine is minimal. The Hypervisor optimizes the switching time of virtual machines, minimizes the time spent on disabling interrupts and preemption, and tries to use kernel locks as little as possible. When a high-priority virtual machine needs to switch execution, it can switch to the high-priority virtual machine as quickly as possible.
3.4 Security and Reliability Technology
Functional safety, information security, and reliability are necessary components for the reliable and safe operation of vehicle control operating system products. The Hypervisor provides the basic operating environment for intelligent vehicle domain controllers, and its safety and reliability are the foundation and core for ensuring the functional safety and reliability of the entire system. The Hypervisor must be designed, developed, and tested according to the highest standards of automotive functional safety ISO26262 ASIL-D, with functional safety requirements derived from the safety requirements of domain controller products.
Multiple virtual machines run on the Hypervisor, and an exception in one virtual machine cannot propagate to other virtual machines. The Hypervisor can obtain the overall health status of the current system. When a virtual machine encounters an exception, the Hypervisor should monitor the system’s health status in real-time, effectively isolate the fault, and repair the exception within the smallest possible impact range, ensuring the system remains continuously available.
-
Trust chain issues between the virtual machine manager and virtual machines. Using virtualization technology to create multiple virtual machines on a trusted physical platform and transmitting the trust chain built from the hardware trusted root to each virtual machine, thereby constructing multiple virtual trusted computing platforms on a trusted physical platform. Some solutions lack trust chain verification from the virtual machine manager to the virtual machines; -
Attacks between virtual machines: malicious intruders can exploit vulnerabilities in the hypervisor to gain control of a virtual machine through another virtual machine existing on the same physical host, thus compromising the target virtual machine; -
Virtual machine escape: exploiting vulnerabilities in the virtualization software or software running in the virtual machine to attack or control the virtual machine’s host operating system.
To enhance the security of the Hypervisor, it is important to establish corresponding security targets. The table below briefly lists the related requirements:
The security capabilities of the Hypervisor can be enhanced from three dimensions.
(1) Establishing Security Boundaries
As shown in Figure 7, this boundary is strictly defined and implemented by the Hypervisor. The confidentiality, integrity, and availability of the Hypervisor security boundary need to be ensured. The boundary can defend against a series of attacks, including side-channel information leakage, denial of service, and privilege escalation. The security boundary of the virtual machine monitor also provides isolation capabilities for network traffic, virtual devices, storage, computing resources, and all other virtual machine resources.
Figure 7 Security Boundary
The overall virtualization security architecture is shown in Figure 8. The confidentiality of the security boundary can be implemented through traditional cryptographic methods. Integrity is ensured through trusted measurement mechanisms, and trusted reporting mechanisms achieve trusted interoperability between different virtual environments. Monitoring mechanisms dynamically measure the behavior of entities, discovering and eliminating unexpected interferences. The isolation mechanisms provided by virtualization technology separate the operational space of entities.
Figure 8 Overall Virtualization Security Architecture
The isolation of the security boundary is supported by Hypervisor’s vCPU scheduling isolation security, memory isolation, network isolation, and storage isolation technologies, achieving isolation between the Hypervisor, virtual machines, and between virtual machines on the same physical machine.
(2) Establishing Deep Defense Mitigation Mechanisms for Vulnerabilities
For potential vulnerabilities in the security boundary, the Hypervisor needs to have certain technical means for proactive defense. These technical means include Address Space Layout Randomization (ASLR), Data Execution Prevention (DEP), arbitrary code protection, control flow protection, and data corruption protection.
(3) Establishing Strong Security Assurance Processes
The attack surfaces associated with the Hypervisor include virtual networks, virtual devices, and all cross-virtual machine surfaces. It is recommended to implement threat modeling, code reviews, and fuzz testing for all virtual machine attack surfaces, establishing automated builds and environments to trigger regular security checks.
As an important technology in cloud computing scenarios, virtualization technology has accumulated many security paradigms over more than a decade of production practice, which can also be referenced in automotive scenarios. However, compared to cloud scenarios, virtualization technology in automotive scenarios has its particularities, such as the lack of need for dynamic migration/creation of virtual machines and the functional safety level requirements for Hypervisors, etc. Its security measures need to be continuously enriched and improved in practice.
4. Typical Application Cases
In the development of automotive intelligence, virtualization is mainly applied in integrated scenarios such as smart cockpits, intelligent driving, and smart gateways. Intelligent driving is limited by technological maturity and regulatory policies, remaining mostly in the research and prototype stage. The business functions of smart gateways are relatively homogeneous and may further integrate into other scenario solutions. Therefore, the current major application cases are concentrated in smart cockpits.
The fusion of smart cockpit domains has also been initiated in recent years and is continuously iterating and evolving. Influenced by factors such as chip computing power, the maturity of virtualization technology, and the ecological chain’s control over virtualization solutions, some manufacturers have adopted hardware isolation solutions for domain fusion, maximizing the use of existing technical capabilities with certain guarantees. However, this lacks the flexibility of software definition and has limited intelligence, making it an optional solution for domain fusion. In terms of embedded virtualization technology, foreign companies like QNX, OpenSynergy, and PikeOS have a first-mover advantage, especially having cultivated in the automotive field for many years, leading to a significant number of application cases in recent years. Driven by the trend of localized intelligent development, many domestic chip manufacturers and independent software vendors have also developed embedded virtualization technologies, products, and solutions in recent years, such as Zhongling Zhixing’s RAITE Hypervisor (RHOS), ZTE’s GoldenOS, Zebra Zhixing’s AliOS Hypervisor, and CAIC Hypervisor from China Automotive Innovation.
4.1 Smart Cockpit Domain Controller Products
A certain manufacturer’s smart cockpit domain controller product, as shown in Figures 9 and 10, is based on Qualcomm 8155 and Renesas R-Car H3 processors, using QNX Hypervisor, equipped with QNX Host, Android P/R/S Guest OS, and capable of outputting up to 6 independent HD screens. It integrates functions such as entertainment systems, LCD dashboards, body control, DMS, APA, etc., supporting independent four-zone audio, multi-screen interaction, and audio-video sharing with high integration, adapted for mass production in various models like Great Wall, Changan, and Yutong buses.
Additionally, the domestic solution, the Chipsea X9HP+ platform, flexibly configures to implement mid-to-low-end smart cockpit domain controller products using both hardware partitioning and Hypervisor solutions.
Figure 9 Smart Cockpit Domain Controller
Figure 10 Domestic Smart Cockpit Domain Controller
4.2 RHOS Smart Cockpit Domain Controller Platform
(1) NXP I.MX8QM Cockpit Domain Controller
A certain manufacturer has adapted the self-developed Type-1 virtualization software RHOS (Raite Hypervisor OS) to support NXP I.MX8QM, providing a lightweight and flexible automotive smart cockpit virtualization solution, which has been mass-produced and launched in Dongfeng models. Its system architecture is shown in Figure 11:
Figure 11 NXP I.MX8 Smart Cockpit System Architecture
After running the Hypervisor on SoC, it can support multiple operating systems simultaneously, such as Linux systems running high real-time and safety-critical applications like fully LCD dashboards, and can extend to run DMS, HUD, and other services. Another virtual machine runs the Android operating system, deploying infotainment and other applications with lower safety and real-time requirements. To ensure the system has good market competitiveness, the domain controller meets TBOX functional requirements, supporting sleep wake-up and fast start-up.
Linux and Android virtual machines can be configured with resources on demand, including memory, CPU, storage space, and peripherals. This architecture supports system upgrades, including upgrades to virtual machines and Hypervisor, and supports exception logging, including virtual machine kernel and Hypervisor logs.
Multi-screen interaction is an important application scenario for smart cockpits. Android’s APP applications can be pushed to the Linux dashboard for display through the Hypervisor.
Figure 12 Virtual Machine Multi-Screen Interaction Architecture
The interaction scheme between Android and Linux dashboards is shown in Figure 12. The NXP I.MX8QM chip has two or more display interfaces, each of which can connect to 2 displays. When the Android system needs to project information onto the dashboard screen, the overlay layer of the dashboard display can display the projected content. The system interaction has zero latency and zero copy, with no additional CPU and GPU resource consumption for multi-system interactions. Achieving cross-system multi-screen interaction through Hypervisor virtualization technology effectively improves driving safety and reduces the hardware costs of smart cockpits.
(2) MT8675 Cockpit Domain Controller
RHOS has adapted to support MT8675, forming a function-rich, cost-effective multi-screen smart cockpit domain controller solution, which has obtained multiple mass production projects from various manufacturers. Its overall system architecture is shown in Figure 13:
Figure 13 MT8675 Smart Cockpit System Architecture
MT8675 only provides one GPU, and the cockpit domain needs to share GPU resources between the dashboard and central control. RHOS achieves GPU virtualization sharing and, through performance optimization, reaches industry-leading virtualization performance (loss < 6%). RHOS supports Suspend to RAM functionality, with the MT8675 A core completely powered down, meeting the requirement of the smart cockpit standby static power consumption being less than 4mA.
5.3 KCS 3.0 Smart Cockpit Virtualization Platform
-
4 screens output simultaneously -
Multi-system real-time 3D rendering -
Multi-screen sharing -
Multi-screen interaction between dashboard and IVI for music and map applications -
Fast startup: <2s -
Facial and emotion recognition, etc.
The platform demonstration is shown in Figure 14:
Figure 14 KCS 3.0 Smart Cockpit Virtualization Platform
Additionally, the manufacturer has developed a digital twin platform based on X86+KVM+QEMU, simulating a hardware development platform through virtualization technology, including support for multiple cameras, multiple display outputs, multi-system audio mixing, screen sharing, and multiple CAN signals, effectively resolving developers’ reliance on real hardware platforms during SOA platform development.
end
AUTOSEMO Background
