Source | Automotive Electronics and SoftwareKnowledge Circle | To join the “Chassis Community”, please add WeChat yanzhi-6, note “Chassis”
With the development of ICT technology, the computing power of a single SoC can handle more tasks. The expansion of network bandwidth and features such as low latency and differentiated services make business deployment and function allocation more flexible. For example, perception, fusion, planning, control, and execution can be decoupled. Automotive business functions can be separated or combined and can be software-defined. The electronic and electrical architecture is transitioning from a distributed architecture to a domain-centric architecture, and then to a centralized architecture, integrating decentralized ECU functions into domain controllers or even a central vehicle computer, which is multi-domain fusion.The underlying hardware of automotive electronics is no longer provided by a single chip for simple logical calculations but requires complex multi-core SoC chips to provide more complex control logic and powerful computing support. However, multi-domain services have different technical requirements. For example, the cockpit domain’s IVI services emphasize interactive experience and a rich application ecosystem, making Android a suitable operating system; the dashboard and advanced driver assistance systems require real-time and reliability, leaning towards RTLinux or RTOS; the intelligent driving domain emphasizes high computing power for perception and planning, also requiring real-time and reliability, thus choosing RTLinux or RTOS. While domain fusion occurs, it is essential to ensure the safety and reliability of critical services and consider the sustainability and compatibility of the application ecosystem, which requires resource isolation technology to support resource partitioning on the same SoC, allowing multiple operating systems to run concurrently without interference.Resource isolation technologies vary, including hardware isolation, virtualization isolation, container isolation, and process isolation, from the hardware layer upwards. Hardware isolation offers the best isolation, with the best performance and security reliability for a single isolation domain, but it has poor flexibility and configurability, cannot achieve hardware sharing, leading to poor resource utilization across the system, and fails to fully achieve the goal of software-defined vehicles. Container isolation and process isolation can achieve business isolation more lightly but still exist within the same operating system, posing risks of resource interference and mutual security attacks, and cannot support heterogeneous operating system domain fusion, affecting traditional business inheritance and hindering ecosystem development. Among various resource isolation technologies, virtualization is a safe, reliable, and flexible preferred solution and is a crucial supporting technology for software-defined vehicles. Typical application scenarios are shown in Figure 1:
Figure 1 Typical Application Scenarios of Virtualization1. Technical FormHypervisor, literally translated as “supervisor”, is also known as a Virtual Machine Monitor (VMM). As shown in Figure 2, the Hypervisor sits 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, allowing them to independently access authorized virtual resources. The Hypervisor achieves the integration and isolation of hardware resources, enabling applications to share physical hardware like CPUs while running in different kernel environments and drivers, thus meeting the diverse application scenario needs in the automotive field.
Figure 2 Position of Virtualization in the SystemIn the automotive field, the Hypervisor mainly performs the following tasks:
- CPU virtualization: Provides VCPU resources and runtime environments for virtual machines;
- Memory virtualization: Responsible for allocating and managing hardware memory resources for itself and virtual machines;
- Interrupt virtualization: Routes interrupts and exceptions to virtual machines for processing as needed when they occur;
- Virtual machine device simulation: Creates virtual hardware components that virtual machines can access based on demand;
- Hardware support BSP: Provides board support packages for the Hypervisor to run on SoC, such as serial port drivers;
- Virtual machine resource configuration: Configures and manages resources such as CPU, memory, and IO peripherals for virtual machines;
- Virtual machine communication: Provides IPC, shared memory, and other communication mechanisms for virtual machines.
- Virtual machine scheduling: Provides scheduling algorithms such as priority and time slices for virtual machines;
- Virtual machine lifecycle management: Creates, starts, and stops virtual machines;
- Virtual machine debugging services: Provides console, logs, and other debugging functions;
In the automotive field, the Hypervisor also faces the following challenges:
- Lightweight and efficient. While the Hypervisor brings the flexibility of software definition, it also leads to an increase in software stack layers, inevitably causing performance loss. The cost-sensitive nature of the automotive field necessitates a continuous demand to reduce performance loss in CPU, storage, network, GPU, and other peripherals, making the lightweight and efficient nature of the Hypervisor very important;
- Safe and reliable. Compared to the internet field, which emphasizes dynamic resource allocation and idle utilization, the automotive field places greater importance on the real-time, reliability, and safety of the Hypervisor;
- Convenient adaptation. In the automotive field, the variety of chip types and operating systems is rich and diverse. A significant feature of embedded virtualization is heterogeneity, and the Hypervisor must possess the ability to quickly adapt to different underlying hardware and upper-layer operating systems.
2. Technical Development Trends2.1 Differentiation of Key Technologies in Cloud, Edge, and End VirtualizationVirtualization technology can be traced back to the 1960s when IBM developed virtual machine monitor software that virtually divided computer hardware into one or more virtual machines, supporting multiple users’ simultaneous and interactive access to mainframe computers. With the improvement of general server computing power in the 21st century, cloud computing has flourished, and cloud virtualization, as a foundational supporting technology, has rapidly iterated and evolved. Later, computing power gradually descended from the cloud, edge, to the end, accompanied by the emergence of edge virtualization and end-side embedded virtualization. Their typical architectures and key technical requirements are shown in Figure 3.
Figure 3 Typical Architecture and Key Technical Requirements of Cloud, Edge, and End Virtualization(1) Cloud-side VirtualizationIts characteristics include a basically homogeneous hardware platform, with a large number of nodes forming a cluster. The architecture design prioritizes throughput capacity, supporting multi-business concurrency. Virtualization must meet resource scheduling strategies for cluster load balancing and energy saving. During cross-node virtual machine allocation, it must ensure uninterrupted business migration. In case of virtual machine failure, it must guarantee recovery from checkpoints to minimize business loss. Virtual machines must support elastic expansion of CPU computing power, memory, storage space, network, GPU, and peripheral capabilities, and must also allow over-allocation to enhance the operational benefits of data centers.(2) Edge-side VirtualizationThis is implemented at specific business edge nodes, using a general ICT architecture to support dynamic deployment of various businesses, typically seen in SDN and NFV. Its technical characteristics include: based on a general hardware platform and industry-customized management deployment platform, achieving soft-hardware decoupling and software definition, with multi-functional nodes deployed on demand and elastic networking. Generally, redundancy methods such as 1+1 or N+1 are used to ensure high availability of services. In 5G telecom network elements, the end-to-end real-time nature of 5G services must be considered, requiring design considerations for the Hypervisor, virtual machines, and communication protocol stacks.(3) End-side VirtualizationEnd-side virtualization typically features heterogeneity, with significant differences in chip architecture and processing capabilities. Generally, it is a single-chip solution, with no virtual machine migration between clusters or primary and backup. Therefore, it emphasizes high security and high reliability for single nodes, such as functional safety ASIL level requirements, while having stronger requirements for real-time and determinism. Additionally, end-side resources are more limited and cost-sensitive, necessitating lightweight and high-performance Hypervisors.2.2 Trends in Virtualization ModelsHypervisors can be divided into two main categories: one is Type 1 bare-metal, where the Hypervisor runs directly on hardware, also known as Bare-Metal Hardware Virtualization; the other is Type 2 hosted, also known as Hosted Virtualization. Figure 4 illustrates the layered architecture of the two types of Hypervisors.
Figure 4 Layered Architecture of Type 1 and Type 2 HypervisorsType 2 Hypervisors require a host operating system to manage CPU, memory, network, and other resources. Since there is a host operating system between the Hypervisor and hardware, all operations of the Hypervisor and VMs must go through the host operating system, which inevitably leads to latency and performance loss. Additionally, security flaws and stability issues in the host operating system can affect the VMs running on it. Therefore, Type 2 Hypervisors are mainly used in scenarios where performance and security requirements are not high, such as personal PC systems.Type 1 Hypervisors do not rely on a host operating system and possess basic operating system functions. They are designed to be simpler, running directly on hardware, with a more streamlined overall codebase and architecture, requiring less memory and storage resources, meeting the functional safety level requirements of 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 streamlined, only including basic and unchanging functions such as CPU scheduling and memory management, while device drivers and other variable components are outside the kernel. There is a debate in the industry about whether these types of Hypervisors 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 Routes between Hypervisors and Virtual Machines(1) Full VirtualizationThe initial virtualization was achieved by software simulating a computer system with complete hardware system functionality, running in an isolated environment, providing virtual hardware devices for Guest OS use. The advantage is that the Guest OS is unaware of the external real hardware environment and does not require modification. However, since each access to fully virtualized hardware in the Guest OS must trap into the Hypervisor, this leads to poor performance of the virtualized hardware, generally only used to simulate simpler hardware like serial ports. Hardware simulation can be directly simulated in the Hypervisor or requests can be passed to other VMs for simulation, such as simulating in a VM using QEMU.(2) Hardware-Assisted VirtualizationIntel was the first to propose hardware-assisted virtualization technology, providing shared functionality directly from hardware to support access by multiple Guest OS, reducing latency and performance loss caused by software virtualization technology. Intel proposed technologies such as Intel VT-x, Intel VT-d, and Intel VT-c, targeting processors & memory, IO, and networks, respectively. With the improvement of ARM computing power, evolving from mobile to edge and even cloud computing centers, ARM is also continuously enhancing its hardware-assisted virtualization technology, such as stage 2 page table translation and virtual exceptions.(3) Para-VirtualizationIn the development stage where hardware-assisted virtualization technology is not perfect or strong, or for sharing and reusing certain complex peripherals, para-virtualization technology can be adopted, where the Guest OS collaborates with the Hypervisor. This technology is generally applied to IO device virtualization, using a front-end and back-end approach to achieve IO device virtualization. The front-end driver is implemented in the Guest OS, while the back-end driver is implemented in the Hypervisor or Host OS, generally following the VirtIO standard. The front-end driver in the Guest OS communicates with the back-end driver through communication mechanisms such as Virt Queue, passing requests from the Guest OS to the back-end driver, which then sends the requests to the hardware driver and returns the results to the front-end driver. Para-virtualization achieves better hardware performance compared to full virtualization and can implement relatively complex hardware, such as block devices, network cards, display devices, etc. As shown in Figure 5.
Figure 5 Para-Virtualization Pass-through Resource AllocationThe Hypervisor supports directly allocating hardware resources to the Guest OS in its virtual machines without needing to go through the Hypervisor for address and instruction translation. For example, serial port resources, USB resources, and other interfaces can be directly allocated to a specific virtual machine using pass-through. Device controllers are generally accessed in MMIO mode, so it is only necessary to map the controller address area to the VM to achieve device controller allocation, while also allocating a virtual interrupt corresponding to a device hardware interrupt to that VM. The direct pass-through method allows the VM to exclusively access that hardware, providing the best performance.3. Key Technology Interpretation3.1 CPU Virtualization and Energy Saving TechnologyHigh-performance processors in vehicles generally adopt multi-core CPU architectures. In SMP (Symmetric Multi-Processing) architecture, the Hypervisor scheduler configures the guest operating system to run on specified CPUs based on CPU affinity. The operating system of the virtual machine can perform task scheduling on the CPU according to its scheduling method, such as priority-based scheduling. To maximize system resource utilization, the Hypervisor also supports multiple virtual machines sharing a specific CPU. On shared cores, the Hypervisor can schedule virtual machines using priority or time partitioning methods, ensuring that the running time and scheduling strategy of virtual machines are deterministic. The scheduling algorithm of the Hypervisor must ensure that no virtual machine within a partition enters a dead loop or fault that occupies processor resources for an extended period, preventing other virtual machines from receiving reasonable time allocations.Virtual machine scheduling also needs to consider energy-saving issues. When the workload is high, the system increases the main frequency to enhance user experience, while under low workload conditions, the system automatically saves energy by reducing frequency to improve endurance. High-performance vehicle processors are designed with big.LITTLE architectures for energy-saving needs, and the CPU and the complex operating systems running above need to support big.LITTLE scheduling, dynamic frequency scaling, low-power settings, shutting down CPU cores, and sleep (Suspend to RAM/Suspend to Disk) energy-saving functions. After system virtualization, physical resources such as CPUs must be accessed directly through the Hypervisor, and the Hypervisor’s scheduling algorithm must also support energy-saving for virtual machines.3.2 IO Device VirtualizationFor performance considerations, semi-virtualization technology is generally used in the embedded field. Semi-virtualization technology requires the front-end driver in the Guest OS to cooperate with the back-end driver in the Hypervisor. The front-end driver sends requests from the Guest OS to the back-end driver through the communication mechanism provided by the Hypervisor, and the back-end driver accesses the device by calling the physical driver. This involves the integration of different vendors’ Guest OS with different vendors’ Hypervisor ecosystems.Virtio is currently the most popular I/O semi-virtualization solution. Virtio is an open protocol and interface managed by the OASIS standards group, allowing virtual machines to access IO devices in a standardized manner. Virtio was officially standardized in March 2016, with version 1.1 released in 2020. The Virtio standard adopts a general and standardized abstract model, supporting an increasing number of device types, being highly efficient, widely used in cloud computing, and having 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 semi-virtualization technology in the automotive industry, as shown in Figure 6, where a device bus Virtio-bus is virtualized inside the Guest OS, allowing bidirectional communication between the front-end driver and back-end virtual devices mounted on the Virtio-bus, following 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 read and write using a caching mechanism, managed by the operating system where the Hypervisor resides. The virtio-blk driver is a block device driver compliant with the Virtio standard, with vdev virtio block as the back-end virtual block device. The virtio-blk driver completes read and write operations on the physical block device through this vdev device and obtains execution results.
- Using virtio-net technology to achieve cross-system communication
Virtio-net enables point-to-point communication between multiple systems. The virtio-net driver within the Guest system communicates with the virtio-net device of the system where the Hypervisor resides through virtqueue, achieving full-duplex communication for control and configuration commands and data exchange between multiple systems. It is suitable for data transmission other than audio and video streams, with good stability, although the complex control logic of virtqueue has some impact on real-time performance.
- Using virtio technology to achieve touch sharing
Touch devices are character-type devices, with the front-end driver and back-end device implemented through the virtio-input driver and vdev-input. The device side reports touch coordinate data to the driver through virtqueue.3.3 Real-time TechnologyReal-time performance is a key performance indicator of embedded real-time operating systems. The real-time performance of the Hypervisor is the foundation of the entire system’s real-time performance. If the Hypervisor cannot schedule the guest operating system to run in a timely manner, the guest operating system 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, with the longest delay time under various pressures being the interrupt latency. Scheduling latency refers to the time from when a high-priority virtual machine process is ready to when that high-priority virtual machine process is scheduled to run, with the longest delay time under various pressures being the scheduling latency.After interrupt virtualization, when an external interrupt occurs, the Hypervisor receives it and injects it into the virtual machine as quickly as possible, ensuring that the Hypervisor’s interrupt handling time for the virtual machine is minimal. The Hypervisor optimizes the switching time of virtual machines, minimizing the time spent on disabling interrupts and preemption, and minimizing the use of kernel locks. When a high-priority virtual machine needs to switch to run, it can switch to the high-priority virtual machine as quickly as possible.3.4 Security and Reliability TechnologyFunctional safety, information security, and reliability are essential components for the reliable and safe operation of vehicle control operating system products. The Hypervisor provides the foundational operating environment for intelligent vehicle domain controllers, and its security and reliability are the basis 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 its functional safety requirements derived from the safety requirements of the 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 experiences an exception, the Hypervisor should monitor the system’s health status in real-time, effectively isolating faults and repairing exceptions within the smallest possible impact range, ensuring the system remains available.Integrating the Hypervisor into the automotive software stack increases the vertical software stack layers and the horizontal complexity of business software, while the safety and reliability requirements of automotive systems are stronger than those of existing cloud-side virtualization and edge virtualization. Therefore, the security of virtualization is increasingly gaining industry attention. These security aspects include:
- The trust chain issue between the virtual machine manager and virtual machines. Using virtualization technology to create multiple virtual machines on a trusted physical platform and passing the trust chain built from the hardware root of trust 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 virtual machine manager to gain control over a virtual machine through another virtual machine on the same physical host, thereby compromising the target virtual machine;
- Virtual machine escape: Attacks using vulnerabilities in the virtual machine software or software running in the virtual machine to attack or control the virtual machine host operating system.
To enhance the security of the Hypervisor, it is crucial to establish corresponding security objectives. The table below briefly lists the relevant requirements:
The security capabilities of the Hypervisor can be enhanced from three dimensions.(1) Establishing Security BoundariesAs shown in Figure 7, this boundary is strictly defined and enforced by the Hypervisor. The confidentiality, integrity, and availability of the Hypervisor security boundary must be guaranteed. The boundary can defend against a range of attacks, including side-channel information leakage, denial of service, and privilege escalation. The Hypervisor security boundary also provides isolation capabilities for network traffic, virtual devices, storage, computing resources, and all other virtual machine resources.
Figure 7 Security BoundaryThe 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 spaces of entities.
Figure 8 Overall Virtualization Security ArchitectureThe isolation of the security boundary is supported by the Hypervisor’s vCPU scheduling isolation security, memory isolation, network isolation, and storage isolation technologies, achieving isolation between the Hypervisor and virtual machines on the same physical machine, as well as between virtual machines.(2) Establishing Deep Defense Vulnerability Mitigation MechanismsFor 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 ProcessesThe attack surface related to the Hypervisor includes 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 a crucial 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, the 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 the Hypervisor, necessitating continuous enrichment and improvement of security measures in practice.4. Typical Application CasesIn the development of automotive intelligence, virtualization is mainly applied in integrated scenarios such as intelligent cockpits, intelligent driving, and intelligent gateways. Intelligent driving is limited by technological maturity and policy regulations, primarily remaining in the research and prototype stages. The business functions of intelligent gateways are relatively homogeneous and may further integrate into other scenario solutions. Therefore, the current main application cases are concentrated in intelligent cockpits.The integration of intelligent cockpit domains has also started in recent years and is continuously iterating and evolving. Influenced by factors such as chip computing power, the maturity of virtualization technology, and the ecosystem’s control over virtualization solutions, some manufacturers have adopted hardware isolation solutions to achieve domain integration, maximizing the use of existing technical capabilities with certainty but lacking the flexibility of software definition, resulting in limited intelligence. This is an optional solution for domain integration. In terms of embedded virtualization technology, foreign companies like QNX, OpenSynergy, and PikeOS have a first-mover advantage, especially in the automotive field, where they have been cultivating for many years, leading to a surge of application cases in recent years. Driven by the trend of localized intelligent development, many domestic chip manufacturers and independent software vendors have developed embedded virtualization technologies, products, and solutions in recent years, such as Zhongling Zhixing’s RAITE Hypervisor (RHOS), ZTE’s GoldenOS, Banma Zhixing’s AliOS Hypervisor, and CAIC Hypervisor from China Automotive Innovation.4.1 Intelligent Cockpit Domain Controller ProductsA certain manufacturer’s intelligent 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, capable of configurable output of up to 6 high-definition large screens independently, integrating entertainment systems, LCD instruments, body control, DMS, APA, and other functions, supporting independent four-zone audio, multi-screen interaction, and audio-video sharing, with high integration, adapted for mass production in multiple models such as Great Wall, Changan, and Yutong buses.Additionally, the domestic solution, Chipstar X9HP+ platform, flexibly configures to achieve mid-to-low-end intelligent cockpit domain controller products using both hard partitioning and Hypervisor solutions.
Figure 9 Intelligent Cockpit Domain Controller
Figure 10 Domestic Solution Intelligent Cockpit Domain Controller4.2 RHOS Intelligent Cockpit Domain Controller Platform(1) NXP I.MX8QM Cockpit Domain ControllerA certain manufacturer has developed a lightweight and flexible automotive intelligent cockpit virtualization solution based on its self-developed Type-1 virtualization software RHOS (Raite Hypervisor OS), supporting NXP I.MX8QM, which has been mass-produced and launched in Dongfeng models. Its system architecture is shown in Figure 11:
Figure 11 NXP I.MX8 Intelligent Cockpit System ArchitectureRunning the Hypervisor on the SoC supports the simultaneous operation of multiple operating systems, such as the Linux system running high real-time and security-critical tasks like fully digital dashboards, while also extending to run DMS, HUD, and other tasks. Another virtual machine runs the Android operating system, deploying infotainment and other tasks with lower security and real-time requirements. To ensure the system has good market competitiveness, the domain controller is compatible with TBOX functional requirements, supporting sleep wake-up and fast startup.Linux and Android virtual machines can be configured with resources as needed, including memory, CPU, storage space, and peripherals. This architecture supports system upgrades, including upgrades to virtual machines and the Hypervisor, and supports exception log recording, including virtual machine kernel and Hypervisor logs.Multi-screen interaction is an important application scenario for intelligent cockpits, where Android app applications can be pushed to the Linux dashboard for display through the Hypervisor.
Figure 12 Virtual Machine Multi-Screen Interaction ArchitectureThe interaction scheme between Android and Linux dashboards is shown in Figure 12. The NXP I.MX8QM chip has more than two display interfaces, each capable of connecting two displays. When the Android system needs to project information onto the dashboard screen, the overlay layer of the dashboard display can show the projected content. The system interaction has zero latency and zero copy, and multi-system interaction does not additionally occupy CPU and GPU resources. The Hypervisor virtualization technology enables cross-system multi-screen interaction, effectively improving driving safety and reducing the hardware costs of intelligent cockpits.(2) MT8675 Cockpit Domain ControllerRHOS, by adapting to support MT8675, forms a feature-rich, cost-effective multi-screen intelligent cockpit domain controller solution, which has obtained mass production projects from multiple automakers. Its overall system architecture is shown in Figure 13:
Figure 13 MT8675 Intelligent Cockpit System ArchitectureMT8675 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, achieves industry-leading virtualization effects (loss < 6%). RHOS supports Suspend to RAM functionality, with the MT8675 A core completely powered down, meeting the requirement for intelligent cockpit standby static power consumption to be less than 4mA.5.3 KCS 3.0 Intelligent Cockpit Virtualization PlatformA certain manufacturer has developed the KSC3.0 intelligent cockpit virtualization platform based on Renesas H3/M3 + QNX Hypervisor2.x, supporting “one chip, multiple screens”, enabling multiple systems to run simultaneously on one SoC, including QNX dashboard, Android central control, and passenger side, supporting the following features:
- 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 emotional recognition, etc.
The platform is displayed in Figure 14:
Figure 14 KCS 3.0 Intelligent Cockpit Virtualization PlatformAdditionally, this manufacturer has developed a digital twin platform based on X86+KVM+QEMU, using virtualization technology to simulate hardware development platforms, including support for multiple cameras, multiple display outputs, multi-system audio mixing, screen sharing, and multiple CAN signals, effectively solving developers’ reliance on real hardware platforms during the development process of SOA platforms.This article is excerpted from the “China Automotive Basic Software Development White Paper 3.0”, which focuses on the theme of “Automotive Basic Software Platform”, discussing its technical forms and key technologies in depth, sharing knowledge outcomes.Click the end of the article “Read the original text” to download the “2022 Basic Software White Paper 3.0” PDF for free.
AUTOSEMO Background
Given the importance of the development of basic automotive software in China, at the request of major domestic automotive enterprises and with the approval of the competent authorities, the China Automotive Industry Association (CAAM) decided in December 2019 to establish the China Automotive Basic Software Ecosystem Committee (AUTOSEMO). The aim is to unite members from the automotive and software industries to form a jointly planned and created software architecture and interface specifications led by local enterprises, strengthen local basic software, promote industry openness and collaboration, and facilitate the industry’s development towards greater intelligence. In the current complex and changing international industrial competition trend, establishing AUTOSEMO has significant strategic and practical significance.To join AUTOSEMO, please contact:Contact: Geng Mingxiao Email: [email protected]