Intelligent cockpit system based on type i virtualization technology and resource division method thereof

Abstract

The application relates to an intelligent cockpit system based on a Type I virtualization technology and a resource division method thereof. The system comprises a hardware platform, at least one virtualization-supported processor, memory, storage device and peripheral device; a Type I virtualization management program running on the hardware platform and directly managing hardware resources; a first virtual customer system running an embedded Linux system and used for driving an instrument display screen; and a second virtual customer system running an Android system and used for driving a central control display screen. Two independent customer systems are virtually generated on a single hardware platform through the Type I virtualization management program, and embedded Linux and Android are respectively run to support the functions of the instrument screen and the central control screen. Through CPU time-sharing scheduling, independent memory division, device direct connection and sharing combination, efficient isolation and reuse of resources are realized, so that the hardware resource utilization rate is effectively improved, and the system cost and power consumption are reduced.

Description

Technical Field

[0001] This invention belongs to the intersection of intelligent cockpit and virtualization technology, specifically involving a cockpit architecture that uses Type I virtualization technology to achieve multi-system integration in an in-vehicle environment, and is particularly suitable for intelligent cockpit platforms that integrate instrument systems and infotainment systems. Background Technology

[0002] Traditional smart cockpits typically employ two independent hardware systems to support instrument panel and central control functions respectively, resulting in high cost, high power consumption, and low integration. With the development of virtualization technology, especially the maturity of Type I virtualization, it has become possible to run multiple operating systems simultaneously on a single hardware platform. However, the in-vehicle environment has strict requirements for real-time performance, security, and resource isolation, and existing virtualization solutions still have room for optimization in areas such as device passthrough, memory allocation, and interrupt handling.

[0003] Therefore, it is necessary to propose a solution to overcome the shortcomings of the current existing technology. Summary of the Invention

[0004] The purpose of this invention is to overcome the shortcomings of the prior art and provide an intelligent cockpit system based on Type I virtualization technology and its resource allocation method, so as to realize the simultaneous operation of the instrument system and the central control system on a single computing platform, and ensure the real-time performance, security and performance of the system through refined resource allocation and device pass-through strategy.

[0005] To achieve the above objectives, the intelligent cockpit system based on Type I virtualization technology and its resource allocation method of the present invention are as follows: The main feature of this intelligent cockpit system based on Type I virtualization technology is that the system includes: The hardware platform includes at least one processor, memory, storage device, and peripheral devices that support virtualization. Type I virtualization management program runs on the aforementioned hardware platform and directly manages hardware resources; The first virtual client system runs an embedded Linux system and is used to drive the instrument display screen; The second virtual client system runs on Android and is used to drive the central control display screen; The Type I virtualization management program divides hardware resources into multiple independent partitions and allocates them to the first virtual client system and the second virtual client system respectively.

[0006] Preferably, the Type I virtualization manager is a Xen-based Hypervisor that runs at the EL2 exception level of the ARMv8 architecture processor.

[0007] Preferably, the peripheral devices include at least one of a GPU, an audio codec, a WIFI module, a Bluetooth module, and a USB controller, and some devices are assigned to a designated virtual client system for exclusive use via a pass-through method.

[0008] Preferably, the GPU and audio codec are directly allocated to the first virtual client system, and the second virtual client system shares the GPU and audio codec through a front-end and back-end driver architecture.

[0009] Preferably, the Type I virtualization management program implements memory virtualization through the system memory management unit, allocating an independent physical memory region for each virtual guest system.

[0010] Preferably, memory virtualization is achieved using SMMU technology on the ARM platform, VT-d technology on the Intel platform, and AMD-Vi technology on the AMD platform.

[0011] Preferably, the processor virtualization is achieved through native virtualization support of ARM architecture, Intel VT-x technology or AMD-V technology, and interrupt virtualization is achieved through GIC or APICv technology.

[0012] Preferably, the storage device is partitioned using the Type I virtualization management program, with each virtual client system mounting an independent storage partition.

[0013] Preferably, the system further includes: A front-end and back-end driven architecture is used to share device resources between virtual client systems; A shared memory region used for communication and data exchange between virtual client systems.

[0014] Preferably, the first virtual client system and the second virtual client system communicate with each other through network virtualization; The Type I virtualization management program virtualizes a multi-port switch and assigns a virtual network port to each virtual client system to enable cross-system network communication.

