Intelligent networked vehicle multi-level virtual machine intercommunication and multi-scenario switching method and system

Abstract

The application discloses a kind of intelligent network connection car multilevel virtual machine intercommunication and multi-scene switching method and system, the method utilizes the way of multilevel virtual machine and distributes different communication resources to realize high real-time communication processing using network connection car communication data characteristics, according to the communication characteristics between different technical maturity of whole vehicle virtual machine, data flow classification and hierarchical design are carried out, then different communication resources and scheduling priority are allocated for the intercommunication between different levels of virtual machine. Through the parallel processing mechanism of physical layer, virtualization layer and application layer, the advantages of multilevel isolated communication are fully utilized, and the overall performance and real-time performance of the intelligent network connection car central centralized domain controller are improved. This hierarchical optimization strategy can effectively allocate and utilize system resources, and differentially process according to the priority and real-time requirement of different data streams, thereby meeting the demand of intelligent network connection car for high performance, high reliability and high safety.

Description

Technical Field

[0001] This invention relates to the field of virtual machine communication technology in embedded systems under virtual environments, and in particular to a method and system for multi-level virtual machine communication and multi-scenario switching in intelligent connected vehicles. Background Technology

[0002] Intelligent connected vehicles integrate cutting-edge technologies such as artificial intelligence, the Internet of Things, and big data analytics, bringing unprecedented safety, efficiency, and comfort to the driving experience. However, as automobiles become increasingly intelligent, the overall vehicle architecture undergoes significant changes. The traditional solution of distributing hundreds of ECUs throughout the vehicle suffers from pain points such as high wiring and harness management costs, and difficulties in software integration and updates.

[0003] To address these issues, centralized domain controller technology, incorporating embedded virtualization, has emerged. Domain controllers can integrate and ensure compatibility with all distributed ECUs, consolidating multiple functions onto one or a few high-performance computing platforms. However, simply upgrading the domain controller hardware platform cannot completely solve the challenges faced by intelligent connected vehicles.

[0004] Real-time performance and reliability: Inter-virtual machine communication in the in-vehicle environment is a crucial link in realizing vehicle control, data acquisition, and information processing, which differs from the well-established server virtualization environment. The response latency of driving operations is directly related to driving safety; excessive latency will lead to slow system response, making it difficult to respond to emergencies in a timely manner and easily causing traffic accidents.

[0005] Communication bandwidth and efficiency: As the autonomous driving function, entertainment function and interconnection with external networks of intelligent connected vehicles increase the demand for communication bandwidth, virtual machines need to transmit a large amount of data, such as sensor data, control commands, multimedia streams, etc.

[0006] Traffic demands vary significantly across different scenarios: Intelligent connected vehicles have vastly different virtual machine communication requirements across different functional domains in various driving scenarios. For example, in high-speed cruising scenarios, autonomous driving functions require frequent environmental perception and path planning, thus placing high demands on the communication resources of the control flow and sensor layer virtual machines; while in parking or low-speed driving scenarios, entertainment functions and vehicle software maintenance and updates will occupy the majority of communication resources.

[0007] Traditional inter-virtual machine communication methods mainly include the following:

[0008] a. Network-based inter-virtual machine communication: Virtual machines communicate with each other through virtual networks, such as bridged mode and NAT mode. This method requires processing through the network protocol stack of the virtualization layer, which introduces additional latency and bandwidth consumption, making it difficult to meet the real-time requirements of intelligent connected vehicles.

[0009] b. Inter-virtual machine communication based on shared memory: Virtual machines exchange data through shared memory regions. While this method is fast, it has security issues. Data isolation between different virtual machines is poor, making them vulnerable to malicious attacks and data leaks.

[0010] c. Communication via APIs provided by the virtualization platform: Virtualization platforms typically provide APIs that allow communication between virtual machines. The efficiency and flexibility of this approach depend on the specific virtualization platform and are difficult to meet the high-performance and customizable requirements of intelligent connected vehicles.

[0011] In summary, traditional inter-virtual machine communication methods cannot meet the needs of intelligent connected vehicles for high real-time performance, high bandwidth efficiency, and flexible resource scheduling and isolation in different scenarios.

[0012] Therefore, an efficient, safe, and reliable method for multi-level virtual machine communication and multi-scenario switching in intelligent connected vehicles is needed. Summary of the Invention

[0013] In view of this, the purpose of the present invention is to provide a method for communication and scene switching between multi-level virtual machines in intelligent connected vehicles. This method utilizes the characteristics of communication data in connected vehicles and uses a multi-level virtual machine approach to allocate different communication resources to achieve high real-time communication processing.

[0014] To achieve the above objectives, the present invention provides the following technical solution:

[0015] The method for multi-level virtual machine communication and multi-scenario switching in intelligent connected vehicles provided by this invention includes the following steps:

[0016] S1: Data flow classification and hierarchical design, used to determine communication units and modes, and to assess, allocate and prioritize resource requirements according to application scenarios;

[0017] S2: Real-time and bandwidth requirement assessment, used to assess the resource requirements of different data streams and determine dynamic resource allocation and priority management decisions during vehicle operation;

[0018] S3: Resource allocation and priority management, used to allocate corresponding communication resources and scheduling priorities to different communication units;

[0019] S4: Virtual network channel isolation implementation, used to create independent virtual network channels for different communication units to achieve isolation between data streams;

[0020] S5: The design of the parallel processing mechanism is used to achieve concurrent execution of data streams through multi-core processors and hardware virtualization technology.

[0021] Furthermore, the data flow classification and hierarchical design includes the following steps:

[0022] S11: Classify the communication data to obtain different types of data streams, including control data, sensor data, entertainment data, and diagnostic and maintenance data;

[0023] S12: Create corresponding communication layers according to different types of data streams; the communication layers include control layer, sensor layer, entertainment layer, and diagnostic and maintenance layer.

[0024] Furthermore, the real-time performance and bandwidth requirement assessment includes the following steps:

[0025] S21: Based on the "queueing theory" and "communication characteristics", the real-time and bandwidth requirements are roughly estimated. The "queueing theory" is used to abstract the communication process between virtual machines on intelligent connected vehicles into a "queueing system". Data streams queue up and wait for service. By analyzing the parameters of the queuing system, the latency and packet loss rate of the data streams are estimated. Based on the "communication characteristics", the approximate bandwidth requirements for different data streams are determined.

[0026] S22: Obtain the experimental measurement results of the prototype vehicle, including real-time communication and bandwidth requirement data;

[0027] S23: Obtain the full vehicle network simulation model to get the specific values ​​of network bandwidth and latency requirements for different data streams.

[0028] Furthermore, the resource allocation and priority management includes the following steps:

[0029] S31: Establish a decision-making framework that adapts to different working modes and coordinates and unifies different scheduling rules; the working modes include driving mode, entertainment mode, and charging mode;

[0030] S32: Design allocation priorities and rules based on the characteristics of data flow network resource requirements in different working modes;

[0031] S33: Design a decision model for basic and dynamic rules based on the real-time performance and bandwidth requirements of data streams, their priority levels, and operating modes;

[0032] S34: Construct a decision model in the whole vehicle network simulation model, monitor the operation status of the simulation network through the decision model, and obtain the network resource allocation optimization model.

[0033] Furthermore, in step S32, priority allocation and rules are designed based on the characteristics of data flow network resource requirements in different working modes; specifically, this is carried out in the following manner:

[0034] (1) Calculate the real-time related loss term according to the following formula:

[0035]

[0036] Among them, L i L represents the actual transmission delay of data stream i. max Priority is the maximum allowed latency of the system. i It is the priority of data stream i;

[0037] (2) Calculate the bandwidth-related loss term according to the following formula:

[0038]

[0039] Among them, B allocated,i B is the bandwidth resource allocated to data stream i. required,i Priority is the bandwidth requirement for data stream i. i It is the priority of data stream i;

[0040] (3) Calculate the bandwidth utilization loss term according to the following formula:

[0041]

[0042] Among them, B total It represents the total bandwidth resources of the vehicle communication system, and α is the system bandwidth robustness factor;

[0043] (4) Calculate the working mode switching smoothness loss term according to the following formula:

[0044]

[0045] in, and These represent the communication resources (bandwidth and VCPU time) of data stream i before and after the handover, respectively, while R... required,i It is the resource requirement of data stream i;

[0046] (5) Calculate the comprehensive loss function according to the following formula:

[0047] Total Loss = λ1·Loss latency +λ2·Loss bandwidth +λ3·Loss utilization +λ4·Loss mode-switch ;

[0048] Where λ1, λ2, λ2 and λ2 are the contribution weights of each loss term to the total loss;

[0049] (6) Determine the priority of network resource allocation based on the comprehensive loss function.

[0050] Furthermore, the isolation of the virtual network channel includes the following steps:

[0051] S41: Configure the virtual network interface for each virtual machine, with each virtual network interface corresponding to a specific data stream;

[0052] S42: Virtual machines at the same network level form a virtual local area network through a virtual switch;

[0053] S43: Configure a virtual router, which is used to connect different virtual switches to achieve network isolation.

[0054] Furthermore, the design of the parallel processing mechanism includes the following steps:

[0055] S51: Construct a physical layer for parallel communication between virtual machines. The physical layer uses a multi-core processor network card to distribute network data packets to different processors for processing.

[0056] S52: Construct a virtualization layer, which virtualizes a multi-core processor into multiple processors and distributes the processing of different data streams to different processors for processing through virtual machines;

[0057] S53: Determine the priority of data stream processing and set up thread scheduling and resource reservation mechanisms according to different priorities.

[0058] The present invention also provides a multi-level virtual machine communication and multi-scenario switching system for intelligent connected vehicles, including a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor implements the above-mentioned method when executing the program.

[0059] The beneficial effects of this invention are as follows:

[0060] This invention provides a method and system for multi-level virtual machine communication and multi-scenario switching in intelligent connected vehicles. This method leverages the characteristics of connected vehicle communication data by employing a multi-level virtual machine approach to allocate different communication resources, achieving high real-time communication processing. After classifying and hierarchically designing data flows based on the communication characteristics of virtual machines at different levels of vehicle maturity, different communication resources and scheduling priorities are allocated to virtual machine communication at different levels. Through a parallel processing mechanism at the physical layer, virtualization layer, and application layer, the advantages of multi-level isolated communication are fully utilized, improving the overall performance and real-time performance of the central domain controller of the intelligent connected vehicle. This hierarchical optimization strategy can effectively allocate and utilize system resources and perform differentiated processing according to the priority and real-time requirements of different data flows, thereby meeting the high performance, high reliability, and high security requirements of intelligent connected vehicles.

[0061] Other advantages, objectives, and features of the invention will be set forth in part in the description which follows, and in part will be apparent to those skilled in the art from the following examination, or may be learned from practice of the invention. The objectives and other advantages of the invention can be realized and obtained through the following description. Attached Figure Description

[0062] To make the objectives, technical solutions, and beneficial effects of this invention clearer, the following drawings are provided for illustration.

[0063] Figure 1 A flowchart illustrating the efficient communication and multi-scenario switching mechanism between multi-level virtual machines in intelligent connected vehicles.

[0064] Figure 2 This diagram illustrates the data flow and hierarchical division of communication between virtual machines in intelligent connected vehicles.

[0065] Figure 3 A framework diagram for analyzing the real-time performance and bandwidth of inter-virtual machine communication in intelligent connected vehicles.

[0066] Figure 4 This diagram illustrates the network resource allocation under different modes of multi-level virtual machine communication in intelligent connected vehicles.

[0067] Figure 5 A flowchart illustrating the decision-making path for multi-level virtual machine communication resource scheduling in intelligent connected vehicles.

[0068] Figure 6 This is a schematic diagram illustrating the decision-making path for multi-level virtual machine communication resource scheduling in intelligent connected vehicles.

