Virtualization device and intelligent cockpit
By using a lightweight virtualization solution, the problems of system crashes, virtual machine failures, and uneven resource distribution in the smart cockpit were solved, achieving efficient and low-cost resource virtualization and backup recovery, and improving system compatibility and portability.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- FUZHOU ROCKCHIP SEMICON
- Filing Date
- 2026-02-26
- Publication Date
- 2026-06-19
AI Technical Summary
Existing virtualization technologies for smart cockpits suffer from problems such as system crashes, virtual machine failures, uneven distribution of resources among multiple virtual machines, and low container efficiency.
A lightweight virtualization solution is adopted, including a virtual machine manager, virtual machine containers, and optional dual-machine virtual machine containers. Through lightweight container hot backup, lightweight container disaster recovery, and lightweight computing resource management, efficient and low-cost resource virtualization is achieved.
It implements a lightweight, highly compatible, and highly portable backup and recovery mechanism, improving backup efficiency and ensuring efficient system operation and reasonable resource allocation.
Smart Images

Figure CN122240238A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of virtualization technology, and more particularly to virtualization devices and smart cockpits. Background Technology
[0002] Intelligent cockpits contain CPUs with different architectures (ARM / RISK-V / DSP / MCU, etc.) and operating systems (ROS / RTOS / Linux / Android). Application processors are now increasingly powerful, featuring advanced characteristics such as high clock speeds, large cores, and heterogeneous multi-core architectures. Powerful application processors can optimize the electronic system architecture of intelligent cockpits, reducing the number of main controllers and communication connections. Currently, a single application processor can support multiple independent operating systems through virtualization technology to ensure compatibility with classic intelligent cockpit hardware and software architectures. For example, the application processor might use ROS / RTOS as the base system, virtualized Linux as the intelligent driving system, and multiple virtualized Android systems as the in-vehicle entertainment system. However, this single-chip, multi-system virtualization approach has the following problems: 1) system crashes; 2) virtual machine crashes; 3) resource distribution issues across multiple virtual machines; and 4) container efficiency issues. Summary of the Invention
[0003] This invention provides virtualization devices and smart cockpits that enable efficient and low-cost resource virtualization.
[0004] In one aspect of the present invention, a virtualization device is provided. The virtualization device includes: at least one virtual machine container; and a virtual machine manager, including a management module, the management module comprising a container hot backup module and a container disaster recovery module, wherein the container hot backup module is configured to collect and store core runtime metadata of the virtual machine instance on the virtual machine container, the core runtime metadata including at least one of running applications and interfaces, network connection status, core system service status, and application personal settings, wherein the container disaster recovery module is configured to perform hot switching based on the core runtime metadata of a virtual machine instance that has crashed or is unresponsive.
[0005] In another aspect of the invention, a smart cockpit is provided. The smart cockpit includes the virtualization device described above.
[0006] According to the technical solution of the present invention, a lightweight backup mechanism is achieved by simplifying snapshots, thereby improving backup efficiency. At the same time, a lightweight non-full recovery scheme is adopted. Compared with complex hot backup schemes such as complex memory snapshots, storage snapshots and configuration snapshots, as well as complex disaster recovery schemes such as complex memory recovery, storage recovery and configuration recovery, the present invention has the characteristics of being lightweight, highly compatible and more portable. Attached Figure Description
[0007] Figure 1 This is a schematic diagram of the structure of a virtualization device according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of a virtualization device in a specific scenario according to an embodiment of the present invention; Figure 3 This is a flowchart of a container hot backup process in a specific scenario according to an embodiment of the present invention; Figure 4 This is a flowchart of a disaster recovery process in a specific scenario according to an embodiment of the present invention; Figure 5 This is a flowchart of a computing resource management process in a specific scenario according to an embodiment of the present invention. Detailed Implementation
[0008] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.
[0009] In existing technologies, the redundant design architecture of an in-vehicle domain control system based on virtualization hot migration deploys a virtualization layer on the in-vehicle domain control unit. Within this virtualization layer, multiple virtual machines are created and managed, including a redundant backup virtual machine and several application execution virtual machines. Applications within the domain control unit are divided and isolated to run under different application execution virtual machines. During the operation of the domain control system, the virtualization layer monitors the working status of each application execution virtual machine in real time. When an abnormality is detected in an application execution virtual machine, hot migration is immediately initiated to completely save the application and resource allocation information of that virtual machine, migrating the image file to the redundant backup virtual machine in real time, and then hot-starting the application in the new virtual machine environment. After the hot migration recovers, the virtual hardware resources of the abnormal execution virtual machine are initialized and redeployed as a new redundant backup virtual machine. This solution uses full virtualization technology, which offers high flexibility but also incurs significant performance overhead.
[0010] Full virtualization means that the hypervisor (virtual machine monitoring program, such as VMware and KVM) directly simulates the entire hardware. The guest operating system does not need to be modified, but simulating the entire machine results in higher performance overhead (due to instruction translation).
[0011] Existing virtualization technologies also include operating system virtualization (such as Docker), containerization technology based on a shared Linux kernel, and process isolation using namespaces and cgroups. Although containers start quickly and have minimal resource overhead, their isolation is weak, and multiple containers share the same kernel.
[0012] To address at least the aforementioned technical issues, this disclosure provides a lightweight virtualization solution. According to this disclosure, the virtual machine architecture of the virtualization device includes a virtual machine manager, virtual machine containers, and optional dual-machine virtual machine containers. The virtual machine manager includes a simplified host operating system, virtualization drivers, and a virtual machine manager program. The virtual machine manager program includes: lightweight container hot backup, lightweight container disaster recovery, and lightweight computing resource management. The virtualization driver mainly includes GPU virtualization, virtualized displays, and computing resource management; lightweight container hot backup employs a lightweight, highly compatible backup mechanism to quickly establish standby instances; lightweight container disaster recovery is used to achieve localized recovery under hardware constraints; and lightweight computing resource management is used to achieve cross-node resource pooling and targeted allocation.
[0013] In this way, embodiments of the present disclosure employ a lightweight, resource-centralized virtualization scheme for embedded scenarios, which enables lightweight virtualization and achieves efficient, low-cost resource virtualization.
[0014] In the following, the technical solutions according to this disclosure will be described with reference to specific embodiments and in conjunction with the accompanying drawings.
[0015] Figure 1 This is a schematic diagram illustrating a virtualization device 100 according to an embodiment of the present disclosure. (Refer to...) Figure 1 The virtualization device 100 includes a virtual machine manager 110 and at least one virtual machine container 120.
[0016] The virtual machine manager 110 includes an operating system module 111 and a management module 112. The operating system module 111 includes a simplified host operating system. The management module 112 includes a container hot backup module 1121 and a container disaster recovery module 1122. The container hot backup module 1121 is configured to collect and store core runtime metadata of the virtual machine instances on the virtual machine container 120, including at least one of the following: running applications and interfaces, network connection status, core system service status, and application personal settings. Additionally, the container disaster recovery module 1122 is configured to perform hot switching based on the core runtime metadata of virtual machine instances that have crashed or become unresponsive.
[0017] In some embodiments, the virtual machine manager 110 further includes a virtualization driver module 113. The virtualization driver module 113 is configured to virtualize the graphics processor, the display, and manage the NPU computing resources of the virtual machine container 120. In this way, by virtualizing the GPU, each virtual machine container has an independent GPU context; by virtualizing the display, containers without a physical screen can render normally, meeting the needs of background services; and by managing NPU computing resources, the aggregation and centralized use of computing resources can be supported.
[0018] In some embodiments, the container hot backup module 1121 is specifically configured to: start a business virtual machine instance; initiate a hot backup of the business virtual machine instance; collect the core runtime metadata of the business virtual machine instance; and store the core runtime metadata of the business virtual machine instance in a shared data partition. In this way, a lightweight and highly compatible backup mechanism simplifies snapshots and improves backup efficiency.
[0019] In some embodiments, the container disaster recovery module 1122 is specifically configured to: monitor the running status of the business virtual machine instance through heartbeat detection or log analysis; when a system crash or application unresponsiveness of the business virtual machine instance is detected, designate the business virtual machine instance with the system crash or application unresponsiveness as a crashed virtual machine instance, and obtain the core running metadata of the crashed virtual machine instance; based on the core running metadata of the crashed virtual machine instance, configure a backup virtual machine instance as a business virtual machine instance, and take over the display connected to the crashed virtual machine instance; configure the crashed virtual machine instance as a backup virtual machine instance; use the virtual display, and restart the crashed virtual machine instance. In this way, a lightweight non-full recovery solution is achieved, featuring lightweight design, high compatibility, and higher portability.
[0020] In some embodiments, the business virtual machine instance and the backup virtual machine instance are configured on the same virtual machine container 120. This avoids the disaster recovery function being unable to function properly due to hardware limitations.
[0021] In some embodiments, the management module 112 further includes a computing resource management module 1123, which is configured to cascade the computing resources of the neural network processors of each virtual machine container and to allocate the computing resources in a targeted manner. This ensures resource availability for critical tasks.
[0022] In some embodiments, the computing resource management module 1123 is specifically configured to: discover and register the computing resources of the neural network processors of each virtual machine manager; have a computing virtual machine apply for exclusive use of the computing resources, wherein the computing virtual machine is the virtual machine that hosts the most computations of the neural network processor; have the computing virtual machine perform pre-processing operations on the combined model to be executed; have the computing virtual machine direct each model in the combined model to be executed to the neural network processors of each virtual machine manager for execution; and have the computing virtual machine perform post-processing operations on the combined model to be executed. In this way, computing resources are uniformly managed across virtual machine containers, enabling the completion of large-scale model tasks or multi-model tasks that cannot be completed by a single chip.
[0023] In some embodiments, virtual machine containers are connected via a high-speed bus.
[0024] The following will describe application scenarios of the virtualization device according to embodiments of the present invention through examples.
[0025] Figure 2 This is a schematic diagram illustrating the virtual machine architecture of a virtualization device according to an embodiment of the present invention. Figure 2 As shown, the virtual machine architecture includes a virtual machine manager and two virtual machine containers. The virtual machine manager contains an operating system module (a simplified host operating system), a virtualization driver module (virtualization driver program), and a management module (virtual machine manager program). The management module includes a container hot backup module (lightweight container hot backup), a container disaster recovery module (lightweight container disaster recovery), and a computing resource management module (lightweight computing resource management).
[0026] The virtual machine manager is responsible for managing the virtualization drivers of hardware resources and managing multiple virtual machine instances. The virtual machine manager and virtual machine containers use the same set of hardware resources, but the virtual machine manager is responsible for the hardware resource allocation rules for the virtual machine containers. The virtual machine manager can manage multiple virtual machine containers. For example, it can have two onboard RK3588 chips interconnected via a high-speed bus (PCIe 3.0, USB 3.0, or C2C bus). The master RK3588 chip hosts four Android containers; the slave RK3588 chips host four Android containers. The virtual machine manager runs on the master RK3588 chip and can manage these eight Android containers uniformly. Both the master and slave RK3588 chips have external SRAM or external interface units. The master RK3588 chip directly accesses the NVMe SSD (Solid State Drive), while the slave RK3588 chip indirectly accesses the NVMe SSD through a high-speed interface.
[0027] In this embodiment, the virtualization driver module is deeply customized for embedded hardware, prioritizing performance and real-time capabilities over general compatibility. Specifically, it mainly includes: 1) GPU Virtualization: Using the Mali GPU SR-IOV driver method, each virtual machine container is provided with an independent GPU (Graphics Processing Unit) context, ensuring that each virtual machine has an independent GPU context, achieving hardware-level isolation and low latency.
[0028] 2) Virtualized display: Configure a virtualized display for virtual machines that are not connected to a physical display to ensure that virtual machine containers without a physical screen can render normally and meet the needs of background services.
[0029] 3) NPU Resource Management: Manages the NPU (Neural-network Processing Unit) computing resources of multiple machines, supports the aggregation and centralized use of computing resources, that is, cross-chip NPU resource aggregation, unified scheduling, and on-demand allocation (such as allocating only parking VMs).
[0030] The container hot backup module (lightweight container hot backup) prioritizes efficiency by simplifying snapshots. The backup mechanism is a non-memory / storage snapshot, employing a lightweight and highly compatible solution, potentially based on configuration synchronization or incremental state replication. Designed to quickly establish standby instances, it sacrifices consistency for speed and resource savings.
[0031] Figure 3 This is a flowchart illustrating a container hot backup process in a specific scenario according to an embodiment of the present invention. For example... Figure 3 As shown, the container hot backup process includes the following steps S301 to S304.
[0032] S301: The virtual machine manager starts the business virtual machine instance.
[0033] S302: The virtual machine manager initiates a hot backup of the business virtual machine instance.
[0034] S303: Collects core runtime metadata of business virtual machine instances.
[0035] S304: Store the core runtime metadata of the business virtual machine instance in a shared data partition.
[0036] In this embodiment, to restore Android's services, the backup is not a complete snapshot of the entire system, but rather key runtime context information that allows the newly launched Android system to seamlessly take over the old system state. Therefore, the core runtime metadata includes: 1) Running applications and interfaces: Record which application is in the foreground, which is in the background, and their respective interface stacks. This way, after restoration, the user will still see the original application and page.
[0037] 2) Network connection status: Save the current IP address and active network connections (such as currently playing online music streams) to ensure that the application can reconnect to the network immediately after recovery.
[0038] 3) Core system service status: such as screen on / off status, volume level, who holds the wake-up lock to prevent system hibernation, etc. By "telling" the new system these statuses, it can mimic the previous environment.
[0039] 4) Application personal settings: Backup system settings database, which stores the personalized preferences of all applications.
[0040] In this embodiment, the virtual machine manager monitors and collects the core runtime metadata of the virtual machine instance. In other embodiments, the virtual machine container may also actively save and report the core runtime metadata. The core runtime metadata is used for virtual machine instance recovery and is persistently saved in formats such as JSON or XML. The virtual machine instance and its backup instance share application data in the data partition and share the core runtime metadata.
[0041] This embodiment uses a lightweight container hot backup solution, which does not employ complex hot backup solutions such as memory snapshots, storage snapshots, and configuration snapshots. It features lightweight design, high compatibility, and higher portability.
[0042] The container disaster recovery module (lightweight container disaster recovery) is used for localized recovery under hardware constraints. The recovery mechanism is not a full recovery; it employs a lightweight solution and may only restore critical states or restart services. In real-world applications, virtualized devices typically have business virtual machines connected to a monitor. These business virtual machines and backup virtual machines need to be configured on the same chip instance; otherwise, the disaster recovery function will not function properly due to display hardware constraints, and cross-node migration and recovery will be impossible. By deploying the primary and backup containers on the same chip, cross-physical machine migration and recovery are supported, offering high flexibility.
[0043] Figure 4 This is a flowchart illustrating a disaster recovery process in a specific scenario according to an embodiment of the present invention. For example... Figure 4 As shown, the disaster recovery process includes the following steps S401 to S405.
[0044] S401: The virtual machine manager monitors the running status of the business virtual machine instance, that is, it monitors whether the business virtual machine instance has crashed or experienced an ANR (Application Not Response).
[0045] In practical applications, a monitoring mechanism can be configured to monitor the virtual machine status in real time through methods such as heartbeat detection and log analysis. It is necessary to precisely adjust the monitoring parameters to avoid oversensitivity leading to false alarms or overly lenient parameters leading to missed alarms.
[0046] S402: When a system crash or ANR is detected in a business virtual machine instance, the virtual machine manager obtains the core runtime metadata of the crashed virtual machine instance, that is, it obtains the core runtime metadata of the business virtual machine instance that has crashed or experienced ANR.
[0047] In real-world applications, ensuring the accuracy of captured data during a system crash is a challenge. To address this, the acquired core runtime metadata can be validated, discarding incomplete or missing metadata to guarantee data accuracy.
[0048] S403: The virtual machine manager configures the backup virtual machine instance as the business virtual machine role and takes over the screen of the crashed virtual machine instance.
[0049] This step dynamically adjusts the configuration of the hot standby system, enabling it to assume the original master or slave role, achieving seamless switching and maintaining an unaffected user experience. In real-world applications, hot switching involves a slight switching delay, and there may still be a brief (a few hundred milliseconds) period of service unavailability during the actual switching process.
[0050] S404: The virtual machine manager has configured the crashed virtual machine instance as a backup system role, i.e., configured it as a backup virtual machine instance.
[0051] This step downgrades the failed instance to a backup state, preparing it for new tasks or as a further hot backup. Furthermore, it cleans up residual sessions and resource usage to ensure a clean state transition.
[0052] S405: The virtual machine manager attempted to use a virtual monitor to restart the crashed virtual machine instance.
[0053] This step starts the virtual display driver, simulating the behavior of a physical monitor and supporting the normal startup of graphical user interface applications. It then restores the virtual machine to its most recent correct state. In real-world applications, the restored user interface may not fully synchronize all previous interaction details.
[0054] Furthermore, the virtual machine manager executes the above hot backup process according to the switched system role. That is, based on the actual role of each node, it performs a series of operations such as monitoring, data collection, and role switching in a loop to maintain a high availability architecture and ensure that any single failure will not affect the entire service chain.
[0055] This embodiment uses a lightweight container disaster recovery solution, which does not employ complex disaster recovery solutions such as memory recovery, storage recovery, and configuration recovery. It features lightweight design, high compatibility, and higher portability.
[0056] The computing resource management module (lightweight computing resource management) is used for cross-node resource pooling and targeted allocation. The resource scope includes the resources of each virtual machine container; in this embodiment, it uniformly manages NPU, GPU, memory, and other resources across dual chips (master and slave RK3588 chips) to form a resource pool. The scheduling strategy employs targeted allocation; for example, NPU resources are allocated only to the intelligent parking VM, ensuring resource security for critical tasks. The management granularity is geared towards specific business applications (such as AI parking), emphasizing deterministic QoS (Quality of Service).
[0057] In real-world applications, not all virtual machine instances need to use NPU resources. NPU virtualization drivers support multi-machine NPU computing resources, enabling the aggregation and centralized use of these resources. For example, two RK3588 machines with six cores (three cores x two) can be managed uniformly and allocated only to the intelligent parking virtual machine instance.
[0058] Figure 5 This is a flowchart illustrating a computing resource management process in a specific scenario according to an embodiment of the present invention. For example... Figure 5 As shown, the computing resource management process includes the following steps S501 to S505.
[0059] S501: The Virtual Machine Manager discovers and registers the NPU computing resources of the master virtual machine container and slave virtual machine containers.
[0060] Specifically, if the master RK3588 chip and the slave RK3588 chip are interconnected through a high-speed interface (PCIe 3.0, USB 3.0 or C2C bus), the virtual machine manager can discover and register the NPU computing resources of the master RK3588 chip and the slave RK3588 chip through the high-speed interface.
[0061] Cascading NPU computing resources allows the NPU computing resources of multiple chips to be cascaded together to collaboratively complete large-scale model tasks or multi-model tasks that cannot be completed by a single chip.
[0062] S502: Computational virtual machines request exclusive NPU computing resources. Computational virtual machines are virtual machines that need to support a large amount of NPU computing.
[0063] Specifically, an asymmetric / peer-to-peer approach is adopted to allow NPU heavy-load virtual machines to exclusively occupy NPU computing resources to complete large-scale NPU application tasks (such as automatic parking).
[0064] S503: Computational virtual machines uniformly execute preprocessing operations (non-model-based computational workloads) of composite models, where the composite models include the first model and the second model.
[0065] S504: The compute virtual machine uses the NPU virtualization driver to direct the first model to the NPU of the master virtual machine container (master RK3588 chip) for execution, and directs the second model to the NPU of the slave virtual machine container (slave RK3588 chip) for execution.
[0066] S505: Computational virtual machines uniformly execute post-processing operations (non-model-based computational load) of composite models.
[0067] This embodiment employs a naive chip cascading approach to collaborate on NPU computing resource cascading, and also uses a naive model cascading approach to complete collaborative computation of NPU models.
[0068] According to another aspect of the present invention, a smart cockpit is provided. This smart cockpit includes the virtualization device described above, which will not be repeated here to avoid repetition.
[0069] In summary, the virtualization device and intelligent cockpit provided by this invention are virtualizations tailored for specific scenarios. While ensuring key functions, they achieve efficient, deterministic, and low-cost resource virtualization through simplified mechanisms, hardware passthrough, and cross-node collaboration, which stands in stark contrast to the "large and comprehensive" approach of general virtualization.
[0070] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.
Claims
1. A virtualization device, characterized in that, include: At least one virtual machine container; as well as The virtual machine manager includes a management module, which further includes a container hot backup module and a container disaster recovery module. The container hot backup module is configured to collect and store core runtime metadata of the virtual machine instance on the virtual machine container. This core runtime metadata includes at least one of the following: running applications and interfaces, network connection status, core system service status, and application personal settings. The container disaster recovery module is configured to perform hot switching based on the core runtime metadata of virtual machine instances that have crashed or become unresponsive.
2. The virtualization device according to claim 1, characterized in that, The container hot backup module is configured as follows: Start the business virtual machine instance; Initiate hot backup of the aforementioned business virtual machine instance; Collect the core runtime metadata of the business virtual machine instance; and The core runtime metadata of the business virtual machine instance is stored in a shared data partition.
3. The virtualization device according to claim 2, characterized in that, The container disaster recovery module is configured as follows: Monitor the running status of the business virtual machine instance; When a system crash or application unresponsiveness is detected in the business virtual machine instance, the business virtual machine instance that crashed or became unresponsive is identified as a crashed virtual machine instance, and the core runtime metadata of the crashed virtual machine instance is obtained. Based on the core runtime metadata of the crashed virtual machine instance, the backup virtual machine instance is configured as a business virtual machine instance and takes over the display connected to the crashed virtual machine instance. Configure the crashed virtual machine instance as a backup virtual machine instance; as well as Use a virtual monitor and restart the crashed virtual machine instance.
4. The virtualization device according to claim 1, characterized in that, The management module also includes a computing resource management module. The computing resource management module is configured to cascade the computing resources of the neural network processors of each virtual machine container and to allocate the computing resources in a targeted manner.
5. The virtualization device according to claim 4, characterized in that, The computing resource management module is configured as follows: Discover and register the computing resources of the neural network processors of each virtual machine manager; The computing resources are exclusively requested by a computing virtual machine, which is the virtual machine that hosts the most computations of the neural network processor; The computational virtual machine performs the preprocessing operations for the combined model to be executed; The computational virtual machine directs each model in the combined model to be executed to the neural network processor of each virtual machine manager for execution. as well as The computational virtual machine performs the post-processing operations of the combined model to be executed.
6. The virtualization device according to claim 1, characterized in that, The virtual machine manager also includes a virtualization driver module. The virtualization driver module is configured to virtualize the graphics processor, the display, and the computing resources of the neural network processor that manages the virtual machine container of the at least one of them.
7. The virtualization device according to claim 1, characterized in that, The virtual machine manager also includes an operating system module. The operating system module includes a simplified host operating system.
8. The virtualization device according to claim 1, characterized in that, The virtual machine manager is positioned to manage the virtualization drivers of hardware resources and the management of multiple virtual machine instances.
9. The virtualization device according to claim 3, characterized in that, The business virtual machine instance and the backup virtual machine instance are configured on the same virtual machine container.
10. The virtualization device according to claim 3, characterized in that, The running status of the business virtual machine instance is monitored through heartbeat detection or log analysis.
11. The virtualization device according to any one of claims 1 to 10, characterized in that, The virtual machine containers are connected via a high-speed bus.
12. An intelligent cockpit, characterized in that, Includes the virtualization device according to any one of claims 1 to 11.