Method and system for communication and multi-scene switching between multi-level virtual machines of intelligent networked automobile

Abstract

The invention discloses a method and a system for communication and multi-scene switching between multi-level virtual machines of an intelligent connected automobile, and the method employs a multi-level virtual machine mode to distribute different communication resources through employing the communication data characteristics of the connected automobile, thereby achieving the high real-time communication processing. After data flow classification and hierarchical design are carried out according to communication characteristics among virtual machines of a whole vehicle with different technical maturity, different communication resources and scheduling priorities are distributed to communication among the virtual machines with different levels. Through a parallel processing mechanism of a physical layer, a virtualization layer and an application layer, the advantages of multi-level isolation communication are fully played, and the overall performance and the real-time performance of the intelligent networked automobile centralized domain controller are improved. According to the hierarchical optimization strategy, system resources can be effectively distributed and utilized, and differentiation processing is carried out according to the priority and real-time requirements of different data streams, so that the requirements of the intelligent networked automobile for high performance, high reliability and high safety are met.

Description

Technical Field

[0001] The present invention relates to the technical field of communication between virtual machines of embedded systems under virtual environments, and in particular to a method and system for multi-level communication between virtual machines and multi-scenario switching of intelligent networked vehicles. Background Art

[0002] Intelligent connected cars integrate cutting-edge technologies such as artificial intelligence, the Internet of Things, and big data analysis, bringing unprecedented safety, efficiency, and comfort to the driving experience. However, as cars move toward intelligence, the overall vehicle architecture has undergone tremendous changes. The traditional solution of hundreds of ECUs scattered throughout the car has pain points such as high wiring and harness management costs, and difficulty in software integration and updating.

[0003] In order to solve these problems, the centralized domain controller technology combined with embedded virtualization technology came into being. The domain controller can complete the integration and compatibility of all decentralized ECUs, integrating multiple functions into 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 and reliability: Communication between virtual machines in the vehicle environment is a key link in achieving vehicle control, data collection and information processing, which is different from the server virtualization environment that has been studied and matured. The response delay of driving operations is directly related to driving safety. Too high a delay will cause the system to respond slowly and fail to respond to emergencies in time, which can easily lead to traffic accidents.

[0005] Communication bandwidth and efficiency: As the autonomous driving function, entertainment function and interconnection with external networks of intelligent connected vehicles place increasingly higher demands on communication bandwidth, a large amount of data needs to be transmitted between virtual machines, such as sensor data, control instructions, multimedia streams, etc.

[0006] Traffic volume varies greatly in different scenarios: Intelligent connected vehicles have different communication requirements for virtual machines in different functional domains in different driving scenarios. For example, in high-speed cruising scenarios, the autonomous driving function requires frequent environmental perception and path planning, so the communication resources of the control flow and sensor layer virtual machines are relatively high; while in parking or low-speed driving scenarios, entertainment functions and vehicle software maintenance and updates will occupy the main communication resources.

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

[0008] a. Network-based inter-VM communication: VMs communicate with each other through virtual networks, such as bridge mode, NAT mode, etc. This method requires processing by the network protocol stack of the virtualization layer, which will introduce additional delays and bandwidth consumption, and it is difficult to meet the real-time requirements of intelligent connected vehicles.

[0009] b. Inter - virtual machine communication based on shared memory: Data is exchanged between virtual machines through a shared memory area. Although this method is relatively fast, there are security issues. The data isolation between different virtual machines is poor, making them vulnerable to malicious attacks and data leakage.

[0010] c. Communication based on APIs provided by the virtualization platform: The virtualization platform usually provides some APIs to allow communication between virtual machines. The efficiency and flexibility of this method depend on the specific virtualization platform and it is difficult to meet the requirements of high performance and customization in intelligent connected vehicles.

[0011] In summary, the traditional inter - virtual machine communication methods cannot meet the requirements 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, secure, and reliable multi - level inter - virtual machine communication and multi - scenario switching method for intelligent connected vehicles is needed. Summary of the Invention

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

[0014] To achieve the above - mentioned purpose, the present invention provides the following technical solutions:

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

[0016] S1: Data flow classification and hierarchical design, used to determine communication units and modes, and conduct resource requirement assessment, allocation, and priority management according to application scenarios;

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

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

[0019] S4: Isolation implementation of virtual network channels, used to create independent virtual network channels for different communication units to achieve isolation between data flows;

[0020] S5: Design of parallel processing mechanism, used to achieve the concurrent execution process of data flows through multi - core processors and hardware virtualization technology.

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

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

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

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

[0025] S21: Roughly estimate the real-time and bandwidth requirements according to "queuing theory" and "communication characteristics". Use "queuing theory" to abstract the communication process between virtual machines on an intelligent connected vehicle into a "queuing system", where data flows queue up waiting for service. By analyzing the parameters of the queuing system, estimate the delay and packet loss rate of the data flow; determine the approximate bandwidth requirements for different data flow communications according to "communication characteristics";

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