[0069] Figure 7 This is a schematic diagram of the parallel communication mechanism between multi-level virtual machines in intelligent connected vehicles. Detailed Implementation

[0070] The present invention will be further described below with reference to the accompanying drawings and specific embodiments, so that those skilled in the art can better understand and implement the present invention. However, the embodiments described are not intended to limit the present invention.

[0071] like Figure 1 As shown, Figure 1 A flowchart for the development of an efficient communication and multi-scenario switching mechanism between multi-level virtual machines in intelligent connected vehicles is provided in this embodiment. The method for communication and multi-scenario switching between multi-level virtual machines in intelligent connected vehicles includes the following steps:

[0072] S1: Data flow hierarchy and working mode division are used to determine communication units and modes, which facilitates subsequent scenario-based resource requirement assessment, allocation and priority management, as well as isolation between different data flows;

[0073] S2: Real-time and bandwidth requirement assessment, used to assess the resource requirements of different data streams, identify them with quantitative requirement values, and provide decision support for dynamic resource allocation and priority management during vehicle operation;

[0074] S3: Resource allocation and priority management, used to optimize resource utilization and ensure real-time performance, allocate corresponding communication resources (such as bandwidth, CPU time, memory) and scheduling priorities to different communication units (i.e., data streams at different levels);

[0075] S4: The implementation of virtual network channel isolation is used to ensure data security and avoid interference. It creates independent virtual network channels for different communication units, realizes the isolation between data streams, improves system stability, and ensures data security to prevent malicious attacks or data leakage.

[0076] S5: The parallel processing mechanism is designed to improve system throughput and reduce latency, making full use of multi-core processors and hardware virtualization technology to improve system throughput, reduce data processing latency, and enhance overall performance;

[0077] like Figure 2 As shown, Figure 2 This diagram illustrates the data flow and hierarchical division of communication between virtual machines in intelligent connected vehicles. The data flow hierarchy and working mode definition include the following steps:

[0078] S11: Classify the communication data to obtain different types of data streams, including control data, sensor data, entertainment data, and diagnostic and maintenance data;

[0079] S12: Create corresponding communication layers according to different types of data streams. The communication layers include a control layer, a sensor layer, an entertainment layer, and a diagnostic and maintenance layer.

[0080] The data flow classification and hierarchical design in this embodiment is carried out according to the following steps:

[0081] Due to the significant differences in real-time requirements, bandwidth requirements, and security isolation requirements between virtual machines within the vehicle:

[0082] (1) Significant differences in real-time requirements: Control command communication has extremely high real-time requirements, and even millisecond-level delays can cause safety accidents; Sensor data has relatively high real-time requirements, but slightly lower than control commands; Entertainment data has relatively low real-time requirements and can tolerate a certain delay; Diagnostic and maintenance data has the lowest real-time requirements.

[0083] (2) Large differences in bandwidth requirements: Sensor data (such as cameras and radar) has high bandwidth requirements, control command bandwidth requirements are low, entertainment data bandwidth requirements are moderate, and diagnostic and maintenance data bandwidth requirements are low and occasional.

[0084] (3) The security isolation requirements vary greatly: the security requirements of control commands and sensor data are extremely high, requiring strong isolation to prevent data tampering and interference; the security requirements of entertainment data are moderate; and the security requirements of diagnostic and maintenance data are relatively low.

[0085] Therefore, to facilitate subsequent differentiated communication resource scheduling and priority management, it is necessary to classify and hierarchically design the data for different needs:

[0086] First, the communication data streams between virtual machines are classified according to the nature of the data, real-time requirements, and security requirements, which facilitates subsequent resource allocation and priority management.

[0087] The first category is control data flow, including core control commands, safety system commands, powertrain system commands, chassis system commands, etc.

[0088] Core control commands: throttle opening, gear shifting, braking pressure, steering angle, etc.

[0089] Safety system commands: airbag deployment, ABS (anti-lock braking system) control, ESP (electronic stability program) control, etc.

[0090] Powertrain commands: engine start / stop, battery management system (BMS) control, motor control, etc.

[0091] Chassis system commands: suspension system control, steering system control, braking system control, etc.

[0092] The second category is sensor data streams, including environmental perception data, vehicle status data, driver status data, passenger status data, etc.

[0093] Environmental perception data includes camera image data, radar point cloud data, lidar point cloud data, ultrasonic sensor data, GPS data, etc.

[0094] Vehicle status data: vehicle speed, acceleration, steering wheel angle, wheel speed, tire pressure, etc.

[0095] Driver status data: driver fatigue monitoring data, driver attention monitoring data, etc.

[0096] Passenger status data: seat occupancy status, seat belt usage status, passenger physiological status (such as heart rate, breathing), etc.

[0097] The third category is entertainment data streams, including locally cached data, online internet data, social media data, real-time news data, etc.

[0098] Local cached data: offline versions of navigation maps, audio and video multimedia files, offline language translation packages, etc.

[0099] Online internet data: online navigation maps, multimedia audio and video streams, web browsing data, etc.

[0100] Social media data: messages from social media platforms, updates from friends' activities, notifications from followed channels, etc.

[0101] Regularly updated information and data: weather information, stock information, news information, etc.

[0102] The fourth category is diagnostic and maintenance data streams, including system operation logs, software update data, remote diagnostic data, vehicle usage data, vehicle fault codes, system operation logs, software updates, etc.

[0103] System operation log: Records system operation status and event information.

[0104] Software update data: Used to update vehicle software and firmware.

[0105] Remote diagnostic data: Used for remotely diagnosing vehicle faults.

[0106] Vehicle usage data: Records vehicle usage information, such as mileage and fuel consumption.

[0107] Vehicle fault codes: Records fault information that occurs in the vehicle.

[0108] Secondly, based on the above data stream classification, an independent communication layer is created for each type of data stream.