[0015] Preferably, the first virtual client system and the second virtual client system communicate with each other through a shared memory and event channel mechanism; The shared memory region is managed with access control through an authorization table, and the event channel is used to transmit read and write control signals.

[0016] The method for resource allocation using the system described above is characterized by the following steps: (1) The virtualization management program identifies hardware resources at startup; (2) Divide the CPU core into multiple virtual CPUs according to the preset strategy and schedule them to each virtual client system in a time-sharing manner; (3) Divide the physical memory into multiple independent regions and map them to each virtual client system respectively; (4) Assign peripheral devices to the corresponding virtual client systems in either pass-through or shared mode; (5) Allocate an independent storage partition for each virtual client system.

[0017] Preferably, the memory partitioning adopts a combination of static partitioning and dynamic mapping, and the SMMU is used to realize the translation of virtual address to physical address.

[0018] Preferably, the allocation strategy for the peripheral devices includes: Connect devices with high real-time requirements directly to the virtual client system of the operating instrumentation system; Connect the interactive devices directly to the virtual client system of the central control system; Computing devices are made available to multiple virtual client systems via a shared driver architecture.

[0019] A vehicle, characterized in that it includes an intelligent cockpit system as described in any of the preceding claims.

[0020] A computer-readable storage medium is characterized in that it stores a computer program thereon, the computer program being executable by a processor to implement the steps of the resource partitioning method described above.

[0021] The intelligent cockpit system and its resource partitioning method based on Type I virtualization technology of this invention achieve a high degree of integration and isolation of hardware resources, reducing system cost and power consumption; through the device pass-through and sharing mechanism, it not only ensures the real-time performance of the instrument system, but also meets the multi-functional needs of the central control system; the system has good scalability and can support more virtual client systems or peripheral devices to access. Attached Figure Description

[0022] Figure 1 This is an overall architecture diagram of the intelligent cockpit system based on Type I virtualization technology of the present invention.

[0023] Figure 2 This is a schematic diagram illustrating direct network communication between the first virtual client system and the second virtual client system of the present invention.

[0024] Figure 3 This is a schematic diagram illustrating communication between the first virtual client system and the second virtual client system using shared memory according to the present invention.

[0025] Figure 4 This is an overall architecture diagram of the present invention from a functional perspective.

[0026] Figure 5 This is a schematic diagram of the exception levels and corresponding software architecture of the ARM architecture of the present invention.

[0027] Figure 6 This is a schematic diagram illustrating the CPU resource allocation method in a specific embodiment of the present invention.

[0028] Figure 7 This is a schematic diagram illustrating the memory resource allocation method in a specific embodiment of the present invention.

[0029] Figure 8 This is a schematic diagram illustrating the storage resource allocation method in a specific embodiment of the present invention. Detailed Implementation

[0030] To more clearly describe the technical content of the present invention, the following description is provided in conjunction with specific embodiments.

[0031] Before describing the embodiments of the present invention in detail, it should be noted that, in the following, the terms “comprising,” “including,” or any other variations are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed or inherent to such process, method, article, or apparatus.

[0032] This intelligent cockpit system, based on Type I virtualization technology, includes: The hardware platform includes at least one processor, memory, storage device, and peripheral devices that support virtualization. Type I virtualization management program runs on the aforementioned hardware platform and directly manages hardware resources; The first virtual client system (i.e., DOM0) runs an embedded Linux system to drive the instrument display screen; The second virtual client system (corresponding to DOM1) runs the Android system and is used to drive the central control display screen; The Type I virtualization management program divides hardware resources into multiple independent partitions and allocates them to the first virtual client system and the second virtual client system respectively.

[0033] In a preferred embodiment of the present invention, the Type I virtualization management program is a Xen-based Hypervisor that runs at the EL2 exception level of the ARMv8 architecture processor.

[0034] In a preferred embodiment of the present invention, the peripheral devices include at least one of a GPU, an audio codec, a WIFI module, a Bluetooth module, and a USB controller, and some devices are assigned to a designated virtual client system for exclusive use via a pass-through method.

[0035] In a preferred embodiment of the present invention, the GPU and audio codec are directly allocated to the first virtual client system, and the second virtual client system shares the GPU and audio codec through a front-end and back-end driver architecture.