[0027] S23: Obtain the vehicle network simulation model to obtain specific values of the network bandwidth and delay requirements for different data flows.

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

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

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

[0031] S33: Design a decision model for basic rules and dynamic rules according to the real-time and bandwidth requirements of the data flow, the priority level, and the working mode;

[0032] S34: Build a decision model in the vehicle network simulation model, and monitor the running state of the simulation network through the decision model to obtain an optimized model for network resource allocation.

[0033] Furthermore, in step S32, design the allocation priorities and rules according to the characteristics of the data flow network resource requirements in different working modes; specifically, proceed as follows:

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

[0035]

[0036] Among them, L i is the actual transmission delay of data stream i, and L max is the maximum delay allowed by the system, and Priority i 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 is the bandwidth resource allocated to data stream i, and B required,i is the bandwidth requirement of data stream i, and Priority i 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 is the total bandwidth resource of the vehicle communication system, and α is the system bandwidth robustness factor;

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

[0044]

[0045] Among them, and are the communication resources (bandwidth and VCPU time) of data stream i before and after the switch respectively, and R required,i 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] Among them, λ1, λ2, λ2 and λ2 are the contribution weights of each loss term to the total loss;

[0049] (6) Determine the network resource allocation priority according to the comprehensive loss function.

[0050] Furthermore, the implementation of isolation for the virtual network channels includes the following steps:

[0051] S41: Set the virtual network interfaces of each virtual machine, and each virtual network interface corresponds to a corresponding data stream;

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

[0053] S43: Set a virtual router, and the virtual router is used to connect different virtual switches to implement the network isolation function.

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

[0055] S51: Build the 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: Build a virtualization layer. The virtualization layer virtualizes the multi-core processor into multiple processors, and through virtual machines, the processing of different data streams is allocated to different processors for processing;

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

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

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

[0060] The intelligent connected vehicle multi-level virtual machine communication and multi-scenario switching method and system provided by the present invention utilize the characteristics of connected vehicle communication data to allocate different communication resources in the form of multi-level virtual machines to achieve high-real-time communication processing. After classifying data streams and hierarchical design according to the characteristics of virtual machine communication between complete vehicles with different levels of technological maturity, different communication resources and scheduling priorities are then allocated to the communication between virtual machines at different levels. Through the parallel processing mechanism of the physical layer, virtualization layer, and application layer, the advantages of multi-level isolation communication are fully utilized to improve the overall performance and real-time performance of the central centralized domain controller of intelligent connected vehicles. This hierarchical optimization strategy can effectively allocate and utilize system resources, and perform differential processing according to the priorities and real-time requirements of different data streams, thereby meeting the requirements of intelligent connected vehicles for high performance, high reliability, and high security.

[0061] Other advantages, objects, and features of the present invention will be set forth in part in the following description, and in part will be obvious to those skilled in the art upon examination of the following, or may be learned by practice of the present invention. The objects and other advantages of the present invention may be realized and obtained by the following description of the specification. Brief Description of the Drawings

[0062] In order to make the objectives, technical solutions, and beneficial effects of the present invention clearer, the present invention provides the following drawings for illustration.

[0063] Figure 1 It is a flowchart of an efficient communication and multi-scenario switching mechanism between multi-level virtual machines of an intelligent connected vehicle.

[0064] Figure 2 It is a schematic diagram of communication data flow and hierarchical division between virtual machines of an intelligent connected vehicle.

[0065] Figure 3 It is a framework diagram of real-time performance and bandwidth analysis for communication between virtual machines of an intelligent connected vehicle.

[0066] Figure 4 It is a network resource allocation diagram for communication between multi-level virtual machines of an intelligent connected vehicle in different modes.

[0067] Figure 5 It is a flowchart of a resource scheduling decision path for communication between multi-level virtual machines of an intelligent connected vehicle.

[0068] Figure 6 It is a schematic diagram of the principle of a resource scheduling decision path for communication between multi-level virtual machines of an intelligent connected vehicle.

[0069] Figure 7 It is a schematic diagram of the principle of a parallel communication mechanism between multi-level virtual machines of an intelligent connected vehicle. Detailed Embodiments

[0070] The following further describes the present invention in conjunction with the drawings and specific embodiments, so that those skilled in the art can better understand the present invention and implement it, but the embodiments given are not intended to limit the present invention.

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

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

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

[0074] S3: Resource allocation and priority management, which is used to optimize resource utilization and ensure real-time performance, and 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: Isolation implementation of virtual network channels, which is used to ensure data security and avoid interference, create independent virtual network channels for different communication units, achieve isolation between data streams, improve the stability of the system, and ensure data security to prevent malicious attacks or data leakage;

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