[0109] Control Layer: Control data such as driving commands, braking signals, and steering control have extremely high requirements for real-time performance and reliability; any delay or error can lead to serious consequences. For some intelligent connected vehicles with redundant designs, virtual machines in the control layer may reside on different physical hosts, using Time-Sensitive Networking (TSN) technology to complete data stream transmission. Time-Sensitive Networking (TSN) is a set of IEEE 802.1 standards designed to extend existing Ethernet standards to support real-time communication. TSN technology can provide deterministic low-latency and low-jitter communication, suitable for applications with extremely high time sensitivity requirements; even within the same physical host, due to the sensitivity and high security requirements of control layer data streams, communication between virtual machines still does not adopt shared memory methods, but continues to use sufficiently low-latency TSN technology.

[0110] Sensor Layer: Some sensor data, such as data from cameras, radar, and lidar, also require high real-time performance and bandwidth to support Advanced Driver Assistance Systems (ADAS) and autonomous driving functions. While these data have high real-time and bandwidth requirements, their importance and security are slightly lower than control layer data. For some sensor data streams, such as emergency braking information or obstacle recognition data requiring rapid response and real-time control, TSN technology is used for transmission to ensure low latency and high reliability. For other sensor data with relatively lower real-time requirements, such as sensor data used to build high-precision maps or perform driving behavior analysis, traditional Ethernet is used for transmission. Although the virtual machines for some sensor data streams may reside within the same physical host, considering the future expansion of the vehicle's sensing system and the isolation between different sensor data streams, and to avoid potential security risks, communication is still conducted using virtual networks based on Ethernet or TSN, rather than directly using shared memory.

[0111] Entertainment Layer: Entertainment data such as audiobooks, online videos, and AI assistant interactions primarily serve passengers' entertainment needs and have relatively low real-time requirements. Occasional delays or jitters will not directly affect driving safety. To save costs and reduce system complexity, traditional Ethernet is used for the transmission of entertainment layer data streams. However, for loading locally cached data in entertainment scenarios, shared memory is more suitable.

[0112] Diagnostic and Maintenance Layer: System logs, remote diagnostics, software updates, and other diagnostic and maintenance data are primarily used for vehicle maintenance and troubleshooting, with minimal real-time requirements. This data can typically tolerate higher latency; therefore, traditional Ethernet is chosen for transmission to reduce costs and simplify system design. Even though some diagnostic virtual machines reside on the same physical host, Ethernet-based virtual networks are used for communication to ensure the security and integrity of diagnostic data and to avoid potential security risks, rather than shared memory, which could allow malicious virtual machine programs to modify diagnostic data and cause false alarms.

[0113] S12: Based on the activity level of virtual machines in different functional domains, corresponding working modes are defined, including driving mode, entertainment mode, and charging mode;

[0114] First, the core function of intelligent connected vehicles is as a means of transportation, and they are in "driving mode" most of the time. Driving mode also distinguishes different driving scenarios (such as highway driving and city driving, autonomous driving and manual driving, etc.). At this time, it is necessary to ensure that critical tasks (such as control commands) can obtain the necessary resources in a timely manner even when the system load is high, so as to ensure their real-time performance and reliability and improve vehicle driving safety.

[0115] Secondly, intelligent connected vehicles are increasingly becoming entertainment-oriented. In scenarios such as long-distance driving or travel, cars will be parked at intervals, and people will focus on entertainment activities such as watching movies and playing games. At this time, "entertainment mode" should be turned on to allow more computing power and memory resources to be allocated to applications in entertainment scenarios, thereby improving resource utilization and enhancing the satisfaction of the entertainment experience.

[0116] Finally, when a connected car is charging, there is no longer energy anxiety, making the vehicle relatively safe in "charging mode," which is particularly suitable for updating system-level software. Entertainment activities can still be enjoyed inside the car in "charging mode," allowing for less focus on saving power when allocating communication resources.

[0117] Preferably, the switching of operating modes depends primarily on the vehicle's speed. Below 3 km / h, it is in entertainment mode; above this speed, it is in driving mode; and it is in charging mode only when charging at a charging station.

[0118] like Figure 3 As shown, Figure 3 This is a framework diagram for analyzing the real-time performance and bandwidth of inter-virtual machine communication in intelligent connected vehicles; the assessment of real-time performance and bandwidth requirements includes the following steps:

[0119] S21: Based on "queueing theory" and "communication characteristics," a rough estimate of real-time performance and bandwidth requirements is made; details are as follows:

[0120] First, using queuing theory, the communication process between virtual machines in intelligent connected vehicles is abstracted as a "queuing system," where data streams, like "customers," arrive at the "service desk" (processor or network) and queue for service. By analyzing the parameters of the queuing system, such as arrival rate, service rate, and queue length, the latency and packet loss rate of the data stream can be estimated.

[0121] Secondly, based on the "communication characteristics" (including data stream format type, data compression and encoding methods, and driving scenarios), the approximate bandwidth requirements for different data stream communications are determined; specifically, the following technical details are included:

[0122] Video streams are characterized by large data volumes, high bandwidth requirements, and sensitivity to latency. Bandwidth requirements are calculated based on resolution, frame rate, color depth, and compression algorithms. However, the bandwidth of a video stream is typically not constant and fluctuates with changes in scene complexity. This is because video compression algorithms determine the degree of compression based on factors such as the degree of frame variation and the richness of image detail within each frame.

[0123] For audio streams, the data volume is relatively small, the bandwidth requirement is low, and they are sensitive to latency. Bandwidth requirements are calculated based on the sampling rate, bit depth, and compression algorithm. Like video streams, the bandwidth requirement for audio streams is closely related to the data compression and encoding methods. The higher the complexity of the audio environment, the richer the frequencies, dynamic range, and variations in the audio signal become, which increases the redundancy and detail of the audio data.

[0124] Control commands are characterized by small data size and high transmission frequency, making them highly sensitive to latency. Bandwidth requirements are calculated based on the command length and transmission frequency, but since the bandwidth requirements for control commands are typically low, they can generally be disregarded.