[0036] In a preferred embodiment of the present invention, the Type I virtualization management program implements memory virtualization through the system memory management unit, allocating an independent physical memory region for each virtual client system.

[0037] As a preferred embodiment of the present invention, SMMU technology is used on the ARM platform, VT-d technology is used on the Intel platform, and AMD-Vi technology is used on the AMD platform to achieve memory virtualization.

[0038] In a preferred embodiment of the present invention, the processor virtualization is achieved through native virtualization support of ARM architecture, Intel VT-x technology or AMD-V technology, and interrupt virtualization is achieved through GIC or APICv technology.

[0039] In a preferred embodiment of the present invention, the storage device is partitioned by the Type I virtualization management program, and each virtual client system is mounted with an independent storage partition.

[0040] In a preferred embodiment of the present invention, the system further includes: A front-end and back-end driven architecture is used to share device resources between virtual client systems; A shared memory region used for communication and data exchange between virtual client systems.

[0041] In a preferred embodiment of the present invention, the first virtual client system and the second virtual client system communicate with each other through network virtualization; The Type I virtualization management program virtualizes a multi-port switch and assigns a virtual network port to each virtual client system to enable cross-system network communication.

[0042] In a preferred embodiment of the present invention, the first virtual client system and the second virtual client system communicate with each other through a shared memory and event channel mechanism; The shared memory region is managed with access control through an authorization table, and the event channel is used to transmit read and write control signals.

[0043] The method for resource allocation using the system described above includes the following steps: (1) The virtualization management program identifies hardware resources at startup; (2) Divide the CPU core into multiple virtual CPUs according to the preset strategy and schedule them to each virtual client system in a time-sharing manner; (3) Divide the physical memory into multiple independent regions and map them to each virtual client system respectively; (4) Assign peripheral devices to the corresponding virtual client systems in either pass-through or shared mode; (5) Allocate an independent storage partition for each virtual client system.

[0044] In a preferred embodiment of the present invention, the memory partitioning adopts a combination of static partitioning and dynamic mapping, and the conversion from virtual address to physical address is realized through SMMU.

[0045] As a preferred embodiment of the present invention, the peripheral device allocation strategy includes: Connect devices with high real-time requirements directly to the virtual client system of the operating instrumentation system; Connect the interactive devices directly to the virtual client system of the central control system; Computing devices are made available to multiple virtual client systems via a shared driver architecture.

[0046] The vehicle includes the aforementioned intelligent cockpit system.

[0047] The computer-readable storage medium contains a computer program that can be executed by a processor to implement the steps of the resource partitioning method described above.

[0048] The implementation process of this technical solution will be described in detail below: like Figure 1As shown, the black portion at the bottom of the image represents the hardware platform. For example, "Aarch64 machine" indicates that the underlying hardware is an ARMv8 architecture SoC system supporting 64-bit operation. The following examples use the functional modules of Aarch64 machine as a default example. Other hardware platforms can be compared using the same functional modules. For instance, ARM's interrupt virtualization is supported by the GIC module, which corresponds to Intel's interrupt virtualization being supported by APICv technology; ARM's SMMU corresponds to Intel's VT-d, and so on.

[0049] A computer system is mainly composed of several major components, including CPU, MEM, interrupt, GPU, external network, and disk. Different platforms need to consider these aspects when making differentiated approaches to virtualization support.

[0050] For CPU components, the ARM platform inherently supports virtualization, while Intel requires the physical CPU itself to support it and VT-x technology to be enabled in the BIOS in order to use CPU virtualization. Similarly, on the AMD platform, this technology is called AMD-V technology.

[0051] For interrupt systems, the GIC (General Interrupt Controller) on the ARM platform is a standard component in the ARM architecture, responsible for unified handling of system interrupts, including virtual interrupts generated by the virtualization system. For Intel systems, I / O interrupts generated by the virtualization system are handled through APICv technology, essentially a virtualization optimization of APIC (Advanced Programmable Interrupt Controller) technology. At the underlying level, KVM's POSTED_IRQ technology notifies the vCPU to handle the interrupt.

[0052] For memory components, MMU stands for Memory Management Unit, a generic name. Essentially, it's a logical component that translates virtual memory into physical memory, and its implementation varies across platforms. ARM platforms use SMMU technology to support memory virtualization. Intel platforms use VT-d technology, and AMD platforms use AMT-Vi technology.