[0077] As Figure 2 shown, Figure 2 is a schematic diagram of communication data streams and hierarchical division between virtual machines of intelligent connected vehicles; The classification and hierarchical design of the data streams include the following steps:

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

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

[0080] The classification and hierarchical design of the data streams in this embodiment are specifically carried out according to the following steps:

[0081] Due to the characteristics of large differences in real-time requirements, large differences in bandwidth requirements, and large differences in security isolation requirements in the communication between virtual machines of the whole vehicle:

[0082] (1) Large differences in real-time requirements: Communication of control instructions has extremely high real-time requirements, and millisecond-level latency may trigger safety accidents; The real-time requirements for sensor data are relatively high, but slightly lower than those of control instructions; The real-time requirements for entertainment data are relatively low, and a certain amount of latency can be tolerated; The real-time requirements for diagnostic and maintenance data are the lowest.

[0083] (2) Large differences in bandwidth requirements: The bandwidth requirements for sensor data (such as cameras and radars) are very high, the bandwidth requirements for control instructions are low, the bandwidth requirements for entertainment data are medium, and the bandwidth requirements for diagnostic and maintenance data are relatively low and sporadic.

[0084] (3) Large differences in security isolation requirements: The security requirements for control instructions and sensor data are extremely high, and strong isolation is required to prevent data tampering and interference; the security requirements for entertainment data are medium; the security requirements for diagnostic and maintenance data are relatively low.

[0085] Therefore, for the convenience of subsequent differential communication resource scheduling and priority management, it is necessary to classify and hierarchically design data with different requirements:

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

[0087] The first category is control data streams, including core control instructions, safety system instructions, power system instructions, chassis system instructions, etc.:

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

[0089] Safety system instructions: airbag trigger, ABS (antilock braking system) control, ESP (electronic stability program) control, etc.

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

[0091] Chassis system instructions: 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: 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, respiration), etc.

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

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

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

[0100] Social media data: social platform messages, friend status updates, follow channel notifications, etc.

[0101] Timed news data: weather information, stock information, news, 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 logs: record the system operation status and event information.

[0104] Software update data: used to update in-vehicle software and firmware.

[0105] Remote diagnostic data: used for remote diagnosis of vehicle faults.

[0106] Vehicle usage data: record the vehicle usage conditions, such as mileage, fuel consumption, etc.

[0107] Vehicle fault codes: record the fault information of the vehicle.

[0108] Secondly, according to the above data stream classification, create an independent communication layer for each type of data stream.

[0109] Control layer: Control data such as driving instructions, braking signals, and steering controls has extremely high requirements for real-time performance and reliability. Any delay or error may lead to serious consequences. For some intelligent connected vehicles with redundant designs, the virtual machines in the control layer may be located in different physical hosts, and the TSN technology is used to complete the 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. The TSN technology can provide deterministic low-latency and low-jitter communication, which is suitable for application scenarios with extremely high requirements for time sensitivity; even within the same physical host, due to the sensitivity and high security requirements of the control layer data stream, the communication between virtual machines still does not adopt the shared memory method, but continues to use the TSN technology with sufficiently low latency.

[0110] Sensor layer: Some sensor data, such as that from cameras, radars, lidars, etc., also requires high real-time performance and bandwidth guarantee to support advanced driver assistance systems (ADAS) and autonomous driving functions. Although such data has high requirements for real-time performance and bandwidth, its importance and security level are slightly lower than that of control layer data. For some sensor data streams, such as emergency braking information or obstacle recognition data that require quick response and real-time control, in order to ensure their low latency and high reliability, TSN technology is used for transmission. For other sensor data with relatively lower real-time requirements, such as sensor data used for building high-precision maps or driving behavior analysis, traditional Ethernet is selected for transmission. Although the virtual machines of some sensor data streams may be located within the same physical host, considering the future expansion of the vehicle's sensing system during iteration and the isolation between different sensor data streams to avoid potential security risks, communication is still carried out using an Ethernet- or TSN-based virtual network instead of directly using shared memory.

[0111] Entertainment layer: Entertainment data such as audiobooks, online videos, and AI assistant interactions mainly serves the entertainment needs of passengers and has relatively low requirements for real-time performance. Occasional delays or jitters will not directly affect driving safety. To save costs and reduce system complexity, traditional Ethernet is selected for transmitting entertainment layer data streams. However, for local cache data loading in entertainment scenarios, using shared memory is more appropriate.

[0112] Diagnostic and maintenance layer: Diagnostic and maintenance data such as system logs, remote diagnosis, and software updates are mainly used for vehicle maintenance and fault troubleshooting and have the lowest requirements for real-time performance. Such data can usually tolerate relatively high latency, so traditional Ethernet is selected for transmission to reduce costs and simplify system design. Even if the virtual machines of some diagnostic functions are located within the same physical host, to ensure the security and integrity of diagnostic data and avoid potential security risks, communication is still carried out using an Ethernet-based virtual network instead of shared memory, which may allow malicious virtual machine programs to modify diagnostic data and cause false alarms.