[0125] Sensor data is characterized by large data volume, high transmission frequency, and sensitivity to latency. The bandwidth requirement is calculated based on the sensor's data output rate and data format. Compared to control flow data, the bandwidth requirement can be as high as hundreds of Mbps depending on the sensor type (for example, a 16-line LiDAR can output millions of point cloud data per second), and therefore cannot be ignored.

[0126] Different driving scenarios require different bandwidths for different data streams. For example, in autonomous driving scenarios, the bandwidth requirements for sensor data streams generated by cameras and LiDAR are relatively high. Therefore, it is necessary to calculate the bandwidth requirements separately for different driving scenarios.

[0127] S22: Accurately measure real-time performance and bandwidth requirements based on prototype vehicle experiments; details are as follows:

[0128] After building a prototype vehicle or using a dedicated test platform, time synchronization is performed via GPS or PTP to ensure that the timestamps of all measuring devices are consistent, thereby accurately measuring communication delays.

[0129] Next, the VN5600 series hardware tools were connected to the prototype vehicle's automotive Ethernet network, and the CANoe and Wireshark software were installed on the host. After configuring the network measurement parameters, different driving conditions, communication modes between virtual machines, and different network loads could be simulated to test the communication latency and bandwidth requirements of different data streams.

[0130] In this step, the measurement results will include the latency and bandwidth required for different data streams to maintain normal operation in some simple working scenarios, and will also provide model input data such as sensor sampling frequency and data packet size, providing support for verification and precise definition of model parameters in the subsequent whole vehicle network simulation process.

[0131] S23: Vehicle network simulation determines latency and bandwidth requirement distribution; details are as follows:

[0132] Based on the actual architecture of the vehicle network, CANoe is used to build a vehicle network simulation model, which includes building a network topology model that defines the connection relationships between each node and link, building node and link models, building a data flow model that defines the characteristics of data packets, and building scenario models that define different working modes and environmental conditions.

[0133] Next, based on different data streams and communication layers, the measurement channels and data capture interfaces are configured to ensure that the communication data of the target node and the link can be monitored and recorded in real time during the simulation.

[0134] In addition, to ensure that subsequent large-scale simulation experiments are meaningful, small-scale network operation simulation experiments will be carried out first to verify that the model accuracy meets the requirements before large-scale vehicle network simulation will be carried out to obtain specific values ​​of network bandwidth and latency requirements for different data flows.

[0135] like Figure 4 As shown, Figure 4 This diagram illustrates network resource allocation under different modes for multi-level virtual machine communication in intelligent connected vehicles; the resource allocation and priority management includes the following steps:

[0136] S31: Establish a decision-making framework that adapts to different working modes and coordinates and unifies different scheduling rules; the working modes include driving mode, entertainment mode, and charging mode; the control layer and sensor layer of the driving mode adopt TSN technology, while the traffic, entertainment, and diagnostic maintenance layers of the sensor layer with low real-time requirements adopt EtherNet technology; the entertainment layer and diagnostic maintenance layer of the entertainment mode adopt EtherNet technology; the entertainment layer and diagnostic maintenance layer of the charging mode adopt EtherNet technology.

[0137] as follows Figure 5 As shown, Figure 5 This is a flowchart of the decision-making path for multi-level virtual machine communication resources in intelligent connected vehicles. It consists of a data flow communication task queue composed of several data packets. The class and level of the data packets are queried to determine whether the data packet is a pre-planned static resource or a static resource. If the conditions are met, it is determined to be a static resource or a dynamic resource, respectively. If the result of dynamic rule decision or basic rule decision is met, the scheduling decision of dynamic resources is followed. Otherwise, it is returned to the queue and continues to wait.

[0138] Resource allocation is not entirely manually determined. Instead, it combines QoS integration service strategies and VCPU affinity configuration to reserve a portion of static basic communication resources, with the remaining resources allocated for dynamic adjustment. The reserved static communication resources provide low-latency and high-bandwidth priority communication guarantees for high-priority data streams, while also ensuring vehicles can operate normally in complex environments where dynamic scheduling may fail. The rules for controlling dynamic communication resources are divided into preset basic rules and rules that require dynamic adjustment based on operating conditions. Preset rules are placed earlier in the decision path, while dynamic adjustment rules are placed later. Data streams with a priority label of "medium" are included in the preset basic rules for scheduling. Data packets are scheduled sequentially from highest to lowest priority in the data packet queue. Data streams in higher-priority basic rules are given more communication resources than those in dynamic rules that should receive additional resources based on certain technical measures.

[0139] like Figure 6 As shown, Figure 6 This diagram illustrates the decision-making path for multi-level virtual machine communication resource scheduling in intelligent connected vehicles, determining the priorities of the control layer, sensor layer, entertainment layer, and diagnostic and maintenance layer; and implementing static resource allocation or dynamic resource scheduling according to three modes: high, medium, and low.

[0140] S32: Design allocation priorities and rules based on the characteristics of data flow network resource requirements in different working modes; specifically, proceed as follows:

[0141] First, under different operating modes, the real-time performance and bandwidth requirements of different data streams in intelligent connected vehicles vary greatly. Based on the communication characteristics analyzed in step S11 above, preset basic rules for resource allocation and priority management are formulated:

[0142] Because the control layer requires high real-time performance and low latency, it should be allocated the highest priority queue and sufficient bandwidth resources in the TSN network to ensure high real-time and latency-free transmission of control commands.

[0143] The sensor layer requires medium to high real-time performance, high bandwidth, and stable, continuous operation, with QoS priority set to "medium" or "high". "Medium" priority sensor layer data streams are transmitted in traditional Ethernet, while "high" priority sensor layer data streams are transmitted in the TSN network. Depending on the specific application of different data streams, safety-sensitive tasks (such as emergency braking or obstacle recognition) are artificially assigned "high" priority to ensure the normal operation of ADAS functions, while non-critical data streams (such as ultrasonic sensors used in low-speed scenarios) are assigned "medium" priority.