[0053] The gray area represents a Type I virtualization system, hereinafter referred to as a Hypervisor system. The Hypervisor system is a virtual machine management platform, and together with the underlying hardware, it is called the Host OS. When the Hypervisor system is running, the part below the blue line runs in kernel mode; the part above it runs in user mode.

[0054] The green part DOM0 represents a virtualized Linux client system (Guest OS1).

[0055] The blue part DOM1 represents a virtualized Android client system (Guest OS2).

[0056] The underlying resources, including CPU / MEM / GPU (connected to the AXI bus) and peripheral devices (connected to the APB bus), are all managed by the Hypervisor. Some of these devices are directly connected to DOM0, while others are directly connected to DOM1.

[0057] Devices that are directly connected to DOM0 can provide functionality to the DOM1 PV driver frontend through the PV driver backend.

[0058] The CPU is shared by DOM0 and DOM1 via a time-sharing hypervisor, including interrupt handling using virtualization capabilities provided by the GIC.

[0059] The MEM is physically partitioned, and then the virtual address is mapped to the actual address through the virtualization capability provided by SMMU for use by DOM0 and DOM1. The Hypervisor itself also needs to use a part of it.

[0060] The GPU is directly used by DOM0; DOM1 is shared by the frontend through the PV driver.

[0061] The meaning of "device A is directly connected to system P" is that the read and write operations of device A do not go through the virtualization system, but are directly controlled by the target system P. In other words, device A is exclusively used by system P and is not relayed by the virtualization system or shared by other systems Q.

[0062] WIFI / BT / USB passthrough is available for DOM1.

[0063] The audio codec is directly used by DOM0; DOM1 uses it through the PV driver frontend.

[0064] SSPM (System SusPend to raM) is a direct pass-through to DOM0.

[0065] As a preferred embodiment of the present invention, the communication method between DOM0 and DOM1 is as follows: I. Using direct network communication The Hypervisor virtualizes a multi-port switch and assigns ports to each virtual machine. DOM0 runs a fully virtual network interface card, and its network port is connected to a port on the virtual switch. The current instance assigns the eth0 virtual port to DOM0, with its default IP address configured as 192.168.100.188; and assigns the eth1 virtual port to DOM1, with its default IP address set to 192.168.100.110.

[0066] The upper-layer application is a dual-screen interactive service based on FDBus. The overall communication diagram is as follows: Figure 2 As shown: The communication establishment process is as follows: 1. DOM0 will start the host-server to manage and synchronize information from other nameservers. The host-server will listen on its own port 9096, which is DOM0's 192.168.100.188:9096, waiting for connections and registrations from other nameservers.

[0067] 2. When the nameserver of DOM1 starts and the nameserver of DOM0 starts, they will both make a request to the registered address of the host-server. The host-server will merge all the service information of the peer nameserver into a large table and then send it back. In this way, all service providers know each other. The host-server will also maintain a regular heartbeat with these nameservers.

[0068] 3. DOM0 will start the FdbusServer service to listen on a certain port to provide dual-screen interaction services. When the nameserver of DOM0 starts, it will synchronize this information to the host-server, and after the nameserver of DOM1 comes online, it will synchronize the address and port information of FdbusServer.

[0069] 4. When an application in DOM1 starts up, it requests the dual-screen interaction service from the local nameserver through FdbusClient. The nameserver of DOM1 will return the address and port of the FdbusServer corresponding to the dual-screen interaction stored in its own memory to FdbusClient. This is the service provided by DOM0. FdbusClient will then directly request this service through this address and port and wait for the message reply from the other end.

[0070] 5. After an application in DOM1 sends a request message via FdbusClient, such as displaying the name of the currently playing song to the other end, the FdbusServer in DOM0 will receive this request via the underlying TCP / IP and forward it to a DOM0 application to process the message, such as displaying the name of the currently playing song on the IC screen, and then send a return message through the address and port of the other end.

[0071] 6. An application in DOM1 will receive a reply message and then perform subsequent operations.

[0072] 7. The underlying TCP / IP connection of the entire communication process is completed by DOM1 through its own virtual network port, through the network protocol of its own virtual network card, handing the data to the virtual switching device of the Hypervisor, and then transmitting it to the virtual network card of DOM0 at the other end, and then transmitting it to the corresponding network port of DOM0.