[0113] S12: Divide into corresponding working modes according to the activity levels of virtual machines in different functional domains, and the working modes include driving mode, entertainment mode, and charging mode;

[0114] First of all, the core function of an intelligent connected vehicle is a means of transportation, and it is in the "driving mode" most of the time. Different driving scenarios are also distinguished under the driving mode (such as highway driving and urban driving, autonomous driving and manual driving, etc.). At this time, it should be ensured that critical tasks (such as control instructions) can obtain the required resources in a timely manner even under high system load, guarantee their real-time performance and reliability, and improve the driving safety of the vehicle;

[0115] Secondly, intelligent connected vehicles are increasingly equipped with entertainment features. In scenarios such as long-distance driving or traveling, the vehicle will be in a parked state at regular intervals, and people will focus on entertainment activities such as watching movies and playing games. At this time, the "entertainment mode" should be turned on to allow more computing power and memory resources for applications in the entertainment scenario, improve resource utilization, and enhance the satisfaction of the entertainment experience;

[0116] Finally, when the intelligent connected vehicle is charging, there is no longer an energy anxiety. Therefore, the vehicle is relatively safe in the "charging mode" and is particularly suitable for updating system-level software. In the "charging mode", entertainment activities can still be carried out inside the vehicle. At this time, less attention can be paid to saving power consumption when scheduling communication resources.

[0117] Preferably, the switching of the working mode mainly depends on the speed of the vehicle. If it is below 3 km / h, it is in the entertainment mode; if it is higher than this speed, it is in the driving mode; and it is in the charging mode only when charging on the charging pile.

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

[0119] S21: Roughly estimate the real-time performance and bandwidth requirements according to the "queuing theory" and "communication characteristics"; specifically as follows:

[0120] First, use the "queuing theory" to abstract the communication process between virtual machines on intelligent connected vehicles into a "queuing system". The data stream arrives at the "service desk" (processor or network) as a "customer" and waits in line for service. By analyzing the parameters of the queuing system, such as arrival rate, service rate, queue length, etc., the delay and packet loss rate of the data stream can be estimated.

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

[0122] For video streams, the data volume is large, the bandwidth requirement is high, and it is sensitive to delay. Calculate the bandwidth requirement according to the resolution, frame rate, color depth, and compression algorithm. However, the bandwidth of video streams is usually not constant and will fluctuate with the change of scene complexity because the video compression algorithm will determine the compression degree according to factors such as the change degree of frames and the richness of image details in each frame.

[0123] For audio streams, the data volume is relatively small, the bandwidth requirement is low, and it is sensitive to latency. The bandwidth requirement is calculated based on the sampling rate, bit depth, and compression algorithm. Similar to video streams, the magnitude of the bandwidth requirement 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 details of the audio data.

[0124] For control instructions, they have characteristics such as small data volume and high transmission frequency, and are very sensitive to latency. The bandwidth requirement is calculated based on the instruction length and transmission frequency. However, since the bandwidth requirement of control instructions is usually low, it can generally be ignored.

[0125] For sensor data, it has characteristics such as large data volume and high transmission frequency, and is sensitive to latency. The bandwidth requirement is calculated based on the data output rate and data format of the sensor. Compared with control flow data, the bandwidth requirement may be as high as several hundred Mbps depending on the type of sensor (for example, a 16-line lidar can output millions of point cloud data per second), so it cannot be ignored.

[0126] In different driving scenarios, there are differences in the bandwidth requirements for different data streams. For example, in the autonomous driving scenario, the bandwidth requirements for the sensor data streams generated by cameras and lidars are relatively high. Therefore, it is necessary to calculate the bandwidth requirements separately according to different driving scenarios.

[0127] S22: Accurately measure the real-time performance and bandwidth requirements based on the prototype vehicle experiment; specifically as follows:

[0128] After building the prototype vehicle or using a dedicated test platform, perform time synchronization through GPS or PTP to ensure that the timestamps of all measurement devices are consistent, so as to accurately measure the communication latency.

[0129] Then, connect the VN5600 series hardware tools to the automotive Ethernet network of the prototype vehicle, and install CANoe and Wireshark software on the host computer. After configuring the network measurement parameters, different driving conditions, communication modes between virtual machines, and different network loads can 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 stream tasks to operate normally in some simple working condition scenarios, and some model input data such as sensor sampling frequency and packet size can be obtained, providing support for the verification and accurate definition of model parameters in the subsequent vehicle network simulation process.

[0131] S23: Determine the latency and bandwidth requirement distribution through vehicle network simulation; specifically as follows:

[0132] According to the actual architecture of the vehicle network, use CANoe to build a vehicle network simulation model, that is, build a network topology model that defines the connection relationships of each node-link, build node models and link models, build a data flow model that defines the characteristics of data packets, and build a scenario model that defines different working modes and environmental conditions.

[0133] Next, configure measurement channels and data capture interfaces according to different data flows and communication levels to ensure that the communication data of target nodes and links can be monitored and recorded in real time during the simulation process.

[0134] In addition, in order to ensure the significance of subsequent large-scale simulation experiments, first conduct small-scale network operation simulation experiments. After verifying that the model accuracy meets the requirements, then conduct large-scale vehicle network simulations to obtain specific values of the network bandwidth and latency requirements for different data flows.

[0135] As Figure 4 shown, Figure 4 is a schematic diagram of network resource allocation for multi-level virtual machine communication in intelligent connected vehicles under different modes; the resource allocation and priority management include the following steps:

[0136] S31: Build a decision-making framework that adapts to different working modes and coordinates 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, and the traffic with low real-time requirements in the sensor layer, the entertainment layer, and the diagnostic and maintenance layer adopt EtherNet technology; the entertainment layer and the diagnostic and maintenance layer of the entertainment mode adopt EtherNet technology; the entertainment layer and the diagnostic and maintenance layer in the charging mode adopt EtherNet technology;

[0137] As follows Figure 5 shown, Figure 5 is a flowchart of the resource scheduling decision path for multi-level virtual machine communication in intelligent connected vehicles. It consists of a data flow communication task queue composed of several data packets. Query the category and level of the data packets, and judge whether the data packets are pre-planned static resources or whether they are static resources. If satisfied, they are respectively determined as static resources or dynamic resources; if the dynamic rule decision or the basic rule decision result is satisfied, then proceed according to the scheduling decision of the dynamic resources, otherwise, return to the queue and continue to wait;

[0138] Resource allocation is not completely manually specified. Instead, a part of the static basic communication resources is reserved by combining the QoS integrated service policy and the VCPU affinity configuration. The remaining communication resources are dynamically adjusted. The reserved static communication resources provide priority communication guarantees of low latency and high bandwidth for high-priority data streams. On the other hand, it also ensures that the vehicle can drive normally under complex environmental conditions where dynamic scheduling may fail. The regulation rules of dynamic communication resources are divided into preset basic rules and rules that need to dynamically adjust the strategy according to the working conditions. Among them, the preset rules are at the earlier position in the decision-making path, while the dynamic adjustment rules are at the later position. As long as the priority label of the data stream is "medium", it will be included in the preset basic rules for scheduling. In the data packet queue, the data streams are scheduled in order of priority from high to low. The data streams in the basic rules with higher priority should obtain more communication resource inclination according to some technical measures compared to those in the dynamic rules.

[0139] Such as Figure 6 shown Figure 6 As shown in the schematic diagram of the communication resource scheduling decision path between multi-level virtual machines of intelligent connected vehicles, determine the priorities of the control layer, sensor layer, entertainment layer, and diagnostic and maintenance layer; perform static resource allocation or dynamic resource scheduling according to three modes of high, medium, and low.

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

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

[0142] Since the control layer has high real-time and low-latency requirements, the highest-priority queue and sufficient bandwidth resources should be allocated to it in the TSN network to ensure the high real-time and delay-free transmission of control instructions.

[0143] The sensor layer has medium-high real-time, high bandwidth, and stable and continuous occupancy requirements. The QoS priority is set to "medium" or "high". The data streams of the sensor layer with "medium" priority are transmitted in the traditional Ethernet, while the data streams of the sensor layer with "high" priority are transmitted in the TSN network. According to the specific applications of different data streams, the data streams of security-sensitive tasks (such as emergency braking or obstacle recognition) are directly assigned the "high" priority manually to ensure the normal operation of the ADAS function, while the non-critical data streams (such as ultrasonic sensors for low-speed scenarios) are assigned the "medium" priority.

[0144] Preferably, the physical layer is equipped with a network card supporting SR-IOV, which allows a single physical network card to be virtualized into multiple virtual functions (VFs), and independent VFs are allocated to the virtual machines in the control layer and the sensor layer. This is equivalent to creating a dedicated channel that directly connects to the physical network card, which can reduce resource competition 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 hierarchical data stream, the competition phenomenon with the VFs of other data streams can be realized.

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

[0147] The diagnostic and maintenance layer has requirements for low real-time performance and occasional bandwidth occupation, and the QoS priority is set to "low". However, some data streams (such as real-time fault detection and warning) have high requirements for real-time performance. Therefore, the priority is set to "medium".