[0144] Preferably, the physical layer is equipped with a network interface card (NIC) that supports SR-IOV, allowing a single physical NIC to be virtualized into multiple virtual functions (VFs), allocating independent VFs for virtual machines in the control and sensor layers. This is equivalent to creating a dedicated, pass-through channel to the physical NIC, reducing resource contention with other virtual machines, thereby improving network performance and reducing latency.

[0145] In this embodiment, different resources are allocated between the physical layer network card and the virtual machine. The virtual machine corresponds to the data stream, and different types of data streams often correspond to different virtual machines. Therefore, by allocating a dedicated independent VF to a certain hierarchical data stream, it is possible to achieve competition with the VFs of other data streams.

[0146] The entertainment layer has low real-time requirements and high bandwidth requirements, but some data streams (such as voice interaction control) have high real-time requirements, so the QoS priority is set to "medium" or "low".

[0147] The diagnostic and maintenance layer has low real-time requirements and occasional bandwidth consumption, so its QoS priority is set to "low". However, some data streams (such as real-time fault detection and warning) have higher real-time requirements, so their priority is set to "medium".

[0148] For data streams from the sensor layer, entertainment layer, and diagnostic / maintenance layer where priority is difficult to determine, priority is determined based on real-time performance and bandwidth requirements, driving scenarios, etc., calculated in step S2 above. Regarding driving scenario factors, for example, high-speed driving scenarios will result in more sensor layer data being marked as "high" priority compared to low-speed driving scenarios.

[0149] Based on the correspondence between priorities and rules, it can be seen that some data streams in the sensor layer may not be allocated to static resources, but rather need to be allocated dynamic resources according to basic rules; while the data streams in the entertainment and diagnostic / maintenance layers allocate communication resources according to preset basic rules or dynamic rules. Furthermore, because intelligent connected vehicles experience "energy-range anxiety" in both driving and entertainment modes, energy management factors such as the distance to nearby charging stations and remaining range need to be considered when allocating communication resources.

[0150] As a preferred option, in order to ensure that the data flow in the basic rules with higher priority is tilted towards obtaining more communication resources compared to the dynamic rules, the priority factor is considered in the training loss function designed in step S33. That is, the loss term suffered by the data flow of the basic rules due to the incomplete supply of demand will be given a larger weight coefficient.

[0151] As a preferred approach, the decision-making logic of basic rules is simpler than that of dynamic rules, and it takes more into account meeting demand rather than balancing the load. Specifically, the supply of communication resources in basic rules depends more on the demand, while the supply of communication resources in dynamic rules depends more on the remaining amount of resources.

[0152] As a preferred option, in order to take into account the impact of the remaining battery energy on the communication bandwidth requirements of non-critical data streams in the sensor layer and all data streams in the entertainment and diagnostic maintenance layers, the communication resource supply is multiplied by a decimal related to the percentage of remaining energy, while keeping other factors constant.

[0153] Preferably, the decimals related to the percentage of remaining energy in the basic rules and dynamic rules are not the same, with the former being larger; specifically, they are equal to the percentage of remaining energy plus 20% and the percentage of remaining energy itself, respectively.

[0154] S33: A decision model for basic and dynamic rules is meticulously designed based on data stream real-time performance, bandwidth requirements, priority levels, and operating modes; specifically, it is carried out in the following manner:

[0155] First, determine the input and output variables of the decision-making model. Input variables specifically include factors such as the real-time nature and bandwidth requirements of the data streams, priority levels, total dynamic resources, remaining resources, network load, driving scenario type, environmental complexity, vehicle energy state, and distance to nearby charging stations. Output variables are the amount of communication resources allocated to each data stream, specifically the amount of VCPU, memory, and bandwidth allocated.

[0156] Secondly, the type of decision model is determined. In this embodiment, both the basic rule and dynamic rule models are defined as MLP network models; the weights are different, but the decision input variables are the same, they are included in the same training process, and they share the same loss function. By setting different loss functions in different working modes, the optimal model weights for resource allocation in each mode will be obtained.

[0157] Finally, a loss function adapted to different working modes is designed; the specific loss terms and the final loss function are shown below:

[0158] (1) Real-time related loss: In order to minimize the transmission latency of data streams, especially high-priority and real-time-critical data streams, this loss term needs to be weighted according to priority, with a larger penalty for latency of high-priority data streams to ensure that high-priority data streams obtain lower latency. If the latency exceeds the allowable range, the loss will increase, and the model will adjust the resource allocation strategy.

[0159] As a preferred option, the expression for the real-time-related loss term is:

[0160]

[0161] Among them, L i L represents the actual transmission delay of data stream i. max Priority is the maximum allowed latency of the system. i It is the priority of data stream i.

[0162] (2) Bandwidth-related loss: In order to ensure that the bandwidth demand of high-priority task data streams is met in a timely manner, and to allocate resources to low-priority data streams when resources are sufficient, it is necessary to set a bandwidth demand-supply ratio loss term to drive the model to tilt bandwidth towards high-priority tasks through priority weighting.

[0163] As a preferred option, the expression for the bandwidth-related loss term is:

[0164]

[0165] Among them, B allocated,i B is the bandwidth resource allocated to data stream i. required,i Priority is the bandwidth requirement for data stream i. i It is the priority of data stream i.

[0166] (3) Bandwidth utilization loss: In order to maximize bandwidth resource utilization and avoid waste, the model is encouraged to be as close as possible to the reasonable upper limit of resource allocation in order to maximize resource utilization. It is necessary to set a bandwidth utilization loss term. At the same time, when the resource allocation is too excessive (exceeding the safe ratio), the value of this loss term will increase, and the model will reduce the possibility of overload by adjusting the resource allocation.

[0167] As a preferred option, the expression for the bandwidth utilization loss term is:

[0168]

[0169] Among them, B total It is the total bandwidth resource of the vehicle communication system, and α is the system bandwidth robustness factor, which ranges from 0.80 to 0.95. The specific value is determined based on factors such as the intelligence level of intelligent connected vehicles to ensure that there is remaining bandwidth resource to cope with emergencies and enhance the safety of real-time sensitive driving systems.

