Virtual machine switching method and device for vehicle-mounted multi-screen architecture, equipment and medium
By employing Surface rendering channels and Socket channels in conjunction with kernel virtualization and SELinux in the in-vehicle intelligent system, dynamic switching of virtual machines in the in-vehicle multi-screen architecture was achieved, solving the problems of high latency and unsmooth input, and improving resource utilization and data security.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-05
- Publication Date
- 2026-03-13
AI Technical Summary
Existing technologies struggle to balance low-latency experience for front-seat passengers with stability under resource constraints in in-vehicle intelligent systems, especially with issues of high latency and choppy input interaction during virtual machine switching.
By combining Surface rendering channels and Socket channels with kernel virtualization and SELinux, dynamic switching between front-row and rear-row virtual machines is achieved. By monitoring system resources and vehicle driving conditions, the screen output path is dynamically adjusted to ensure the continuity of input events and data security.
It reduces application rendering latency, improves system resource utilization, ensures input continuity and data security during virtual machine switching, and adapts to different bandwidth environments.
Smart Images
Figure CN121658149A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of in-vehicle multi-screen data processing technology, and in particular to a virtual machine switching method, apparatus, device and medium for in-vehicle multi-screen architecture. Background Technology
[0002] With the development of in-vehicle intelligent systems, virtualization and containerization technologies are widely used in vehicle platforms to improve system security and resource isolation.
[0003] Existing technical solutions include: single-run, where the virtual machine runs on the Android system being used (front-end system or back-end TV system), which can cause lag or even virtual machine crashes when resources are insufficient; and remote-run, which runs on a cloud server and is connected via IP for rendering. Although multiple virtual machines can be switched, there are problems such as large latency and unsmooth input interaction.
[0004] Therefore, the aforementioned existing technologies cannot simultaneously achieve both a low-latency experience for front-end users and stability under resource constraints. Summary of the Invention
[0005] Aimed at at least in solving one of the technical problems existing in the prior art, the present invention provides a virtual machine switching method, device, equipment and medium for in-vehicle multi-screen architecture, which reduces the latency of application screen rendering and improves the utilization of system resources.
[0006] One aspect of the present invention provides a virtual machine switching method for an in-vehicle multi-screen architecture, comprising:
[0007] Based on the application's screen rendering request event, the screen is output to the front-end system for display via the Surface rendering channel through the front-end virtual machine;
[0008] Monitor the usage of front-row system resources. If the front-row system resources are lower than the preset value, dynamically switch virtual machines according to the vehicle driving situation.
[0009] When the rear virtual machine is switched on, it outputs the screen to the front display screen through the Socket channel of the rear virtual machine.
[0010] According to the virtual machine switching method of the in-vehicle multi-screen architecture, the method further includes:
[0011] The front-row virtual machines and the back-row virtual machines use kernel virtualization and SELinux methods to load shared disks and handle security policies.
[0012] According to the virtual machine switching method of the in-vehicle multi-screen architecture, the system resource usage of the front row is monitored. If the system resources are lower than a preset value, dynamic switching of virtual machines is performed based on the vehicle driving situation, including:
[0013] The system resources of the front-end system are monitored, including the utilization of CPU, memory, and GPU.
[0014] If the system resource status does not meet the preset values required for screen display, obtain the vehicle driving status;
[0015] If the vehicle's driving conditions do not meet the requirements for switching virtual machines, virtual machine switching will be prohibited; otherwise, a prompt will appear through the interactive interface indicating that switching is allowed.
[0016] According to the virtual machine switching method of the in-vehicle multi-screen architecture, the virtual machine switching conditions include:
[0017] Virtual machine switching is prohibited if any of the following conditions are met: the gear is higher than the preset gear, the vehicle speed is higher than the preset speed, or the driver is controlling the vehicle. Virtual machine switching is allowed if the following conditions are met simultaneously: the gear is lower than the preset gear, the vehicle speed is lower than the preset speed, and the passenger is controlling the vehicle.
[0018] According to the virtual machine switching method of the in-vehicle multi-screen architecture, when the rear virtual machine starts up via switching, it outputs the screen to the front display screen through the Socket channel of the rear virtual machine, including:
[0019] When the back-end virtual machine is switched on, the back-end system establishes a connection with the front-end system through the local IP's socket channel;
[0020] The rendered image is sent to the front-end system for display via a Socket channel through the back-end virtual machine.
[0021] According to the virtual machine switching method of the in-vehicle multi-screen architecture, the method further includes:
[0022] During virtual machine switching, capture user input events, including screen touch, voice, and gestures.
[0023] The application's running location is used to dynamically route the input events, where the application's running location includes either a front-end virtual machine or a back-end virtual machine.
[0024] According to the virtual machine switching method of the in-vehicle multi-screen architecture, the method further includes:
[0025] The communication bandwidth of the in-vehicle multi-screen architecture is tested, and the resolution and encoding method of the rendering screen of the rear virtual machine are dynamically adjusted based on the test results.
[0026] Another aspect of the present invention provides a virtual machine switching device for an in-vehicle multi-screen architecture, comprising:
[0027] The first module is used to output the screen to the front-end system for display through the Surface rendering channel of the front-end virtual machine based on the application screen rendering request event.
[0028] The second module is used to monitor the usage of front system resources. If the front system resources are lower than the preset value, the virtual machine will be dynamically switched according to the vehicle driving situation.
[0029] The third module is used to output the screen to the front display screen through the Socket channel of the rear virtual machine when the rear virtual machine is switched on.
[0030] Another aspect of the present invention provides an electronic device, including a processor and a memory;
[0031] The memory is used to store programs;
[0032] The processor executes the program to implement the method as described above.
[0033] This invention also discloses a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device can read the computer instructions from the computer-readable storage medium and execute the computer instructions, causing the computer device to perform the methods described above.
[0034] The beneficial effects of this invention are as follows: When the front-end system is running, the application window is directly bound to the Surface rendering channel, avoiding the latency of traditional Socket rendering and achieving a latency-free direct connection; through the differential mounting mechanism, no task migration is required when the back-end takes over, reducing switching time and front-end computing power consumption; the back-end rendering results are returned via the Socket channel, and the encoding method and resolution can be dynamically adjusted to adapt to different bandwidth environments, achieving adaptive return and improving resource utilization; the unified input forwarding mechanism ensures that user operations are not lost during the switching process and that virtual machine switching does not affect or interrupt input; combined with SELinux and container isolation, secure access to shared data is ensured during the switching process, achieving data security. Attached Figure Description
[0035] Figure 1 This is a schematic diagram of the virtual machine switching process of the in-vehicle multi-screen architecture according to an embodiment of the present invention.
[0036] Figure 2This is a schematic diagram of front and rear virtual machine switching and shared storage based on an in-vehicle multi-screen architecture according to an embodiment of the present invention.
[0037] Figure 3 This is a schematic diagram of the dynamic switching process of virtual machines according to an embodiment of the present invention.
[0038] Figure 4 This is a schematic diagram of the virtual machine display switching process according to an embodiment of the present invention.
[0039] Figure 5 This is a schematic diagram of a virtual machine switching device for an in-vehicle multi-screen architecture according to an embodiment of the present invention. Detailed Implementation
[0040] The embodiments of the present invention are described in detail below, examples of which are shown in the accompanying drawings. Throughout the description, the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions. In the following description, suffixes such as "module," "part," or "unit" used to denote elements are used only for the purpose of illustrative purposes and have no specific meaning in themselves. Therefore, "module," "part," or "unit" can be used interchangeably. Terms such as "first," "second," etc., are used only to distinguish technical features and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or implicitly indicating the sequential relationship of the indicated technical features. In the following description, the consecutive reference numerals for method steps are for ease of review and understanding. Adjusting the implementation order of steps, in conjunction with the overall technical solution of the present invention and the logical relationship between the various steps, will not affect the technical effect achieved by the technical solution of the present invention. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.
[0041] refer to Figure 1 and Figure 2 , Figure 1 This is a schematic diagram illustrating the virtual machine switching process in an in-vehicle multi-screen architecture. Figure 2 This is a schematic diagram illustrating the switching and shared storage of virtual machines between the front and rear rows based on an in-vehicle multi-screen architecture. Figure 1 Including but not limited to steps S100~S300:
[0042] S100, based on the application screen rendering request event, outputs the screen to the front-end system for display through the Surface rendering channel of the front-end virtual machine.
[0043] In some embodiments, the front-end virtual machines and the back-end virtual machines employ kernel virtualization and SELinux methods for loading shared disks and handling security policies.
[0044] Combination Figure 2The virtual machines in the back row are also mounted to the same shared disk space through the LXC (kernel virtualization) mount module. This space is controlled by the SELinux+LXC security policy to ensure that only application-related data is mounted, avoiding unauthorized access.
[0045] S200 monitors the usage of front-row system resources. If the front-row system resources are lower than the preset value, it dynamically switches virtual machines according to the vehicle's driving conditions.
[0046] In some embodiments, reference Figure 3 The diagram shown illustrates the dynamic switching process for virtual machines, including but not limited to steps S210-S230:
[0047] S210 detects the system resources of the front-end system, including the utilization of CPU, memory, and GPU.
[0048] S220: If the system resource status does not meet the preset values required for screen display, obtain the vehicle driving status.
[0049] S230: If the vehicle driving conditions do not meet the conditions for switching virtual machines, virtual machine switching is prohibited; otherwise, the user interface will prompt that switching is allowed.
[0050] In some embodiments, virtual machine switching is prohibited if any of the following conditions are met: the gear is higher than a preset gear, the vehicle speed is higher than a preset speed, or the driver is controlling the vehicle; virtual machine switching is allowed if the gear is lower than a preset gear, the vehicle speed is lower than a preset speed, and the passenger is controlling the vehicle.
[0051] In some embodiments, the default gear is P gear.
[0052] When the S300 rear virtual machine is switched on, it outputs the screen to the front display screen through the Socket channel of the rear virtual machine.
[0053] In some embodiments, reference Figure 4 The virtual machine display switching process diagram shown includes, but is not limited to, steps S310~S320:
[0054] When the S310 virtual machine is switched to start, the back-end system establishes a connection with the front-end system through the local IP socket channel;
[0055] The S320 sends the rendered image to the front system for display via a Socket channel through the rear virtual machine.
[0056] In some embodiments, during virtual machine switching, user input events are captured, including screen touch, voice, and gestures; the application's running location is used to dynamically route the input events, where the application's running location includes either a front-end virtual machine or a back-end virtual machine.
[0057] Specifically, refer to Figure 2 During the switching process, the front row continues to capture user input events (touch, voice, gestures). Input events are dynamically routed through the input event forwarding module based on the current application running location (front row or back row virtual machine). That is, when the application is running in the back row virtual machine, the events captured by the front row are forwarded to the back row for processing through the Socket channel, ensuring that the interaction is not interrupted. Therefore, there is no need to migrate data during the switching process, ensuring the continuity of application operation.
[0058] In some embodiments, the method further includes detecting the communication bandwidth of the in-vehicle multi-screen architecture and dynamically adjusting the resolution and encoding method of the rendering screen of the rear virtual machine based on the detection results.
[0059] Experiments were conducted on a vehicle-mounted prototype system using the above embodiments:
[0060] In front-row direct connection mode, the operation and display latency is less than 5ms;
[0061] Rear seat takeover mode, switching latency 1.8s, input latency less than 50ms, adaptive image quality adjustment;
[0062] Resource usage test: After switching, the CPU usage of the front row decreased by 45%;
[0063] Security testing showed that unauthorized virtual machines could not access shared storage, demonstrating effective data isolation.
[0064] Experimental results show that the embodiments of the present invention are feasible and significantly outperform existing solutions in terms of low latency experience and resource optimization.
[0065] Figure 5 This is a schematic diagram of a virtual machine switching device for an in-vehicle multi-screen architecture according to an embodiment of the present invention. The device includes a first module 510, a second module 520, and a third module 530.
[0066] The first module is used to output the screen to the front system for display through the Surface rendering channel of the front virtual machine according to the application screen rendering request event; the second module is used to monitor the resource usage of the front system, and if the resources of the front system are lower than the preset value, the virtual machine is dynamically switched according to the vehicle driving situation; the third module is used to output the screen to the front display screen through the Socket channel of the rear virtual machine when the rear virtual machine is switched and started.
[0067] For example, with the cooperation of the first, second, and third modules in the device, the embodiment device can implement any of the aforementioned virtual machine switching methods for in-vehicle multi-screen architecture. That is, according to the application screen rendering request event, the screen is output to the front system for display through the Surface rendering channel of the front virtual machine; the resource usage of the front system is monitored, and if the resources of the front system are lower than a preset value, the virtual machine is dynamically switched according to the vehicle driving situation; when the rear virtual machine is started by switching, the screen is output to the front display screen through the Socket channel of the rear virtual machine. The beneficial effects of this invention are as follows: When the front-end system is running, the application window is directly bound to the Surface rendering channel, avoiding the latency of traditional Socket rendering and achieving a latency-free direct connection; through the differential mounting mechanism, no task migration is required when the back-end takes over, reducing switching time and front-end computing power consumption; the back-end rendering results are returned via the Socket channel, and the encoding method and resolution can be dynamically adjusted to adapt to different bandwidth environments, achieving adaptive return and improving resource utilization; the unified input forwarding mechanism ensures that user operations are not lost during the switching process and that virtual machine switching does not affect or interrupt input; combined with SELinux and container isolation, secure access to shared data is ensured during the switching process, achieving data security.
[0068] This invention also provides an electronic device, which includes a processor and a memory;
[0069] The memory stores the program;
[0070] The processor executes a program to perform the aforementioned virtual machine switching method for an in-vehicle multi-screen architecture; the electronic device has the function of carrying and running a software system for virtual machine switching of an in-vehicle multi-screen architecture provided in the embodiments of the present invention, such as a personal computer, minicomputer, mainframe, workstation, network or distributed computing environment, standalone or integrated computer platform, or communicating with charged particle tools or other imaging devices, etc.
[0071] This invention also provides a computer-readable storage medium storing a program that is executed by a processor to implement the virtual machine switching method for the in-vehicle multi-screen architecture described above.
[0072] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this invention are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented in the embodiments of this invention. Alternative embodiments are contemplated, in which the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.
[0073] This invention also discloses a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device can read the computer instructions from the computer-readable storage medium and execute the computer instructions, causing the computer device to perform the aforementioned virtual machine switching method for an in-vehicle multi-screen architecture.
[0074] Furthermore, although the invention has been described in the context of functional modules, it should be understood that, unless otherwise stated, one or more of the described functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding the invention. Rather, considering the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed in the embodiments of the invention, the actual implementation of the module will be understood within the scope of conventional skill of an engineer. Therefore, those skilled in the art can implement the invention as set forth in the claims using ordinary techniques without excessive experimentation. It is also understood that the specific concepts disclosed are merely illustrative and are not intended to limit the scope of the invention, which is determined by the full scope of the appended claims and their equivalents.
[0075] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0076] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can include, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device.
[0077] More specific examples of computer-readable media (a non-exhaustive list) include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which the program can be printed, because the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.
[0078] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.
[0079] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," 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, the 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.
[0080] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.
[0081] The above is a detailed description of the preferred embodiments of the present invention, but the present invention is not limited to the embodiments described. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention, and these equivalent modifications or substitutions are all included within the scope defined by the claims of this application.
Claims
1. A virtual machine switching method for an in-vehicle multi-screen architecture, characterized in that, include: Based on the application's screen rendering request event, the screen is output to the front-end system for display via the Surface rendering channel through the front-end virtual machine; Monitor the usage of front-row system resources. If the front-row system resources are lower than the preset value, dynamically switch virtual machines according to the vehicle driving situation. When the rear virtual machine is switched on, it outputs the screen to the front display screen through the Socket channel of the rear virtual machine.
2. The virtual machine switching method for in-vehicle multi-screen architecture according to claim 1, characterized in that, The method further includes: The front-row virtual machines and the back-row virtual machines use kernel virtualization and SELinux methods to load shared disks and handle security policies.
3. The virtual machine switching method for in-vehicle multi-screen architecture according to claim 1, characterized in that, The monitoring of front-row system resource usage, if system resources are lower than a preset value, dynamically switches virtual machines based on vehicle driving conditions, including: The system resources of the front-end system are monitored, including the utilization of CPU, memory, and GPU. If the system resource status does not meet the preset values required for screen display, obtain the vehicle driving status; If the vehicle's driving conditions do not meet the requirements for switching virtual machines, virtual machine switching will be prohibited; otherwise, a prompt will appear through the interactive interface indicating that switching is allowed.
4. The virtual machine switching method for in-vehicle multi-screen architecture according to claim 3, characterized in that, The virtual machine switching conditions include: Virtual machine switching is prohibited if any of the following conditions are met: the gear is higher than the preset gear, the vehicle speed is higher than the preset speed, or the driver is controlling the vehicle. Virtual machine switching is allowed if the following conditions are met simultaneously: the gear is lower than the preset gear, the vehicle speed is lower than the preset speed, and the passenger is controlling the vehicle.
5. The virtual machine switching method for in-vehicle multi-screen architecture according to claim 1, characterized in that, When the rear virtual machine starts via a switch, it outputs the image to the front display screen through the Socket channel of the rear virtual machine, including: When the back-end virtual machine is switched on, the back-end system establishes a connection with the front-end system through the local IP's socket channel; The rendered image is sent to the front-end system for display via a Socket channel through the back-end virtual machine.
6. The virtual machine switching method for an in-vehicle multi-screen architecture according to claim 5, characterized in that, The method further includes: During virtual machine switching, capture user input events, including screen touch, voice, and gestures. The application's running location is used to dynamically route the input events, where the application's running location includes either a front-end virtual machine or a back-end virtual machine.
7. The virtual machine switching method for an in-vehicle multi-screen architecture according to claim 5, characterized in that, The method further includes: The communication bandwidth of the in-vehicle multi-screen architecture is tested, and the resolution and encoding method of the rendering screen of the rear virtual machine are dynamically adjusted based on the test results.
8. A virtual machine switching device for an in-vehicle multi-screen architecture, characterized in that, include: The first module is used to output the screen to the front-end system for display through the Surface rendering channel of the front-end virtual machine based on the application screen rendering request event. The second module is used to monitor the usage of front system resources. If the front system resources are lower than the preset value, the virtual machine will be dynamically switched according to the vehicle driving situation. The third module is used to output the screen to the front display screen through the Socket channel of the rear virtual machine when the rear virtual machine is switched on.
9. An electronic device, characterized in that, Including the processor and memory; The memory is used to store programs; The processor executes the program to implement the virtual machine switching method for the in-vehicle multi-screen architecture as described in any one of claims 1-7.
10. A computer-readable storage medium, characterized in that, The storage medium stores a program, which is executed by a processor to implement the virtual machine switching method for the in-vehicle multi-screen architecture as described in any one of claims 1-7.