[0148] For the parts of the data streams in the sensor layer, entertainment layer, and diagnostic and maintenance layer where it is difficult to determine the priority, the priority is determined according to the real-time performance, bandwidth requirements, driving scenarios, etc. calculated in the above S2 step; regarding the driving scenario factors, for example, in a high-speed driving scenario compared to a low-speed driving scenario, more data in the sensor layer will be marked as "high" priority.

[0149] According to the correspondence between the priority and the rules, some data streams in the sensor layer may not be allocated static resources, but need to allocate dynamic resources through basic rules; while the data streams in the entertainment layer and the diagnostic and maintenance layer are allocated communication resources according to preset basic rules or dynamic rules. And due to the "energy-mileage anxiety" in both the driving mode and the entertainment mode of the intelligent connected vehicle, energy management factors such as the distance to the nearby charging station and the remaining mileage need to be considered to allocate communication resources.

[0150] Preferably, in order to ensure that the data streams in the basic rules with higher priority obtain more inclination of communication resources compared to those in the dynamic rules, the priority factor is considered in the training loss function designed in the S33 link, that is, the loss term suffered by the data streams in the basic rules due to incomplete supply of requirements will be given a larger weight coefficient.

[0151] Preferably, the decision logic of the basic rule is simpler than that of the dynamic rule, and more consideration is given to meeting requirements rather than balancing the load; specifically, the supply amount of communication resources in the basic rule depends more on the demand amount, etc., while the supply of communication resources in the dynamic rule depends more on the remaining amount of resources, etc.

[0152] Preferably, in order to consider the influence of the remaining battery energy on the communication bandwidth demand supply of non-critical data streams in the sensor layer and all data streams in the entertainment layer and diagnostic maintenance layer, a decimal related to the remaining energy percentage is multiplied by the communication resource supply amount under the condition that other factors remain unchanged.

[0153] Preferably, the decimals related to the remaining energy percentage in the basic rule and dynamic rule parts are not the same, and the former has a larger value; specifically, they are respectively equal to the remaining energy percentage plus 20% and the remaining energy percentage itself.

[0154] S33: Fine-tune the decision models of the basic rule and dynamic rule according to the real-time performance, bandwidth demand, priority level, working mode, etc. of the data stream; specifically, proceed as follows:

[0155] First, determine the input variables and output variables of the decision model. The input variables specifically include factors such as the real-time performance and bandwidth demand of the data stream, priority level, total dynamic resources, remaining resource quantity, network load situation, driving scenario category, environmental condition complexity, vehicle energy state, and distance to the nearby charging station. The output variable is the quantity of communication resources allocated to each data stream, specifically the amount of VCPU, memory, and bandwidth allocation.

[0156] Second, determine the type of the decision model. In this embodiment, the models of the basic rule and dynamic rule are both defined as MLP network models; the weights are different, but the decision input variables are the same, and they are included in one training process and share the same loss function. Under different working modes, different loss functions are set, and finally the model weights with the best resource allocation in each mode will be obtained.

[0157] Finally, design a loss function adapted to different working modes; the specific loss terms included and the finally obtained loss function are as follows:

[0158] (1) Loss related to real-time performance: In order to minimize the transmission delay of the data stream, especially for data streams with high priority and high real-time requirements, this loss term needs to be weighted according to the priority, and the delay penalty for high-priority data streams is greater to ensure that high-priority data streams obtain lower delays. If the delay exceeds the allowable range, the loss will increase, and the model will adjust the resource allocation strategy.

[0159] Preferably, the expression of the loss term related to real-time performance is:

[0160]

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

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

[0163] Preferably, the expression of the bandwidth-related loss term is:

[0164]

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

[0166] (3) Bandwidth utilization loss: To maximize the utilization of bandwidth resources, avoid waste, encourage the model to approach the reasonable resource allocation upper limit as much as possible to maximize resource utilization, it is necessary to set a bandwidth utilization loss term; at the same time, when the resource allocation is excessive (exceeding the safety ratio), the value of this loss term increases, and the model will adjust the resource allocation to reduce the possibility of overload.

[0167] Preferably, the expression of the bandwidth utilization loss term is:

[0168]

[0169] Among them, B total is the total bandwidth resource of the vehicle communication system, α is the system bandwidth robustness factor, and its value range is between 0.80 and 0.95. The specific value is judged according to factors such as the intelligence of the intelligent networked vehicle to ensure that there is remaining bandwidth resource to cope with emergencies and enhance the safety of the real-time sensitive driving system.

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

[0171] Preferably, the expression of the working mode switching smoothness loss term is:

[0172]

[0173] Among them, and are the communication resources (bandwidth and VCPU time) of data stream i before and after switching respectively, while R required,i is the resource requirement of data stream i.

[0174] Combining the four losses mentioned above, a comprehensive loss function is obtained to balance the relationship between different objectives:

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