[0170] (4) Working mode switching smoothness loss: In order to ensure that resource allocation is fast and smooth when switching working modes, it is necessary to add a working mode switching smoothness loss item to avoid interruption or performance degradation of important data flow related tasks during the working mode switching process.

[0171] As a preferred option, the expression for the smoothing loss term during working mode switching is:

[0172]

[0173] in, and These represent the communication resources (bandwidth and VCPU time) of data stream i before and after the handover, respectively, while R... required,i This refers to the resource requirements of data stream i.

[0174] Combining the four losses mentioned above, we obtain the comprehensive loss function, which balances the relationship between different objectives:

[0175] Total Loss = λ1·Loss latency +λ2·Loss bandwidth +λ3·Loss utilization +λ4·Loss mode-switch ;

[0176] Wherein, λ1, λ2, λ2 and λ2 are the contribution weights of each loss term to the total loss, which can be adjusted according to the actual system requirements.

[0177] As a preferred approach, for ease of description, the above only defines a total of three priority levels: high, medium, and low. In actual vehicle development, in order to further refine the distinction between the importance of different data streams, it may be necessary to define more priority levels, such as five levels.

[0178] As a preferred approach, when the vehicle is in a transitional state between two modes, the model outputs of both modes are considered simultaneously; specifically, this can be the averaging of the decision results.

[0179] S34: The above decision model is integrated into the vehicle network simulation model, enabling the model to monitor the operating status of the simulation network and make real-time decisions on network resource allocation parameters. The simulation is paused every five minutes, followed by a weight optimization using the loss function. Then, the updated decision model is integrated back into the global simulation model to observe whether various performance indicators (such as data flow task communication) meet the requirements. If not, optimization continues until they do.

[0180] The isolation of the virtual network channel in this embodiment includes the following steps:

[0181] S41: Configure the virtual network interface for each virtual machine, with each virtual network interface corresponding to a specific data stream;

[0182] S42: Virtual machines at the same network level form a virtual local area network through a virtual switch;

[0183] S43: Configure a virtual router, which is used to connect different virtual switches to achieve network isolation.

[0184] The isolation of the virtual network channel in this embodiment is implemented in the following manner:

[0185] To ensure that different types of data streams do not interfere with each other during transmission, each virtual machine is configured with multiple virtual network interfaces (VNICs), each interface corresponds to a specific data stream category, and each layer independently processes its corresponding data stream, thereby achieving initial isolation;

[0186] In the scenario of virtualization of the central domain controller of intelligent connected vehicles, these interfaces can play the role of inter-virtual machine communication through the virtual network framework. Virtual machines in the same network layer form a virtual local area network through virtual switches, and communication within the virtual local area network can be directly realized through the virtual switches.

[0187] Since virtual switches can only forward data within the same virtual LAN, devices capable of routing and forwarding are needed to enable communication between different virtual LANs.

[0188] Preferably, network isolation is achieved by configuring multiple virtual routers and connecting different virtual machines or networks to different virtual routers. Each virtual router has an independent routing table and network configuration, responsible for managing network traffic within the virtual LAN it connects to. Network traffic between different virtual routers needs to be routed to communicate, thus achieving isolation between different data flow categories.

[0189] As a preferred option, most virtualization platforms (such as KVM and Xen) offer virtual router functionality, which can be used to achieve network isolation by configuring virtual router instances.

[0190] As a preferred option, SDN technology is used to implement a more flexible and programmable virtual router isolation mechanism.

[0191] Since virtual routers connect different virtual LANs, firewall rules also need to be configured to finely regulate access control between virtual machines in different virtual LANs.

[0192] Specifically, it prohibits virtual machines in low-priority virtual LANs from accessing virtual machines in high-priority virtual LANs, or only allows access to data on specific ports.

[0193] The above configuration of virtual switches, virtual routers, and firewalls ensures that these virtual machines are not directly connected or share communication resources, thereby achieving complete traffic isolation and preventing interference, and avoiding disorderly occupation of bandwidth resources.

[0194] like Figure 7 As shown, Figure 7This is a schematic diagram of the parallel communication mechanism between multi-level virtual machines in intelligent connected vehicles. Different virtual machines are divided into two parts: one part is used for network interfaces with independent queues, and the other part is used for network interfaces with shared queues. The design of the parallel processing mechanism includes the following steps:

[0195] S51: Construct a physical layer for parallel communication between virtual machines. The physical layer uses a multi-core processor network card to distribute network data packets to different processors for processing.

[0196] S52: Construct a virtualization layer, which virtualizes a multi-core processor into multiple processors and distributes the processing of different data streams to different processors for processing through virtual machines;

[0197] S53: Determine the priority of data stream processing and set up thread scheduling and resource reservation mechanisms according to different priorities;

[0198] The parallel processing mechanism in this embodiment is designed as follows:

[0199] To maximize the advantages of multi-layered isolated communication, it is necessary to design an efficient parallel processing mechanism, including collaboration between the physical layer, virtualization layer, and application layer, to fully leverage the performance of hardware resources.

[0200] (1) Physical Layer: The vehicle domain controller should be equipped with a multi-core processor and a network interface card (NIC) that supports multi-queues and SR-IOV, providing the necessary hardware foundation for parallel processing of the virtualization layer and application layer. A multi-core processor enables true parallel processing (rather than polling), significantly improving system performance. Utilizing the multi-queue support of the NIC, network packets can be distributed to different vCPUs for processing, achieving parallel processing of network data and further improving network throughput and reducing latency.

[0201] (2) Virtualization layer: The Hypervisor virtualizes a multi-core physical CPU into multiple vCPUs. The virtual machine distributes the processing of different data streams to different vCPUs. Through the CPU affinity configuration of the virtualization platform, a specific vCPU can be bound to a specific physical CPU core, ensuring that a CPU core focuses on processing data streams at a specific level, thereby improving processing efficiency.