[0073] II. Using shared memory for communication There is a shared memory area between DOM0 and DOM1 and the Hypervisor. This area is configured with permission management pages (Grant Tables) to indicate whether it is shared, and the read and write control flow of the memory page between the two DOMs is configured through the Event Channel.

[0074] The upper layer carries the application that projects from DOM1 to DOM0. The overall block diagram is as follows: Figure 3 As shown: The overall process is as follows: 1. DOM1 and DOM0 establish a command plane connection through the Hypervisor's Event Channel to determine the memory pages that need to be shared and their availability.

[0075] 2. When DOM1 receives the screen mirroring request, it will call the GPU instruction locally to write the drawing data into page0, and notify DOM0's GpuServer that the data is ready to be read through the Event Channel.

[0076] 3. DOM0 obtains the shared memory page through the Event Channel, and the Hypervisor is responsible for transferring read and write permissions for this memory area.

[0077] 4. DOM0's GpuServer reads the data from page0, calls the local GPU driver instructions, draws the actual data onto the screen device connected to DOM0, and sends back a release message through the Event Channel.

[0078] 5. DOM1 may be writing to page1 at this time and passing a message through the Event Channel to indicate whether page1 is available. If it receives a message that page0 has been released, then the next frame can be rendered in page0.

[0079] 6. Throughout the process, the Hypervisor is responsible for the transfer of permissions for memory pages and the transmission mechanism of Event Channel messages; DOM0 is responsible for overlaying the rendering of data in memory with its own rendering, and then calling GpuServer to complete the drawing using actual hardware.

[0080] See system function division Figure 4 In summary: a) The Hypervisor has functions such as physical resource management, inter-system call support, and pass-through control; b) DOM0 is capable of running Linux systems and supports functions such as instrument panel display. It also supports functions such as console / virtual machine management / PV driver runtime framework / Shared memory management. c) The DOM1 is equipped with an Android system, supports central control screen display and other functions, and can directly use USB / WIFI / BT devices.

[0081] As a preferred embodiment of the present invention, the system anomaly level switching and management method is as follows: In the Arm64 architecture, there are four exception levels, from EL3 to EL0, with EL3 being the highest. In this example, Linux and Android run in EL1, the application runs in EL0, and the Hypervisor runs in EL2.

[0082] Address space management, VCPU scheduling and context switching, and device interrupts are all handled by the Hypervisor in EL2.

[0083] For details on the procedures and their correspondence with EL levels, please refer to [link / reference]. Figure 5 .

[0084] As a preferred embodiment of the present invention, the CPU resource allocation method is as follows: Multiple guest OSes run on physical CPUs in a time-sharing manner, each with its own independent physical address space. This allows the hypervisor at the EL2 layer to assist multiple guest OSes in switching contexts.

[0085] For specific CPU partitioning methods, please refer to [link / reference]. Figure 6 .

[0086] As a preferred embodiment of the present invention, the MEM resource allocation method is as follows: The physical memory of multiple guest OSes is separated, which is achieved through hard address partitioning and soft hypervisor management to complete the technical implementation of SMMU.

[0087] For specific MEM partitioning methods, please refer to Figure 7 .

[0088] As a preferred embodiment of the present invention, the EMMC resource allocation method is as follows: The storage resources of multiple Guest OSs are obtained by first mounting their own file partitions through the Hypervisor system, and then controlling the Guest OS system to mount its corresponding partition locations through parameters.

[0089] For specific EMMC partitioning methods, please refer to [link / reference]. Figure 8 .

[0090] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0091] It should be understood that various parts of the present invention can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution device.

[0092] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0093] The storage media mentioned above can be read-only memory, disk, or optical disk, etc.

[0094] In the description of this specification, references to terms such as "an embodiment," "some embodiments," "example," "specific example," or "embodiment," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0095] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

[0096] The intelligent cockpit system and its resource partitioning method based on Type I virtualization technology of this invention achieve a high degree of integration and isolation of hardware resources, reducing system cost and power consumption; through the device pass-through and sharing mechanism, it not only ensures the real-time performance of the instrument system, but also meets the multi-functional needs of the central control system; the system has good scalability and can support more virtual client systems or peripheral devices to access.

[0097] In this specification, the invention has been described with reference to specific embodiments thereof. However, it will be apparent that various modifications and variations can be made without departing from the spirit and scope of the invention. Therefore, the specification and drawings should be considered illustrative rather than restrictive.