[0176] Among them, λ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] Preferably, for the sake of convenience of description, only three levels of priorities, namely high, medium and low, are defined above. In actual vehicle development, in order to further finely divide the importance of different data streams, more priority levels may need to be defined, such as five levels.

[0178] Preferably, when the vehicle is in the transition state between two modes, the model outputs in both modes are considered simultaneously; specifically, it can be the averaging of the decision results.

[0179] S34: Integrate the above decision model into the vehicle network simulation model, so that the model can monitor the running state of the simulation network, and then make real-time decisions on network resource allocation parameters. Pause the simulation every five minutes, and then use the loss function to complete a weight optimization. Then, integrate the updated decision model into the global simulation model again, and observe whether each performance index (such as data stream task communication) meets the requirements. If not, continue to optimize until it meets the requirements;

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

[0181] S41: Set the virtual network interfaces of each virtual machine, and each virtual network interface corresponds to the corresponding data stream;

[0182] S42: The virtual machines in the same network layer form a virtual local area network through a virtual switch;

[0183] S43: Set a virtual router, and the virtual router is used to connect different virtual switches to implement the network isolation function;

[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 flows 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 flow category, and each layer independently processes its corresponding data flow, thereby achieving preliminary isolation.

[0186] In the virtualization scenario 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 achieved directly through virtual switches.

[0187] Since virtual switches can only forward data within the same virtual LAN, in order to achieve communication between different virtual LANs, it is necessary to use a device that can perform routing and forwarding.

[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 the network traffic within the virtual LAN to which it is connected. Network traffic between different virtual routers needs to be forwarded through routing to be interoperable, thereby achieving isolation between different data flow categories.

[0189] Preferably, most virtualization platforms (such as KVM and Xen) provide a virtual router function, and network isolation can be achieved by configuring a virtual router instance.

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

[0191] Since the virtual router will connect different virtual LANs, it is also necessary to configure firewall rules to refine and regulate the access control between virtual machines in different virtual LANs.

[0192] Specifically, virtual machines in a low-priority virtual LAN are prohibited from accessing virtual machines in a high-priority virtual LAN, or only access to data on a specific port is allowed.

[0193] The above virtual switch, virtual router and firewall configuration can ensure that there is no direct connection or shared communication resources between these virtual machines, so as to achieve complete isolation of traffic and non-interference, and avoid disorderly occupation of bandwidth resources.

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

[0195] S51: Construct the 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 the virtualization layer. The virtualization layer virtualizes the multi-core processor into multiple processors, and through virtual machines, the processing of different data streams is allocated to different processors for processing;

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

[0198] The design of the parallel processing mechanism in this embodiment is specifically processed in the following manner:

[0199] In order to maximize the advantages brought by multi-level isolation communication, it is necessary to design an efficient parallel processing mechanism, including the cooperation between the physical layer, virtualization layer, and application layer, to give full play to the performance of hardware resources.

[0200] (1) Physical layer: The in-vehicle domain controller should be equipped with a multi-core processor and a network card that supports multi-queues and SR-IOV, providing the necessary hardware foundation for parallel operation of the virtualization layer and application layer. The multi-core processor can achieve true parallel processing (instead of the polling method), significantly improving system performance. By using the multi-queue support feature of the network card, network data packets can be distributed to different vCPUs for processing, realizing the parallelization of network data processing, further improving network throughput and reducing latency.

[0201] (2) Virtualization layer: The Hypervisor virtualizes the 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 to ensure that there is a CPU core dedicated to processing data streams at a specific level, improving processing efficiency.

[0202] (3) Application layer: In terms of communication mechanisms and queue management, high-priority data streams adopt synchronous communication and independent queue management systems to maximize communication real-time performance. Through mechanisms such as priority thread scheduling and resource reservation, it ensures that it can obtain the required resources in a timely manner, avoiding interference from low-priority data streams, thus meeting strict requirements for real-time performance and reliability. For low-priority data streams, asynchronous communication and shared queue management systems are adopted to reduce CPU and memory resource consumption, and to maximize the system throughput and efficiency without affecting high-priority data streams.

[0203] By integrating the parallel processing mechanisms of the physical layer, virtualization layer, and application layer, the advantages of multi-level isolation communication can be fully exploited, improving the overall performance and real-time performance of the central centralized domain controller of intelligent connected vehicles. This hierarchical optimization strategy can effectively allocate and utilize system resources, and perform differential processing according to the priority and real-time requirements of different data streams, thus meeting the requirements of intelligent connected vehicles for high performance, high reliability, and high security.

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

Claims

1. Method for communication between multi-level virtual machines and multi-scenario switching of intelligent connected vehicles, characterized in that: It includes the following steps: S1: Data flow classification and hierarchical design, which is used to determine communication units and modes, and conduct resource requirement assessment, allocation, and priority management according to application scenarios; S2: Real-time and bandwidth requirement assessment, which is used to evaluate the resource type requirements of different data flows and determine dynamic resource allocation and priority management decisions during the operation of the whole vehicle; S3: Resource allocation and priority management, which is used to allocate corresponding communication resources and scheduling priorities to different communication units; S4: Isolation implementation of virtual network channels, which is used to create independent virtual network channels for different communication units to achieve isolation between data flows; S5: Design of parallel processing mechanism, which is used to achieve the concurrent execution process of data flows through multi-core processors and hardware virtualization technologies.

2. The method for multi-level virtual machine communication and multi-scenario switching in an intelligent network-connected vehicle according to claim 1, wherein: The data flow classification and hierarchical design includes the following steps: S11: Classify communication data to obtain different types of data flows, and the different types of data flows include control data, sensor data, entertainment data, and diagnostic and maintenance data; S12: Create corresponding communication layers according to different types of data flows; the communication layers include a control layer, a sensor layer, an entertainment layer, and a diagnostic and maintenance layer.

3. The method for multi-level virtual machine communication and multi-scenario switching in an intelligent networked vehicle according to claim 1, characterized in that: The real-time and bandwidth requirement assessment includes the following steps: S21: Roughly estimate real-time and bandwidth requirements according to "queuing theory" and "communication characteristics". Use "queuing theory" to abstract the communication process between virtual machines on an intelligent network-connected vehicle into a "queuing system", where data flows queue up waiting for service. By analyzing the parameters of the queuing system, estimate the delay and packet loss rate of data flows; determine the approximate bandwidth requirements for different data flow communications according to "communication characteristics"; S22: Obtain the experimental measurement results of the prototype vehicle, and the measurement results include real-time and bandwidth requirement data of communication; S23: Obtain the whole vehicle network simulation model to get the specific values of the network bandwidth and delay requirements for different data flows.

4. The method for multi-level virtual machine communication and multi-scenario switching in an intelligent network-connected vehicle according to claim 1, characterized in that: The resource allocation and priority management includes the following steps: S31: Build a decision 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 according to the characteristics of data flow network resource requirements in different working modes; S33: Design a decision model for basic rules and dynamic rules according to the real-time and bandwidth requirements of data flows, priority levels, and working modes; S34: Build a decision model in the whole vehicle network simulation model, and monitor the operation status of the simulation network through the decision model to obtain an optimized model for network resource allocation.

5. The method for multi-level virtual machine communication and multi-scenario switching in an intelligent connected vehicle according to claim 4, characterized in that: In step S32, the allocation priorities and rules are designed according to the characteristics of data flow network resource requirements in different working modes; specifically, it is carried out in the following manner: (1) Calculate the real-time related loss term according to the following formula: Among them, L i is the actual transmission delay of data stream i, and L max is the maximum delay allowed by the system, and Priority i is the priority of data stream i; (2) Calculate the bandwidth related loss term according to the following formula: Among them, B allocated,i is the bandwidth resource allocated to data stream i, and B required,i is the bandwidth requirement of data stream i, and Priority i is the priority of data stream i; (3) Calculate the bandwidth utilization loss term according to the following formula: Among them, B total is the total bandwidth resource of the vehicle communication system, and α is the system bandwidth robustness factor; (4) Calculate the smoothness loss term of working mode switching according to the following formula: wherein, and are the communication resources (bandwidth and VCPU time) of data stream i before and after the handover respectively, while R required,i is the resource requirement of data stream i; (5) Calculate the comprehensive loss function according to the following formula: Total Loss=λ1·Loss latency +λ2·Loss bandwidth +λ3·Loss utilization +λ4·Loss mode-switch ; Among them, λ1, λ2, λ2, and λ2 are the contribution weights of each loss term to the total loss; (6) Determine the network resource allocation priority according to the comprehensive loss function.

6. The method for multi-level virtual machine communication and multi-scenario switching in an intelligent networked vehicle according to claim 1, wherein: The isolation implementation of the virtual network channel includes the following steps: S41: Set the virtual network interfaces of each virtual machine, and each virtual network interface corresponds to a corresponding data stream; S42: The virtual machines in the same network layer form a virtual local area network through a virtual switch; S43: Set a virtual router, and the virtual router is used to connect different virtual switches to implement the network isolation function.

7. The method for multi-level virtual machine communication and multi-scenario switching in an intelligent networked vehicle according to claim 1, characterized in that: The design of the parallel processing mechanism includes the following steps: S51: Construct the 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. The virtualization layer virtualizes the multi-core processor into multiple processors, and through the virtual machine, the processing of different data streams is allocated to different processors for processing; S53: Determine the priority of data stream processing, and set the thread scheduling and resource reservation mechanism according to different priorities.

8. An intelligent networked vehicle multi-level virtual machine communication and multi-scenario switching system, including a memory, a processor, and a computer program stored on 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 7 above.

Images