[0202] (3) Application Layer: In terms of communication mechanisms and queue management, high-priority data streams employ synchronous communication and an independent queue management system to maximize real-time communication. Mechanisms such as priority thread scheduling and resource reservation ensure that they can acquire the necessary resources in a timely manner, avoiding interference from low-priority data streams, thus meeting stringent requirements for real-time performance and reliability. For low-priority data streams, asynchronous communication and a shared queue management system are used to reduce CPU and memory resource consumption, and to maximize system throughput and efficiency without affecting high-priority data streams.

[0203] By combining parallel processing mechanisms at the physical, virtualization, and application layers, the advantages of multi-layered isolated communication can be fully leveraged to improve the overall performance and real-time capabilities of the central domain controller in intelligent connected vehicles. This layered optimization strategy effectively allocates and utilizes system resources and performs differentiated processing based on the priority and real-time requirements of different data streams, thereby meeting the high performance, high reliability, and high security demands of intelligent connected vehicles.

[0204] The above-described embodiments are merely preferred embodiments provided to fully illustrate the present invention, and the scope of protection of the present invention is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on the present invention are all within the scope of protection of the present invention. The scope of protection of the present invention is defined by the claims.

Claims

1. A method for inter-communication and multi-scene switching among multi-level virtual machines of intelligent connected vehicles, characterized in that: Includes the following steps: S1: Data flow classification and hierarchical design, used to determine communication units and modes, and to assess, allocate and prioritize resource requirements according to application scenarios; S2: Real-time and bandwidth requirement assessment, used to assess the resource requirements of different data streams and determine dynamic resource allocation and priority management decisions during vehicle operation; S3: Resource allocation and priority management, used to allocate corresponding communication resources and scheduling priorities to different communication units; S4: Virtual network channel isolation implementation, used to create independent virtual network channels for different communication units to achieve isolation between data streams; S5: The design of the parallel processing mechanism is used to achieve concurrent execution of data streams through multi-core processors and hardware virtualization technology; The resource allocation and priority management includes the following steps: S31: Establish a decision-making framework that adapts to different working modes and coordinates and unifies different scheduling rules; the working modes include driving mode, entertainment mode, and charging mode; S32: Design allocation priorities and rules based on the characteristics of data flow network resource requirements in different working modes; S33: Design a decision model for basic and dynamic rules based on the real-time performance and bandwidth requirements of data streams, their priority levels, and operating modes; S34: Construct a decision model in the whole vehicle network simulation model, monitor the operation status of the simulation network through the decision model, and obtain the network resource allocation optimization model; In step S32, priority allocation and rules are designed based on the characteristics of data flow network resource requirements in different working modes; specifically, this is carried out in the following manner: (1) Calculate the real-time related loss term according to the following formula: ； wherein, is the actual transmission delay of the data stream , is the maximum delay allowed by the system, is the priority of the data stream . (2) Calculate the bandwidth-related loss term according to the following formula: ； wherein is a bandwidth resource allocated to a data flow , is a bandwidth requirement of a data flow , is a priority of a data flow . (3) Calculate the bandwidth utilization loss term according to the following formula: ； in, It is the total bandwidth resource of the vehicle communication system. It is the system bandwidth robustness factor; (4) Calculate the smoothness loss term for working mode switching according to the following formula: ； in, and These are data streams Communication resources before and after the handover, including bandwidth and VCPU time, It is a data stream Resource requirements; (5) Calculate the comprehensive loss function according to the following formula: ； in, It represents the contribution weight of each loss item to the total loss; (6) Determine the priority of network resource allocation based on the comprehensive loss function.

2. The method for multi-level virtual machine communication and multi-scenario switching in intelligent connected vehicles as described in claim 1, characterized in that: The data flow classification and hierarchical design includes the following steps: S11: Classify the communication data to obtain different types of data streams, including control data, sensor data, entertainment data, and diagnostic and maintenance data; S12: Create corresponding communication layers according to different types of data streams; the communication layers include control layer, sensor layer, entertainment layer, and diagnostic and maintenance layer.

3. The method for multi-level virtual machine communication and multi-scenario switching in intelligent connected vehicles as described in claim 1, characterized in that: The real-time performance and bandwidth requirement assessment includes the following steps: S21: Based on the "queueing theory" and "communication characteristics", the real-time performance and bandwidth requirements are roughly estimated. The "queueing theory" is used to abstract the communication process between virtual machines on intelligent connected vehicles into a "queueing system". Data streams queue up and wait for service. By analyzing the parameters of the queuing system, the latency and packet loss rate of the data streams are estimated. The bandwidth requirements of different data streams are determined based on the "communication characteristics". S22: Obtain the experimental measurement results of the prototype vehicle, including real-time communication and bandwidth requirement data; S23: Obtain the full vehicle network simulation model to get the specific values ​​of network bandwidth and latency requirements for different data streams.

4. The method for multi-level virtual machine communication and multi-scenario switching in intelligent connected vehicles as described in claim 1, characterized in that: The isolation of the virtual network channel includes the following steps: S41: Configure the virtual network interface for each virtual machine, with each virtual network interface corresponding to a specific data stream; S42: Virtual machines at the same network level form a virtual local area network through a virtual switch; S43: Configure a virtual router, which is used to connect different virtual switches to achieve network isolation.

5. The method for multi-level virtual machine communication and multi-scenario switching in intelligent connected vehicles as described in claim 1, characterized in that: The design of the parallel processing mechanism includes the following steps: S51: Construct a physical layer for parallel communication between virtual machines. The physical layer uses a multi-core processor network card to distribute network data packets to different processors for processing. S52: Construct a virtualization layer, which virtualizes a multi-core processor into multiple processors and distributes the processing of different data streams to different processors for processing through virtual machines; S53: Determine the priority of data stream processing and set up thread scheduling and resource reservation mechanisms according to different priorities.

6. A multi-level virtual machine communication and multi-scenario switching system for intelligent connected vehicles, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method described in any one of claims 1 to 5.

Images