Claims

1. An intelligent cockpit system based on Type I virtualization technology, characterized in that, The system includes: The hardware platform includes at least one processor, memory, storage device, and peripheral devices that support virtualization. Type I virtualization management program runs on the aforementioned hardware platform and directly manages hardware resources; The first virtual client system runs an embedded Linux system and is used to drive the instrument display screen; The second virtual client system runs on Android and is used to drive the central control display screen; The Type I virtualization management program divides hardware resources into multiple independent partitions and allocates them to the first virtual client system and the second virtual client system respectively.

2. The intelligent cockpit system based on Type I virtualization technology according to claim 1, characterized in that, The aforementioned Type I virtualization management program is a Xen-based Hypervisor that runs at the EL2 exception level of the ARMv8 architecture processor.

3. The intelligent cockpit system based on Type I virtualization technology according to claim 1, characterized in that, The peripheral devices include at least one of a GPU, an audio codec, a WIFI module, a Bluetooth module, and a USB controller, and some of these devices are assigned to a designated virtual client system for exclusive use via a pass-through method.

4. The intelligent cockpit system based on Type I virtualization technology according to claim 3, characterized in that, The GPU and audio codec are directly allocated to the first virtual client system, and the second virtual client system shares the GPU and audio codec through a front-end and back-end driver architecture.

5. The intelligent cockpit system based on Type I virtualization technology according to claim 1, characterized in that, The Type I virtualization management program implements memory virtualization through the system memory management unit, allocating an independent physical memory region for each virtual guest system.

6. The intelligent cockpit system based on Type I virtualization technology according to claim 5, characterized in that, Memory virtualization is achieved using SMMU technology on the ARM platform, VT-d technology on the Intel platform, and AMD-Vi technology on the AMD platform.

7. The intelligent cockpit system based on Type I virtualization technology according to claim 1, characterized in that, The virtualization of the processor is achieved through native virtualization support of the ARM architecture, Intel VT-x technology, or AMD-V technology, while interrupt virtualization is achieved through GIC or APICv technology.

8. The intelligent cockpit system based on Type I virtualization technology according to claim 1, characterized in that, The storage device is partitioned using the Type I virtualization management program, with each virtual client system mounting an independent storage partition.

9. The intelligent cockpit system based on Type I virtualization technology according to claim 1, characterized in that, The system also includes: A front-end and back-end driven architecture is used to share device resources between virtual client systems; A shared memory region used for communication and data exchange between virtual client systems.

10. The intelligent cockpit system based on Type I virtualization technology according to claim 1, characterized in that, The first virtual client system and the second virtual client system communicate with each other through network virtualization; The Type I virtualization management program virtualizes a multi-port switch and assigns a virtual network port to each virtual client system to enable cross-system network communication.

11. The intelligent cockpit system based on Type I virtualization technology according to claim 9, characterized in that, The first virtual client system and the second virtual client system communicate with each other through a shared memory and event channel mechanism; The shared memory region is managed with access control through an authorization table, and the event channel is used to transmit read and write control signals.

12. A method for resource allocation using the system according to any one of claims 1 to 11, characterized in that, The method includes the following steps: (1) The virtualization management program identifies hardware resources at startup; (2) Divide the CPU core into multiple virtual CPUs according to the preset strategy and schedule them to each virtual client system in a time-sharing manner; (3) Divide the physical memory into multiple independent regions and map them to each virtual client system respectively; (4) Assign peripheral devices to the corresponding virtual client systems in either pass-through or shared mode; (5) Allocate an independent storage partition for each virtual client system.

13. The resource allocation method according to claim 12, characterized in that, The memory partitioning uses a combination of static partitioning and dynamic mapping, and the SMMU is used to translate virtual addresses into physical addresses.

14. The resource allocation method according to claim 13, characterized in that, The allocation strategy for the peripheral devices includes: Connect devices with high real-time requirements directly to the virtual client system of the operating instrumentation system; Connect the interactive devices directly to the virtual client system of the central control system; Computing devices are made available to multiple virtual client systems via a shared driver architecture.

15. A vehicle, characterized in that, The system includes an intelligent cockpit system as described in any one of claims 1 to 11.

16. A computer-readable storage medium, characterized in that, It stores a computer program that can be executed by a processor to implement the steps of the resource partitioning method of claim 14.

Images