Adaptive switching method and device of vehicle-mounted protocol, electronic equipment and storage medium

Abstract

The invention relates to a self-adaptive switching method and device of a vehicle-mounted protocol, electronic equipment and a storage medium, and the method comprises the steps: obtaining real-time multi-source data in a vehicle driving process, the multi-source data being used for indicating a current driving scene; according to the multi-source data, an expected performance vector and a predicted performance vector of each protocol are constructed, the expected performance vector is used for indicating the lowest transmission performance required by normal operation of a vehicle-mounted service in a current driving scene, and the predicted performance vector is used for indicating the network transmission performance of the corresponding protocol in a future preset duration; and comparing the expected performance vector with the predicted performance vector of each protocol, eliminating the protocol which does not meet the lowest transmission performance in the current driving scene, obtaining a reserved feasible protocol, and switching from the current protocol to the feasible protocol. According to the invention, the communication stability after vehicle-mounted protocol switching is improved.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to an adaptive switching method, apparatus, electronic device and storage medium for vehicle protocols. Background Technology

[0002] Vehicle-to-everything (V2X) network communication is facing increasingly complex dynamic network environments and diversified vehicle application demands. On the one hand, vehicles need to adapt to network fluctuations under various road conditions, such as high-speed driving, weak tunnel coverage, and dense urban intersections, as well as the risk of 5G / 4G switching and V2X direct communication interruptions. On the other hand, services such as autonomous driving control, high-definition cockpit video, OTA upgrades, and vehicle-road cooperative interaction have significantly different requirements for network latency, throughput, and reliability.

[0003] To adapt to diverse scenarios, vehicle communication systems need to be compatible with various heterogeneous network protocols. Traditional protocols, such as TCP (Transmission Control Protocol) and dedicated CAN bus transmission protocols, while possessing mature and stable characteristics, are no longer sufficient to meet the operational requirements of high-performance scenarios such as low latency, high throughput, and packet loss resistance. Meanwhile, new transmission protocols, such as QUIC (Quick UDP Internet Connections) and customized transmission protocols based on UDP (User Datagram Protocol), are gradually becoming the preferred solutions for high-performance scenarios due to their advantages such as fast connection establishment, multiplexing, and weak network adaptability.

[0004] Existing in-vehicle multi-protocol switching equipment can support multi-protocol access, but the protocol selection relies on pre-configured strategies and cannot be dynamically adapted, resulting in unstable communication quality after in-vehicle protocol switching. Summary of the Invention

[0005] This application provides an adaptive switching method, apparatus, electronic device, and storage medium for vehicle protocols to solve the problem of unstable communication quality after switching vehicle protocols.

[0006] Firstly, this application provides an adaptive switching method for vehicle protocols, the method comprising: Acquire real-time multi-source data during vehicle operation, wherein the multi-source data is used to indicate the current driving scenario; Based on the multi-source data, an expected performance vector and a predicted performance vector for each protocol are constructed respectively. The expected performance vector is used to indicate the minimum transmission performance required for the normal operation of vehicle services in the current driving scenario, and the predicted performance vector is used to indicate the network transmission performance of the corresponding protocol in the future within a preset time period. By comparing the expected performance vector with the predicted performance vector of each protocol, protocols that do not meet the minimum transmission performance requirements under the current driving scenario are eliminated, and the remaining feasible protocols are obtained. The current protocol is then switched to the feasible protocol.

[0007] Optionally, the multi-source data includes network state data, and constructing a predicted performance vector for each protocol based on the multi-source data includes: The network indicators in the network status data are combined in a fixed field order to form the network status matrix, which is used to present real-time network transmission characteristics. Based on the network state matrix, historical network data of the protocol within the most recent fixed time window is collected; The basic data indicators in the historical network data are calculated using a set prediction algorithm to obtain multiple basic prediction indicators. Based on the signal strength time-series data and retransmission count time-series data in the historical network data, transmission stability is predicted to obtain a stability prediction index. By integrating the multiple basic prediction metrics and the stability prediction metrics, the prediction performance vector of the protocol is constructed.

[0008] Optionally, constructing the desired performance vector based on the multi-source data includes: A business evaluation matrix is ​​constructed based on at least two types of data from the multi-source data, wherein the business evaluation matrix is ​​used to evaluate in-vehicle business requirements; Multiple key data are extracted from the business evaluation matrix, including business data characteristics, scenario data characteristics, network data characteristics, and business degradation capability data. The business degradation capability is used to indicate whether the current in-vehicle service supports suspension, bitrate reduction, or interruption. The key data is transformed into quantitative indicators by executing preset conversion rules through a business mapping model. The conversion rules are obtained based on the joint modeling results of in-vehicle services and driving scenarios. The desired performance vector is formed by integrating multiple quantitative indicators.

[0009] Optionally, the multi-source data includes vehicle driving data, vehicle positioning data, map data, traffic data, and network status data. Constructing a business evaluation matrix based on at least two types of data from the multi-source data includes: The current driving scenario is determined based on at least two types of data from the multi-source data. The business parameter type corresponding to the current driving scenario is determined according to the preset mapping relationship between driving scenarios and parameter types; Read real-time parameter values ​​that conform to the business parameter type from the multi-source data, and then concatenate the real-time parameter values ​​according to a preset structure to form the business evaluation matrix.

[0010] Optionally, by comparing the expected performance vector with the predicted performance vector of each protocol, protocols that do not meet the minimum transmission performance requirements under the current driving scenario are eliminated, resulting in the following remaining feasible protocols: Hard constraints are determined based on the expected performance vector, wherein the hard constraints are used to indicate the minimum transmission performance indicators required for the normal operation of the current vehicular service. The predicted performance vector of each protocol is compared with the hard constraints one by one; The protocol from which all indices of the predicted performance vector satisfy the hard constraint is selected as a feasible protocol.

[0011] Optionally, after obtaining the retained feasible protocol, the method further includes: If multiple feasible protocols are retained, then multiple scoring items are determined for each of the feasible protocols; The various scoring items include service-protocol difference score, instability penalty score, and multidimensional correlation penalty score. The service-protocol difference score is used to indicate the degree of dimension-wise difference between the predicted performance vector and the expected performance vector of the feasible protocol. The instability penalty score is used to indicate the fluctuation risk of the feasible protocol in transmission performance. The multidimensional correlation penalty score is used to indicate the degree of comprehensive deviation of the feasible protocol from the requirements of vehicle services in multiple transmission indicators. The weighted summation of the various scoring items yields the preliminary comprehensive utility of the feasible protocol, wherein the preliminary comprehensive utility indicates the degree of matching between the feasible protocol and the vehicle service requirements, as well as the degree of operational risk. Based on the protocol switching cost of switching from the current protocol to the feasible protocol, the preliminary comprehensive utility is adjusted to obtain the adjusted final comprehensive utility; The protocol with the highest overall utility from the final overall utility is selected as the optimal protocol.

[0012] Optionally, determining the instability penalty of the feasible protocol includes: Determine the variance of the predicted performance vector of the feasible protocol; The instability penalty of the feasible protocol is determined based on the preset instability penalty weight and the variance, wherein the instability penalty is inversely related to the protocol stability.

[0013] Secondly, this application provides an adaptive switching device for vehicle protocols, the device comprising: The acquisition module is used to acquire real-time multi-source data during vehicle operation, wherein the multi-source data is used to indicate the current driving scenario; The construction module is used to construct the expected performance vector and the predicted performance vector for each protocol based on the multi-source data. The expected performance vector is used to indicate the minimum transmission performance required for the normal operation of the vehicle service in the current driving scenario, and the predicted performance vector is used to indicate the network transmission performance of the corresponding protocol in the future preset time period. The switching module is used to compare the expected performance vector with the predicted performance vector of each protocol, eliminate protocols that do not meet the minimum transmission performance under the current driving scenario, obtain the remaining feasible protocols, and switch from the current protocol to the feasible protocol.

[0014] Thirdly, this application provides an electronic device, comprising: at least one communication interface; at least one bus connected to the at least one communication interface; at least one processor connected to the at least one bus; and at least one memory connected to the at least one bus.

[0015] Fourthly, this application also provides a computer storage medium storing computer-executable instructions for executing the adaptive switching method of the vehicle protocol described in any of the preceding claims of this application.

[0016] The technical solutions provided in this application have the following advantages compared with the prior art: Multi-source data generated during vehicle operation accurately reflects the current driving scenario. The expected performance vector, generated based on this multi-source data, clarifies the minimum transmission performance required for normal operation of in-vehicle services and is adapted to the current driving scenario due to the deep correlation between the data source and the scenario. Similarly, the predicted performance vectors for each protocol are constructed based on multi-source data, characterizing the network transmission capabilities of the corresponding protocol within a preset future timeframe, ensuring a consistent basis for comparison with the expected performance vectors. By precisely benchmarking the expected performance vectors and the predicted performance vectors for each protocol against network transmission performance indicators, protocols that do not meet the minimum transmission requirements are eliminated. The remaining feasible protocols are both compatible with the current driving scenario due to the scenario adaptability of the expected performance vectors and meet the minimum communication requirements of in-vehicle services, thereby improving communication stability after switching in-vehicle protocols. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0020] Figure 1 This is a schematic diagram of the vehicle system architecture provided in an embodiment of this application; Figure 2 A flowchart illustrating an adaptive switching method for an in-vehicle protocol provided in an embodiment of this application; Figure 3 This application provides an overall flowchart of adaptive switching of vehicle protocols. Figure 4 A schematic diagram of the structure of an adaptive switching device for vehicle protocols provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0023] Figure 1 This is a schematic diagram of the vehicle system architecture of this application, which includes five major modules.

[0024] The vehicle's internal system encompasses the sensor layer, actuator control, and cockpit domain controller. Camera or radar data from the sensor layer is input to the protocol decision engine via the CAN bus as the basis for network switching. Protocol commands are accelerated by actuator hardware and then sent to the braking or steering system to ensure low-latency control. The cockpit domain controller synchronizes the protocol status to the human-machine interface, supporting real-time network monitoring by the driver.

[0025] Communication module: Includes wireless interface and computing storage unit. The wireless interface supports 4G or 5G cellular network and V2X direct communication, serving as the entry point for vehicle-cloud, vehicle-road interaction, and realizing the transmission and reception of network data. The computing storage unit has a built-in CPU or FPU processing unit and eMMC+DDR storage combination, which is responsible for parsing the network protocol stack, caching data, and storing protocol decision intermediate states.

[0026] MCU control module: Includes protocol decision engine and multi-protocol execution layer. Protocol decision engine integrates dynamic evaluation matrix and AI decision core, responsible for generating protocol switching strategy; multi-protocol execution layer includes pre-built connection pool and shared memory context pool. Connection pool maintains keep-alive links of multiple protocols to reduce fault switching latency. Shared memory context pool is responsible for storing state data such as session key and sequence number, supporting seamless migration across protocols.

[0027] Hardware acceleration module: Includes DMA (Direct Memory Access) channel and optional NPU (Neural Processing Unit) acceleration unit. The DMA channel achieves zero-copy migration of encrypted context through direct memory access technology, reducing CPU load. The NPU acceleration uses a dedicated neural network processor to optimize protocol switching calculations and improve AI decision-making efficiency.

[0028] The data flow process in this system architecture is shown below.

[0029] (a) Multi-source data acquisition stage.

[0030] The sensor layer of the vehicle's internal system collects driving environment data in real time and transmits it to the protocol decision engine via the CAN bus. At the same time, the wireless interface of the communication module captures vehicle-cloud, vehicle-road interaction data and network status parameters, and transmits them to the computing and storage unit to complete protocol stack parsing and data caching. The two types of data together constitute the input basis for protocol decision-making, ensuring the comprehensiveness of the decision basis.

[0031] (ii) Smart Protocol Decision-Making Stage.

[0032] The computing and storage unit synchronizes the cached business data and network status data to the protocol decision engine, dynamically evaluates the generated matrix, and then the AI ​​decision core performs precise screening through the Q-learning algorithm, comprehensively considering indicators such as protocol latency, stability, and retransmission overhead, and outputs the optimal protocol selection instruction.

[0033] (iii) Protocol execution and state transition phase.

[0034] The multi-protocol execution layer responds to decision instructions and activates the target protocol keep-alive link in the pre-built connection pool. If cross-protocol switching is involved, the shared memory context pool retrieves state data to complete seamless migration without the need to re-establish a connection, ensuring the continuity of business transmission.

[0035] (iv) Hardware acceleration and optimization phase.

[0036] During protocol switching, the DMA channel initiates zero-copy migration technology to reduce CPU load. If equipped with an NPU acceleration unit, the AI ​​decision-making calculation process is optimized simultaneously, providing dual protection for system operating efficiency.

[0037] (v) Instruction execution and status feedback stage.

[0038] The optimized protocol commands are sent to the actuator control unit to achieve low-latency business response; at the same time, the protocol working status is synchronized to the human-machine interface via the cockpit domain controller, forming a complete closed loop of data collection, decision-making, execution and feedback.

[0039] The adaptive switching method for vehicle protocols provided in this application will be described in detail below with reference to specific implementation methods, taking its application to an MCU as an example. Figure 2 As shown, the specific steps are as follows: Step 201: Acquire real-time multi-source data during vehicle operation, wherein the multi-source data is used to indicate the current driving scenario; Step 202: Construct the expected performance vector and the predicted performance vector for each protocol based on the multi-source data. The expected performance vector is used to indicate the minimum transmission performance required for the normal operation of the vehicle service in the current driving scenario, and the predicted performance vector is used to indicate the network transmission performance of the corresponding protocol in the future within a preset time period. Step 203: By comparing the expected performance vector with the predicted performance vector of each protocol, protocols that do not meet the minimum transmission performance under the current driving scenario are eliminated, and the remaining feasible protocols are obtained. The current protocol is then switched to a feasible protocol. In step 201, the MCU acquires real-time multi-source data during vehicle operation. The multi-source data includes vehicle driving data, vehicle positioning data, map data, traffic data, and network status data. The sources and specific contents of each type of data are as follows.

[0040] Vehicle driving data: derived from vehicle power domain, cockpit domain controller and bus data, including vehicle speed, acceleration, etc.

[0041] Vehicle location data: sourced from the positioning module, including vehicle coordinates or latitude and longitude.

[0042] Map data: sourced from locally stored high-precision maps or cloud map APIs, including slopes, tunnel groups, bridges, or ramps.

[0043] Traffic data: derived from camera or radar data, sensor data and V2X broadcasts, including traffic events, road congestion and density, with traffic events covering congestion, traffic light density or number of lanes, etc.

[0044] Network status data: sourced from base stations, 4G or 5G cellular networks, V2X antenna interfaces, Ethernet or V2X radio frequency and roadside equipment, including round-trip time (RTT), packet loss rate, available bandwidth, jitter, RSRP (Reference Signal Receiving Power) or SINR (Signal to Interference plus Noise Ratio).

[0045] Multi-source data offers complementary dimensions; a single data source cannot fully depict a driving scenario, while the collaborative collection of multi-source data enables comprehensive scenario perception, avoiding misjudgments caused by distortion from a single data source. Specifically, vehicle driving data reflects its own motion state, vehicle positioning data reflects its real-time location, map and traffic data provide road information, and network status data reflects the current link quality. Multi-source data, from four core dimensions—the vehicle itself, the geographical environment, the traffic environment, and the communication environment—jointly construct a complete profile of the driving scenario, ensuring the accuracy of driving scenario identification.

[0046] For example, vehicle location data shows that the vehicle is on a highway, and combined with map data, the road type is confirmed to be a highway. Traffic data shows that the highway is currently congested, and network status data indicates that the signal strength is unstable. Together, these factors confirm the scenario of a congested highway driving.

[0047] In step 202, the MCU constructs a desired performance vector based on at least two types of data from multiple sources. These at least two types of data cover at least two of the following: vehicle driving data, vehicle positioning data, map data, traffic data, and network status data, comprehensively reflecting the current driving scenario and the requirements of in-vehicle services. Through quantification, the desired performance vector clarifies the minimum standards for key network transmission indicators such as latency, bandwidth, jitter, weak coverage tolerance, and handover stability. This reflects the minimum transmission performance baseline necessary for the normal operation of in-vehicle services under the current driving scenario, ensuring the basic requirements for uninterrupted service operation.

[0048] For example, the expected performance vector is [expected latency ≤ 30ms, expected bandwidth ≥ 1Mbps, expected jitter ≤ 5ms, expected weak coverage tolerance ≥ 80%, expected handover stability ≥ 99%]. The expected performance vector clarifies the minimum transmission performance standards required for the normal operation of vehicle services. Failure to meet any of the indicators may lead to abnormal service transmission.

[0049] The MCU simultaneously uses network status data metrics from multiple data sources to determine historical network data for each protocol and constructs a predicted performance vector for each protocol. This predicted performance vector maintains the same dimension as the expected performance vector, accurately reflecting the network transmission capability of the corresponding protocol within a preset timeframe under the current driving scenario, including key indicators such as predicted latency, predicted bandwidth, and predicted jitter, providing direct quantitative basis for subsequent protocol performance comparisons.

[0050] For example, the predicted performance vector for the TCP protocol is [predicted latency 60ms, predicted bandwidth 0.8Mbps, predicted jitter 8ms, predicted weak coverage tolerance 70%, predicted handover stability 98.5%]. The predicted performance vector for the QUIC protocol is [predicted latency 25ms, predicted bandwidth 2Mbps, predicted jitter 3ms, predicted weak coverage tolerance 95%, predicted handover stability 99%].

[0051] In step 203, the MCU rigorously compares the predicted performance vector of each protocol with the expected performance vector in a dimension-by-dimensional manner, verifying whether the predicted indicators of each protocol meet the corresponding minimum requirements. The comparison follows a veto rule: if any indicator in the predicted performance vector of a protocol fails to meet the corresponding standard of the expected performance vector, the MCU directly eliminates it; only when the predicted indicators of all dimensions of a protocol meet the standards, that is, its future transmission capacity can cover the minimum service requirements, is it included in the candidate range.

[0052] Through the above screening process, the MCU eliminates all protocols that fail to meet performance standards, and the final set of protocols constitutes a feasible protocol set. If the feasible protocol set contains only one protocol, the MCU directly identifies it as the protocol to be switched; if the feasible protocol set contains multiple protocols, the MCU can select any protocol to perform the switch according to actual needs, ensuring that the switched protocols can meet the minimum transmission requirements of in-vehicle services in the current driving scenario, thus laying the foundation for communication stability.

[0053] For example, the predicted performance vectors of both the TCP and QUIC protocols are compared with the expected performance vectors. If the QUIC protocol is found to meet the requirements, then the QUIC protocol is considered a feasible protocol.

[0054] In this application, multi-source data during vehicle operation accurately reflects the current driving scenario. The expected performance vector generated based on this multi-source data clarifies the minimum transmission performance required for the normal operation of in-vehicle services and is adapted to the current driving scenario due to the deep correlation between the data source and the scenario. The predicted performance vectors of each protocol are also constructed based on multi-source data, depicting the network transmission capability of the corresponding protocol within a preset time period in the future, ensuring a consistent basis for comparison with the expected performance vector. By accurately benchmarking the expected performance vector and the predicted performance vector of each protocol against network transmission performance indicators, protocols that do not meet the minimum transmission requirements are eliminated. The remaining feasible protocols are both compatible with the current driving scenario due to the scenario adaptability of the expected performance vector and meet the minimum communication requirements of in-vehicle services, thereby improving communication stability after protocol switching.

[0055] As an optional approach, in step 202, the multi-source data includes network state data, and constructing a predicted performance vector for each protocol based on the multi-source data includes: Step S11: Combine the network indicators in the network status data according to a fixed field order to form the network status matrix, wherein the network status matrix is ​​used to present real-time network transmission characteristics.

[0056] The MCU collects network status data from multiple data sources at fixed intervals, such as 50ms–500ms. This network status data covers core network metrics such as latency (τ), packet loss rate (ρ), available bandwidth (β), jitter, and signal strength (RSRP or SINR). These metrics reflect the real-time transmission status of the network from different dimensions. The content parameters and sources of the network status data are shown in Table 1.

[0057] Table 1

[0058] To ensure the structured and interpretable nature of the data, the MCU combines the above network metrics in an ordered manner according to a preset fixed field sequence to form a network state matrix. The formula for the network state matrix is: N(t)=[τ,ρ,β,jitter,RSRP…], where N(t) is the network state matrix, τ is the latency, ρ is the packet loss rate, β is the available bandwidth, jitter is the jitter, and RSRP is the reference signal received power.

[0059] The field order remains unchanged throughout the protocol decision-making process to avoid errors in subsequent data processing due to field confusion. The network state matrix is ​​presented as a dataset, its purpose being to integrate discrete network metrics into a unified dataset, providing a clear and comprehensive view of real-time network transmission characteristics. Through this network state matrix, the MCU can quickly obtain the overall status of the current network.

[0060] Step S12: Collect historical network data of the protocol within the most recent fixed time window according to the network state matrix.

[0061] Using the constructed network state matrix as its data foundation, the MCU initiates a historical network data acquisition process for each candidate protocol, such as TCP and QUIC. The acquisition process adheres to the principles of protocol exclusivity and time window limitation, collecting network operation data for each protocol within the most recent fixed time window to ensure accurate correspondence between historical data and protocol type, avoiding data confusion between different protocols. The duration of the fixed time window can be dynamically configured according to the actual application scenario, with a default setting of 1-5 seconds. This duration ensures sufficient historical network data is collected to reflect network trends while avoiding data lag due to excessively long windows, ensuring the real-time nature of the prediction results.

[0062] Step S13: Calculate the basic data indicators in the historical network data using the set prediction algorithm to obtain multiple basic prediction indicators.

[0063] The MCU acquires basic data metrics from the collected historical network data, such as round-trip latency, packet loss rate, throughput, and jitter. These basic data metrics are: N_hist(t)={RTT(τ),Loss(τ),Throughput(τ),Jitter(τ)},τ∈[t [T,t], where N_hist(t) is the set of network historical data for a certain protocol within the most recent fixed time window, [t [T,t] represents the time range of a fixed time window, T represents the duration of the fixed time window, τ represents the τth time within the fixed time window, RTT(τ) represents the round-trip delay at each time τ, Loss(τ) represents the packet loss rate at each time τ, Throughput(τ) represents the throughput at each time τ, and Jitter(τ) represents the jitter at each time τ.

[0064] The MCU uses a variety of preset prediction algorithms to calculate and obtain several basic prediction indicators, such as predicted round-trip time, predicted packet loss rate, predicted throughput, or predicted jitter.

[0065] The preset algorithm can be either the sliding window trend extrapolation method or simple linear regression prediction. The prediction algorithm can be adaptively selected according to the complexity of the network environment, or each prediction algorithm can be calculated in parallel and the optimal result can be taken to ensure prediction accuracy.

[0066] The following sections will provide specific explanations of the sliding window trend extrapolation method and simple linear regression prediction.

[0067] Sliding window trend extrapolation method.

[0068] The core logic of the sliding window trend extrapolation method is to extrapolate future indicator trends by analyzing the mean and slope of historical network data. Specifically, the MCU first calculates the average value and slope of each basic data indicator within a fixed time window for each basic data indicator in the historical network data set N_hist(t). The average value reflects the baseline level of the basic data indicator, and the slope reflects the trend of the basic data indicator, such as rising, falling, or remaining stable. Then, the MCU combines this with preset trend extrapolation coefficients to calculate the predicted values ​​of each basic data indicator, thus predicting future transmission performance.

[0069] The formula for predicting round-trip time delay is: RTT_pred = RTT_mean + k × RTT_slope, where RTT_pred represents the predicted value of round-trip time delay; RTT_mean represents the average value of round-trip time delay within a fixed time window; RTT_slope represents the slope of round-trip time delay over time within the time window, with a positive slope indicating an upward trend and a negative slope indicating a downward trend; k is the trend extrapolation coefficient, ranging from 1 to 2, which can be dynamically adjusted according to the degree of network fluctuation. It is set to 1 when the network fluctuation is small and 2 when the fluctuation is large to enhance the adaptability of the prediction.

[0070] The prediction formulas for other basic indicators are similar. For example, the formula for predicting the packet loss rate is: Loss_pred = Loss_mean + k × Loss_slope, where Loss_pred is the predicted value of the packet loss rate, Loss_mean is the average value of the packet loss rate within a fixed time window, and Loss_slope is the slope of the packet loss rate change.

[0071] The formula for predicting throughput is: Throughput_pred = Throughput_mean + k × Throughput_slope, where Throughput_pred is the predicted throughput, Throughput_mean is the average throughput over a fixed time window, and Throughput_slope is the slope of throughput change.

[0072] The formula for predicting jitter is Jitter_pred = Jitter_mean + k × Jitter_slope, where Jitter_pred is the predicted value of jitter, Jitter_mean is the average value of jitter within a fixed time window, and Jitter_slope is the slope of jitter change.

[0073] Simple linear regression prediction.

[0074] Single linear regression prediction methods have the advantages of low computational cost and fast response speed, making them suitable for scenarios with high real-time requirements. The MCU performs linear fitting on each basic data indicator in the historical network dataset N_hist(t) within a fixed time window to construct a linear relationship model between the basic data indicator and time, and uses this model to predict the indicator values ​​at future times.

[0075] The linear fitting formula is X(t) = a × t1 + b, where X(t) represents the value of a certain basic data indicator (such as round-trip delay, packet loss rate, etc.) at time t; a represents the slope of the linear fitting line, reflecting the rate of change of the basic data indicator with time; b represents the intercept of the linear fitting line, reflecting the initial value of the basic data indicator when time is 0; and t1 represents the time within a fixed time window.

[0076] Based on the above linear fitting formula, the prediction formula for the next time point is X_pred=a×(t2+Δt)+b, where X_pred represents the predicted value of the basic data indicator; a and b have the same meaning as in the linear fitting formula; t2 represents the current time; Δt is the prediction time step, for example, 100ms, which can be adjusted according to the real-time requirements of the business to ensure that the prediction result can accurately correspond to the network performance within the preset time period in the future.

[0077] By using one or a combination of the two algorithms mentioned above, the MCU ultimately obtains basic prediction metrics such as round-trip time prediction (RTT_pred), packet loss rate prediction (Loss_pred), throughput prediction (Throughput_pred), and jitter prediction (Jitter_pred).

[0078] The set of basic predictive indicators for output is as follows: [RTT_pred,Loss_pred,Throughput_pred,Jitter_pred,Stability_pred].

[0079] Step S14: Based on the signal strength time-series data and retransmission count time-series data in the historical network data, perform transmission stability prediction to obtain a stability prediction index.

[0080] The MCU also extracts signal strength time-series data and retransmission count time-series data from the network historical data set N_hist(t). These two types of data are key indicators of protocol transmission stability. The signal strength time-series data records the continuous changes in network signal strength within the time window, which directly affects the reliability of data transmission. The retransmission count time-series data records the retransmission frequency of protocol data within the time window. The more retransmissions, the worse the transmission stability.

[0081] The MCU performs trend analysis on the extracted signal strength timing data to obtain the signal strength trend (SignalTrend). A positive trend value indicates an upward trend in signal strength, while a negative value indicates a downward trend. The larger the absolute value, the more obvious the trend. The MCU also performs trend analysis on the retransmission count timing data to obtain the retransmission count trend (RetransTrend). A positive trend value indicates an upward trend in the number of retransmissions, while a negative value indicates a downward trend. The larger the absolute value, the more obvious the trend.

[0082] The formula for calculating the stability prediction index is: Stability_pred=α×( Loss_pred)+β×(SignalTrend) γ×(RetransTrend), Stability_pred represents the stability prediction index, with a value range of 0~100. The higher the value, the better the protocol transmission stability. α, β and γ are all positive weights, preset according to the needs of vehicle services and network environment characteristics. The default value is 1, which can be dynamically optimized through the Qlearning algorithm. Loss_pred represents the inverse of the predicted packet loss rate. The lower the packet loss rate, the larger the predicted packet loss rate, and the more positive the contribution to stability. SignalTrend represents the signal strength trend. A positive value (signal enhancement) contributes positively to stability, while a negative value (signal weakening) has a negative impact. RetransTrend represents the inverse of the retransmission count trend. The fewer the retransmissions (when the trend is negative), the larger the retransmission count trend, and the more positive the contribution to stability. Through this formula, the MCU integrates the packet loss rate, signal strength trend, and retransmission count trend to quantify the protocol's stability prediction index, Stability_pred.

[0083] Step S15: By integrating the multiple basic prediction metrics and the stability prediction metrics, a prediction performance vector for the protocol is constructed.

[0084] After the MCU completes the calculation of the basic prediction metrics and the stability prediction metrics, it initiates the metric integration process, combining the two types of metrics in a fixed dimensional order to form a prediction performance vector for each protocol. For example, the dimensional order of the prediction performance vector is predefined as [round-trip delay prediction value, packet loss rate prediction value, throughput prediction value, jitter prediction value, stability prediction metric], which is consistent with the dimensions of the expected performance vector used for subsequent comparison, ensuring that the two can achieve accurate dimensional matching.

[0085] The specific form of the predicted performance vector is as follows: Perf_p(t)=[RTT_pred,Loss_pred,Throughput_pred,Jitter_pred,Stability_pred].

[0086] In steps S12 to S15, the prediction performance Perf_p(t) of protocol p at the current time t is obtained by processing the network historical data set N_hist(t) by the prediction method P_p of protocol p. The formula for the prediction performance vector is: Perf_p(t) = P_p(N_hist(t).

[0087] In this application, various network metrics are sequentially combined according to a preset fixed field order to form a network state matrix that comprehensively presents the real-time network transmission characteristics. The MCU uses this network state matrix as a structured data source to accurately collect historical network data for each protocol within the most recent fixed time window, such as time-series data for round-trip latency, packet loss rate, throughput, and jitter, ensuring the correlation and completeness between historical data and real-time network characteristics. Subsequently, prediction algorithms such as sliding window trend extrapolation and simple linear regression prediction are used to calculate the historical network data, obtaining basic prediction metrics such as predicted latency, predicted packet loss rate, predicted throughput, and predicted jitter. At the same time, transmission stability analysis is performed based on the signal strength time-series data and retransmission count time-series data in the historical network data to generate stability prediction metrics. Finally, the MCU integrates the above basic prediction metrics and stability prediction metrics to form a unified prediction performance vector. The prediction performance vector comprehensively reflects the network transmission capability of the corresponding protocol within a preset time period under the current driving scenario, providing a basis for subsequent protocol comparison and selection.

[0088] As an optional implementation, in step 202, constructing the desired performance vector based on the multi-source data includes: Step S21: Construct a business evaluation matrix based on at least two types of data from the multi-source data, wherein the business evaluation matrix is ​​used to evaluate in-vehicle business requirements.

[0089] The process of constructing the business evaluation matrix is ​​as follows: determine the current driving scenario based on at least two types of data from the multi-source data; determine the business parameter type corresponding to the current driving scenario according to the preset mapping relationship between the driving scenario and the parameter type; read the real-time parameter values ​​that conform to the business parameter type from the multi-source data, and concatenate the real-time parameter values ​​according to the preset structure to form the business evaluation matrix.

[0090] The MCU first performs collaborative analysis based on at least two types of data from multiple sources to accurately identify the current driving scenario. These multiple sources include vehicle driving data, vehicle location data, map data, traffic data, and network status data. The MCU cross-validates the feature associations of data from different dimensions to match corresponding typical driving scenarios. Typical driving scenarios include highway cruising, tunnel complexes, long tunnel entrances, urban congestion, steep mountain roads, and high frame rate sensing data upload scenarios.

[0091] The driving scenarios, scenario characteristics, and their corresponding parameter types are shown in Table 2.

[0092] Table 2

[0093] As shown in Table 2, different driving scenarios have distinct scenario characteristics and correspond to specific types of service parameters. For example, in tunnel scenarios, parameters such as tunnel length, tunnel gradient, and network attenuation must be included. In highway scenarios, parameters such as driving status, network coverage prediction, and cabin service type must be included. In urban congestion scenarios, parameters such as low-speed status, intersection density, and video stream stability should be emphasized.

[0094] After driving scene recognition is completed, the MCU filters the service parameter types suitable for the current driving scene based on the preset mapping relationship between driving scene and parameter type. The MCU reads or calculates the real-time values ​​of these service parameter types from multi-source data, combines them in a fixed field order to form a structured service evaluation matrix. The service evaluation matrix comprehensively covers the correlation information between scene features and vehicle service requirements. In this application, the parameters included in the service evaluation matrix are as follows: [current speed, acceleration, road slope, curvature, tunnel length, weak coverage prediction probability, base station density, road segment type, cockpit service bandwidth requirements, reliability level, latency sensitivity].

[0095] The formula for the business evaluation matrix is: ParamTypes(t) = F(Scene(t)); b_j(t)=Aggregate(ParamTypes(t)).

[0096] Where Scene(t) represents the driving scene identified at the current time t, F(·) represents the mapping function between the driving scene and the parameter type, ParamTypes(t) represents the set of selected business parameter types at the current time t, Aggregate(·) represents the aggregation function that concatenates the selected parameter types into a multidimensional matrix according to a predefined fixed structure, and b_j(t) represents the business evaluation matrix at the current time t.

[0097] In this application, the types of parameters and their data sources are as follows.

[0098] 1. Driving state parameters, reflecting the vehicle's dynamic characteristics, are provided in real time by the vehicle's dynamic domain or fusion domain. They are used to determine the impact of vehicle motion characteristics on network performance and include the following: current vehicle speed; acceleration; driving state (including constant speed, low speed, high speed, braking, and stopping). Driving state parameters are mainly used to characterize the mobility requirements in a scenario. For example, high-speed scenarios require higher handover stability, while low-speed or congested scenarios are sensitive to jitter.

[0099] 2. Map parameters, reflecting road structure and weak coverage risks, are provided by the high-precision map and network topology prediction module. They are used to characterize the communication attenuation characteristics caused by road structure, including the following: tunnel length, number of tunnel groups; road slope and curvature (affecting occlusion and attenuation); weak coverage area prediction (based on base station distribution and occlusion model). Map parameter data is used to judge the potential signal fading, bandwidth reduction and disconnection risks that may occur on subsequent roads, thereby affecting reliability weights and redundancy strategies.

[0100] 3. Driving route parameters, reflecting the macroscopic traffic and base station layout, are jointly generated by the positioning module and road network information. They are used to describe network load and handover complexity, including the following: Route type: urban, highway, mountainous; number of intersections; base station density and handover frequency prediction. Driving route parameters are used to model the impact of different road segments on network fluctuations, signal obstruction, and handover stability.

[0101] 4. Cockpit service type parameters reflect the network requirements of various in-vehicle services. These parameters are obtained from the cockpit OS, vehicle bus, and service identification module, and are used to describe the differences in latency, bandwidth, and reliability requirements of services. These include: image streaming services (high bandwidth, highly jitter-sensitive); control command services (extremely low latency, highest reliability); and file or OTA services (delayable, interruptible). When scenarios cause significant network fluctuations (such as tunnels, congestion, or mountainous areas), these service requirement differences will be incorporated into protocol decisions, thus requiring the inclusion of such parameters.

[0102] This application provides an example of constructing a service evaluation matrix. If the MCU identifies the current scenario as a tunnel group or the entrance of a long tunnel, it needs to filter parameter types such as tunnel length, slope, network attenuation prediction, and control service priority according to the mapping rules. After extracting real-time parameter values ​​from multi-source data, they are spliced ​​together according to a fixed structure to form a service evaluation matrix b_j(t). The fields of the service evaluation matrix include [current vehicle speed 35km or h, road slope 2°, tunnel length 1.2km, network attenuation prediction probability 85%, control service priority 0.9, weak coverage area prediction probability 90%], which fully presents the core requirements and environmental constraints of vehicle services in this scenario.

[0103] Step S22: Extract various key data from the business evaluation matrix. The key data includes business data characteristics, scenario data characteristics, network data characteristics, and business degradation capability data. The business degradation capability is used to indicate whether the current vehicle service supports pausing, reducing bit rate, or interruption.

[0104] Based on preset decomposition rules, the MCU extracts four categories of key data from the constructed business evaluation matrix b_j(t), ensuring that the data dimensions accurately match the input requirements of the subsequent business mapping model. The decomposition process follows the principle of one-to-one correspondence between matrix fields and key data, requiring no additional data dimensions; it only categorizes and extracts structured information from the matrix, guaranteeing the authenticity and relevance of the key data. The various key data extracted are shown below.

[0105] 1. Business data characteristics include business type (security, control, video, entertainment, and sensing), data size, transmission cycle, real-time level, etc., which directly reflect the differences in the core network transmission requirements of the business. For example, control business emphasizes ultra-low latency, while video business focuses on high bandwidth.

[0106] 2. Scene data features include driving scenarios (city, highway, tunnel, congestion, mountainous areas, etc.), HDMap structure (tunnel groups, slope, curvature), and depiction of the constraints of the current driving environment on network transmission.

[0107] 3. Network data characteristics include network status (bandwidth, latency, packet loss, jitter, weak coverage prediction), which directly reflects the potential state of the current and future network environment and provides a basis for assessing the network adaptability of service transmission.

[0108] 4. Service degradability data is used to determine whether the current in-vehicle service supports delayed transmission, reduced bitrate transmission, or interrupted transmission. For example, file or OTA services support delayed or interrupted transmission, while control services do not support any form of degradation.

[0109] Step S23: Execute the preset conversion rules through the business mapping model to convert the key data into quantitative indicators, wherein the conversion rules are obtained based on the joint modeling results of in-vehicle services and driving scenarios.

[0110] The MCU invokes a pre-defined business mapping model M to transform the four types of key data into quantitative indicators that can be directly used for protocol evaluation. The business mapping model M can be implemented based on a rule module or an ML (Machine Learning) model. Its function is to establish a transformation channel from abstract requirements to quantitative standards. Its input covers the four types of key data mentioned above. The transformation process is defined by the formula b_j^{desired}(t)=M(b_j(t)), where b_j^{desired}(t) represents the expected performance vector at the current time t; M(·) represents the business mapping model; and b_j(t) represents the business evaluation matrix at the current time t.

[0111] In this embodiment, the conversion rule is constructed based on the joint modeling results of in-vehicle services and driving scenarios. It adopts a dual-dimensional correlation logic of scenarios and services to ensure that the quantitative indicators are both adapted to scenario constraints and meet the core business needs.

[0112] A typical conversion rule example is shown below.

[0113] IFtype=control → high delay and high reliability requirements; if the business data characteristic is control (control-related business), then the conversion rule is set to expect a delay of ≤30ms and a reliability of ≥99.9%.

[0114] If scene = urban_jam, the jitter sensitivity is increased; if the scene data feature is urban_jam (urban congestion), then the conversion rule is set to jitter sensitivity ≥ 0.8 (high sensitivity).

[0115] If scene = tunnel, reliability and tolerance for weak coverage are improved; if the scene data feature is tunnel, the transformation rule is set to expect reliability ≥ 99.5% and tolerance for weak coverage ≥ 80%.

[0116] If scene = highway → switch stability weight is increased; if the scene data feature is highway (high-speed scene), the conversion rule sets the switch stability requirement to ≥99%.

[0117] IFtype=video → High bandwidth weight, high jitter sensitivity; if the business data characteristic is video (video-related business), then the conversion rule is set to expect bandwidth ≥ 50Mbps and jitter sensitivity ≥ 0.9.

[0118] IFtype=OTA → Latency requirements are reduced and interruption tolerance is increased; if the business data characteristics are OTA (file or OTA service), the conversion rule is set to expect latency ≤ 500ms and interruption tolerance ≥ 0.7.

[0119] Through the above transformation rules, the MCU transforms the four types of key data into corresponding quantitative indicators one by one. Each quantitative indicator has a clear numerical range or level standard, and the indicator dimension is consistent with the dimension of the subsequent prediction performance vector, laying the foundation for accurate comparison in the future.

[0120] Step S24: Integrate the multiple quantitative indicators to form the expected performance vector.

[0121] After the MCU completes the transformation of key data into quantitative indicators, it integrates all quantitative indicators according to a preset fixed-dimensional order to form the expected performance vector. The integration process follows the principles of unified dimensions and fixed order to ensure that the structure of the expected performance vector completely matches the predicted performance vector, so as to facilitate subsequent dimension-by-dimensional comparison. The quantitative indicators cover expected latency (low latency or ultra-low latency), expected reliability level (high or very high), expected bandwidth, jitter sensitivity, handover stability requirements (dedicated to high-speed scenarios), load tolerance (dedicated to congestion scenarios), and weak coverage expected tolerance (dedicated to tunnel and mountainous scenarios), etc. Each dimension of the quantitative indicator directly corresponds to the minimum transmission performance requirements of the vehicle service in the current scenario.

[0122] Desired performance vector: b_j^{desired}(t) = [desired latency, desired reliability, desired bandwidth, jitter sensitivity, handover stability requirements, load tolerance, weak coverage expected tolerance].

[0123] This application provides an example of an integrated expected performance vector: If the current scenario is high-speed cruising and the service type is control command transmission, the integrated expected performance vector of the MCU is b_j^{desired}(t) = [expected latency ≤ 25ms, expected reliability ≥ 99.9%, expected bandwidth ≥ 1Mbps, jitter sensitivity ≥ 0.8, handover stability requirement ≥ 99.5%, load tolerance ≥ 0.6, weak coverage expected tolerance ≥ 0.7]. The expected performance vector comprehensively defines the minimum transmission performance standard required for the normal operation of vehicle services in the current scenario, providing a clear benchmark threshold for accurate comparison with the predicted performance vectors of various protocols and selection of feasible protocols.

[0124] As an optional implementation, in step 203, by comparing the expected performance vector with the predicted performance vector of each protocol, protocols that do not meet the minimum transmission performance under the current driving scenario are eliminated, and the remaining feasible protocols include the following.

[0125] Step S31: Determine hard constraints based on the expected performance vector, wherein the hard constraints are used to indicate the minimum transmission performance indicators required for the normal operation of the current vehicular service.

[0126] Before selecting a protocol, the MCU first extracts hard constraints based on the minimum transmission performance requirements in the expected performance vector. These hard constraints represent the baseline standard for the normal operation of in-vehicle services. Any candidate protocol that fails to meet any one of these constraints will be directly eliminated, ensuring the fundamental reliability of subsequent protocol selection. The expected performance vector clearly defines the minimum requirements for core network indicators such as latency, reliability, bandwidth, and jitter.

[0127] The determination of hard constraints follows the formula P_feasible={p|Perf_p(t) satisfies the minimum business constraint b_desired_min}, where P_feasible represents the set of feasible protocols formed by the final screening; p represents any protocol; Perf_p(t) represents the predictive performance vector of protocol p at the current time t; and b_desired_min represents the minimum acceptable business index, i.e. the quantitative standard of hard constraints.

[0128] Specifically, the MCU pre-sets differentiated hard constraints for different types of in-vehicle services and driving scenarios to ensure the adaptability and relevance of the constraints. Typical hard constraints include, but are not limited to, the following.

[0129] The hard constraint for control-related services (such as vehicle control command transmission) is that the prediction latency must be less than 30ms to avoid security risks caused by command delays.

[0130] The hard constraint for video streaming services (such as high-definition video uploads) is that the predicted throughput must be higher than the service requirement threshold (e.g., >50Mbps) to ensure smooth video transmission.

[0131] The hard constraint in tunnel or weak coverage scenarios is that the protocol must have fast packet recovery capability or predict a packet loss rate of less than 5% to meet the transmission stability requirements in weak network environments.

[0132] Step S32: Compare the predicted performance vector of each protocol with the hard constraints one by one.

[0133] For all candidate protocols, the MCU initiates a process of comparing the predicted performance vector with the hard constraints one by one. The comparison process follows the principle of full-dimensional verification and no omission matching. The MCU performs point-to-point verification between the Perf_p(t) of each candidate protocol and the corresponding index in b_desired_min to ensure that each hard constraint is verified.

[0134] In this application, the core logic of the comparison is to verify whether the future transmission capabilities of the candidate protocols fully cover the minimum business requirements. During the comparison process, the MCU will record the verification results of each protocol. If a certain dimension fails to meet the standard, the protocol will be marked as infeasible immediately, without the need to continue verification of subsequent dimensions, thus improving the screening efficiency.

[0135] For example, for control-related services, the MCU first compares the predicted latency of a certain protocol (such as 60ms for TCP and 25ms for QUIC) with the hard constraint latency of <30ms; then it verifies whether the predicted throughput meets the minimum requirements; and finally confirms whether the protocol has the high reliability constraints required for vehicle control services.

[0136] Step S33: Select a protocol from the protocols in which all indices of the predicted performance vector satisfy the hard constraint conditions as a feasible protocol.

[0137] Based on the comparison results, the MCU includes candidate protocols that meet the hard constraints in all dimensions of the predicted performance vector into the feasible protocol set P_feasible. If any metric of a candidate protocol fails to meet the requirement of b_desired_min, the MCU will directly exclude it from the subsequent selection process, following a veto principle. This screening method fundamentally avoids the risk of abnormal service transmission due to insufficient performance in a single dimension, ensuring that every protocol in the feasible protocol set has the basic capability to guarantee the normal operation of the current service.

[0138] For example, if the predicted latency of protocol p is lower than the maximum allowable latency of the service, the throughput is higher than the minimum service requirement, and other strong service constraints (such as fast packet recovery capability) are met, then the protocol is added to the feasible protocol set P_feasible.

[0139] In this application, the expected performance vector is compared with the predicted performance vector of each protocol dimension by dimension to determine the feasible protocol. This ensures that each transmission indicator of the feasible protocol meets the minimum hard constraints of the current scenario, thus avoiding security risks such as service interruption and instruction delay caused by the failure of a single indicator. It also efficiently eliminates protocols that are completely unsuitable, thus obtaining feasible protocols that are suitable for driving scenarios and meet the minimum transmission requirements.

[0140] As an optional implementation, after obtaining the retained feasible agreement, the method further includes: Step 301: If multiple feasible protocols are retained, determine various scoring items for each feasible protocol. These scoring items include a service-protocol difference score, an instability penalty score, and a multidimensional correlation penalty score. The service-protocol difference score indicates the degree of dimension-wise difference between the predicted performance vector and the expected performance vector of the feasible protocol. The instability penalty score indicates the fluctuation risk in transmission performance of the feasible protocol. The multidimensional correlation penalty score indicates the degree of comprehensive deviation of the feasible protocol from the requirements of vehicular services across multiple transmission metrics.

[0141] When the feasible protocol set P_feasible contains multiple protocols, the MCU initiates a multi-dimensional comprehensive scoring process to determine three core scoring items for each feasible protocol: business-protocol difference score, instability penalty score, and multi-dimensional correlation penalty score. These three scoring items comprehensively evaluate the protocol's adaptability from three dimensions: demand matching degree, operational risk, and comprehensive deviation degree.

[0142] 1. Business-Agreement Difference Scoring.

[0143] This scoring item is used to quantify the degree of difference between the predictive performance of a feasible protocol and the target expectation in each dimension. The smaller the difference, the lower the score, and the more closely the protocol fits the business needs.

[0144] The formula for the difference vector is: Δ_p = Perf_p(t) b_desired(t), Δ_p represents the difference vector of protocol p, Perf_p(t) represents the predicted performance vector of protocol p at the current time t, and b_desired(t) represents the target expectation vector. The target expectation vector is different from the minimum requirement of hard constraints and is a performance standard that is more in line with the ideal needs of business.

[0145] The formula for difference scoring is: S1(p) = w ×|Δ_p|, S1(p) represents the business-protocol difference score of protocol p; w |Δ_p| represents the transpose of the weight vector, and the weight allocation is dynamically adjusted based on the business type; |Δ_p| represents the dimension-wise absolute value of the difference vector, ensuring that the difference calculation is not affected by the positive or negative direction, and only reflects the degree of deviation.

[0146] 2. Instability penalty score.

[0147] This scoring criterion is used to assess the risk of performance fluctuations in feasible protocols, avoiding the selection of protocols with drastic performance fluctuations that could lead to unstable communication quality. The more unstable the protocol, the greater the penalty for instability.

[0148] The formula for stability penalty score is: S2(p) = α × Var(Perf_p), where S2(p) represents the instability penalty score of protocol p; α represents the instability penalty weight; and Var(Perf_p) represents the variance of the predicted performance vector of protocol p. The larger the variance, the more severe the performance fluctuation, and the higher the penalty score.

[0149] 3. Multidimensional correlation penalty score.

[0150] This scoring criterion is based on Mahalanobis distance and comprehensively measures the deviation correlation between the agreement and business needs from multiple dimensions, avoiding situations where a single dimension meets the standard but the overall adaptability is poor.

[0151] The formula for the multidimensional correlation penalty score is: S3(p) = β × √(Δ_p) ×Σ - ¹×Δ_p), S3(p) represents the multidimensional relevance penalty score of protocol p, β represents the weight of the penalty term, and Δ_p Σ represents the transpose of the difference vector; -¹ represents the inverse of the covariance matrix of performance differences, used to eliminate the influence of correlation between indicators and more accurately reflect the overall deviation. The higher the multidimensional correlation penalty score, the more significant the overall deviation of the protocol from business requirements in terms of multidimensional indicators.

[0152] Step 302: Perform a weighted summation of the various scoring items to obtain the preliminary comprehensive utility of the feasible protocol, wherein the preliminary comprehensive utility indicates the degree of matching between the feasible protocol and the vehicle service requirements, as well as the degree of operational risk.

[0153] The MCU performs a weighted summation operation on the three categories of scoring items for each feasible protocol to obtain the preliminary comprehensive utility of the feasible protocol.

[0154] The formula for preliminary comprehensive utility is: U_p = (S1(p)+S2(p)+S3(p)), where U_p represents the initial comprehensive utility of protocol p; S1(p) is the business-protocol difference score, S2(p) is the instability penalty score, and S3(p) is the multidimensional correlation penalty score; the negative sign indicates that the logic of lower scores being better is transformed into that of higher utility being better.

[0155] The value of the preliminary comprehensive utility U_p directly reflects the comprehensive adaptability of the protocol. The larger the value, the higher the degree of matching between the protocol and the expected business goals, the lower the risk of performance fluctuations, the smaller the comprehensive deviation of multi-dimensional indicators, and the more it meets the business needs under the current driving scenario.

[0156] Step 303: Adjust the preliminary comprehensive utility based on the protocol switching cost of switching from the current protocol to the feasible protocol to obtain the adjusted final comprehensive utility.

[0157] Based on the initial comprehensive utility, the MCU introduces protocol switching costs for secondary adjustments to avoid communication interruptions or delays caused by excessive switching overhead, ensuring that protocol selection balances performance and smooth switching. Switching costs mainly include various overheads for switching from the current protocol p_old to the feasible protocol p, such as connection reconstruction latency (e.g., TCP three-way handshake time), session state transition overhead, and encryption context synchronization time. These overheads are calculated using a preset cost quantification model C_switch(·).

[0158] Adjusted final overall utility formula: _p=U_p λ×C_switch(p_old→p), _p represents the final overall utility of protocol p; U_p represents the initial overall utility; λ represents the switching cost weight, which is a preset positive number; C_switch(p_old→p) represents the switching cost from the current protocol p_old to the feasible protocol p, and the larger the switching cost, the higher the switching cost.

[0159] In this application, the core logic of adjusting the initial overall utility is that the performance gains offset the switching costs. If the initial overall utility of a feasible protocol is significantly higher than that of the current protocol, it may still be the optimal choice even if the switching costs are high. If the advantage of the initial overall utility is weak, the high switching costs will lead to a decrease in its final overall utility, or even lower than that of the current protocol, thereby avoiding unnecessary switching.

[0160] Step 304: Select the protocol with the highest overall utility from the final overall utility as the optimal protocol.

[0161] After the MCU completes the final comprehensive utility calculation for all feasible protocols, it initiates the optimal protocol selection process. The core objective is to maximize the final comprehensive utility, using the formula p*=argmax_p. _p determines the optimal protocol, where p* represents the final selected optimal protocol; argmax_p represents the final overall utility. Candidate protocol p that reaches the maximum value of _p.

[0162] During the screening process, if the number of feasible protocols is small, such as 3, the MCU directly enumerates all protocols. The protocol corresponding to the maximum value of _p is selected. If there are many feasible protocols, a simple optimization algorithm (such as a greedy algorithm) can be used to quickly filter them to ensure that the decision response time meets the real-time requirements of the vehicle scenario (<20ms). The finally selected optimal protocol not only meets the minimum hard constraint of service transmission, but also performs best in terms of demand matching and performance stability, while taking into account the switching cost, thus achieving the dual goals of excellent performance and smooth switching.

[0163] For example, the feasible protocol set includes two protocols: QUIC and TCP. The final overall utility of QUIC is... _p=0.8, TCP If _p=1.5, then it is determined by argmax_p _p selects QUIC as the optimal protocol; if the feasible protocol set contains multiple protocols, the MCU compares them one by one. The value of _p is used to ultimately lock in the protocol corresponding to the maximum value, ensuring that this protocol is the most adaptable, lowest risk, and most cost-effective choice in the current scenario, providing core assurance for subsequent protocol switching and communication quality stability.

[0164] This application provides three embodiments to explain the solution.

[0165] Example 1: Emergency braking command transmission (high real-time control business scenario).

[0166] The vehicle's front-mounted LiDAR and camera work together to detect a sudden obstacle 50 meters ahead. This triggers a high-real-time control scene recognition, and the onboard ECU generates a highest-priority emergency braking command. The decision-making module simultaneously collects the most recent second of historical network data, including TCP link round-trip latency and jitter timing data. Using a sliding window trend extrapolation method, it predicts that the current TCP link latency will increase to 100-120ms in the future.

[0167] Based on the hard business constraint that end-to-end latency must be less than 30ms, feasible protocols were selected. TCP was eliminated due to excessive predicted latency, while the QUIC protocol, with a predicted latency of 25ms and a variance of only 2ms², met the constraint and was included in the feasible protocol set. Further comprehensive scoring showed that QUIC performed excellently in the business-protocol difference score, with a latency difference of 0ms and a throughput fit of 98%. In terms of instability penalty, the variance weight α was 0.5, and the penalty score was only 1, both of which were better than TCP. Even considering the cost of switching from TCP to QUIC, with a handshake latency discount of 0.3, the final overall utility was still 32% higher.

[0168] During the switchover, the system first freezes the TCP session state, saving sequence number 0x8A2F to shared memory. Then, it activates the pre-built QUIC connection pool in the background, eliminating the need for a three-way handshake. AES and 128 key migration is accelerated via DMA, taking 0.4ms, an 80% improvement in efficiency compared to CPU handling. Finally, the braking command is transmitted via QUIC, with end-to-end latency stabilizing at 25ms, meeting the real-time requirements of emergency control.

[0169] Example 2: In-vehicle high-definition video upload (high-bandwidth media service scenario).

[0170] The vehicle enters the 5G base station coverage area. The cockpit domain controller triggers high-bandwidth video upload scene recognition and simultaneously initiates service requirement analysis. High-definition video resolution is 4K, requiring a minimum throughput of 50Mbps and jitter of less than or equal to 10ms. The decision module collects network status data at 500ms intervals and predicts throughput using simple linear regression. The current TCP link's future throughput is approximately 45Mbps, limited by the congestion control algorithm. Due to its multiplexing characteristics, the QUIC link is predicted to have a throughput of up to 80Mbps with jitter of less than or equal to 5ms.

[0171] Based on the hard constraint of throughput greater than 50Mbps, TCP was excluded due to its failure to meet the standard, making QUIC the only feasible protocol. In the comprehensive evaluation phase, QUIC's service-protocol difference score was only 0.06, specifically reflecting a throughput difference of 30Mbps, a jitter difference of 5ms, and a bandwidth weight of 0.7 in the weight vector. Its instability penalty score was 0.24, corresponding to a throughput variance of 8Mbps², with α of 0.3. The multidimensional correlation penalty score was 0.1, and the Mahalanobis distance weight β was 0.2, indicating a preliminary comprehensive utility significantly higher than TCP. Even considering the switching cost—0.2 in state synchronization overhead when switching from TCP to QUIC—the final comprehensive utility still leads by 40%.

[0172] During the switchover, the system directly utilizes the pre-built QUIC connection pool in the background, having already completed the TLS handshake. Video stream encoding context, such as frame sequence number and bitrate parameters, is synchronized via shared memory. Unacknowledged video frames continue to be transmitted via TCP, while pending frames seamlessly switch to QUIC. The entire process is smooth and lag-free, with the video uplink rate ultimately stabilizing at 75Mbps and bandwidth utilization reaching 93.75%, meeting the requirements for real-time high-definition video upload.

[0173] Example 3: Adaptive protocol selection in the scenario of continuous urban tunnel groups.

[0174] When the vehicle is approximately 2km away from the continuous tunnel group, the system reads tunnel length, gradient, and weak coverage prediction data from a high-precision map. Combined with GPS positioning, the system identifies the continuous tunnel group scenario, which consists of three sections with a total length of 4.3km. The system constructs a service evaluation matrix according to scenario mapping rules, including tunnel lengths of 1.2km, 0.8km, and 2.3km, a network attenuation prediction probability of 85%, and a control-type service priority of 0.9. It also generates an expected performance vector with a weak coverage tolerance of ≥80%, a jitter sensitivity of ≥0.8, and a reliability of ≥99%. Simultaneously, connection resource pre-configuration is initiated, activating a TCP and QUIC dual-protocol connection pool. TCP maintains basic signaling connections, while QUIC warms up the congestion window with an initial CWND of 32MSS, reserving resources for subsequent handover.

[0175] After the vehicle entered the first tunnel, the real-time network status matrix showed that the available bandwidth dropped from 50Mbps to 15Mbps, the packet loss rate increased to 12%, and jitter reached 25ms. The system compared the predicted performance vectors of each protocol with the expected performance vectors. TCP was eliminated due to its excessive packet loss rate (predicted at 15%). QUIC, with its fast packet recovery capability (predicted at 8% packet loss and 28ms latency), met all the hard constraints and became a feasible protocol. The system then switched to the QUIC-dominated communication mode.

[0176] When a vehicle's speed drops to 20 km / h or below due to congestion caused by an accident ahead in the second tunnel, the system dynamically adjusts the service evaluation matrix. The jitter sensitivity is increased to 0.9, the bandwidth expectation for entertainment services is reduced to 10 Mbps, while reliability remains the highest priority. Based on real-time network data, the bandwidth is further reduced to 8 Mbps, and a second decision is made to enable a parallel TCP and QUIC dual-protocol mode. Control data continues to use QUIC to ensure a low latency of 26 ms, while entertainment data, such as online music, is switched to TCP to avoid excessive retransmission burden on QUIC. The entire process requires no connection rebuilding, the switching latency is less than 5 ms, and the transmission interruption rate within the tunnel is reduced to 1.8%, achieving stable transmission of multiple services in complex weak network scenarios.

[0177] Table 3 shows a comparison between the proposed solution and the traditional solution. It can be seen that the proposed solution reduces the average handover latency, the interruption rate of weak network transmission, and the memory usage of multiple protocols.

[0178] Table 3

[0179] The overall process of this application is as follows: Figure 3 As shown, when the current protocol latency is detected to be high, such as 100ms, the decision engine initiates protocol evaluation. After switching to a feasible protocol through steps 201 to 203, a freeze mechanism is first triggered to save the TCP session state to shared memory to complete context synchronization. Then, the pre-built connection pool in the background is directly activated, and the already connected protocol is obtained from the connection pool, omitting the protocol re-handshake step. At the same time, the AES and 128 key migration is accelerated through DMA, and the data to be sent is switched to be carried by the feasible protocol. Finally, the feasible protocol switching command is issued to achieve latency reduction.

[0180] In this application, some of the multi-source data can be obtained directly from the logs, while some cannot. The sources and acquisition methods of this data are as follows.

[0181] 1. High-precision map slope (map_slope).

[0182] Source: Local HDmap or cloud map API (map tile or road segment attributes).

[0183] Acquisition method: GPS + heading → Project the current location on HDmap → Read road slope metadata.

[0184] 2. Location and length of the tunnel group (tunnel_ahead_len).

[0185] Source: HDmap topological annotations or geographic information database; or visual or radar identification (if the vehicle-mounted camera can identify the tunnel entrance).

[0186] Acquisition method: Query future path labels along the current heading and accumulate tunnel segment lengths.

[0187] 3. Roadside Unit (RSU) coverage or signal prediction.

[0188] Source: Roadside database or operator interface; or historical heat map measurements.

[0189] Acquisition method: online query or local cache overlay heatmap.

[0190] 4. Road congestion or density.

[0191] Source: Cloud-based traffic services, fleet data, or vehicle sensors (distance, radar).

[0192] Acquisition method: API query or V2X broadcast.

[0193] 5. Business-realized QoE (user experience metrics such as visual clarity).

[0194] Obtain: Application-side reports (such as video encoder PSNR) or end-to-end probes.

[0195] 6. If HDmap cannot be accessed (offline).

[0196] Historical trajectories and the vehicle's sensors are used to attempt online identification (e.g., using cameras and IMU feature detection at tunnel entrances).

[0197] Table 4 shows the reporting content and methods for data from each module in the vehicle.

[0198] Table 4

[0199] This application also provides an adaptive switching device for vehicle protocols, such as... Figure 4 As shown, the device includes: The acquisition module 401 is used to acquire real-time multi-source data during vehicle driving, wherein the multi-source data is used to indicate the current driving scenario; The construction module 402 is used to construct an expected performance vector and a predicted performance vector for each protocol based on the multi-source data. The expected performance vector is used to indicate the minimum transmission performance required for the normal operation of the vehicle service under the current driving scenario, and the predicted performance vector is used to indicate the network transmission performance of the corresponding protocol in the future within a preset time period. The switching module 403 is used to compare the expected performance vector with the predicted performance vector of each protocol, eliminate protocols that do not meet the minimum transmission performance under the current driving scenario, obtain the remaining feasible protocols, and switch from the current protocol to the feasible protocols.

[0200] Optionally, the multi-source data includes network status data, and the construction module 402 is used for: The network indicators in the network status data are combined in a fixed field order to form the network status matrix, which is used to present real-time network transmission characteristics. Based on the network state matrix, historical network data of the protocol within the most recent fixed time window is collected; The basic data indicators in the historical network data are calculated using a set prediction algorithm to obtain multiple basic prediction indicators. Based on the signal strength time-series data and retransmission count time-series data in the historical network data, transmission stability is predicted to obtain a stability prediction index. By integrating the multiple basic prediction metrics and the stability prediction metrics, the prediction performance vector of the protocol is constructed.

[0201] Optionally, building module 402 is used for: A business evaluation matrix is ​​constructed based on at least two types of data from the multi-source data, wherein the business evaluation matrix is ​​used to evaluate in-vehicle business requirements; Multiple key data are extracted from the business evaluation matrix, including business data characteristics, scenario data characteristics, network data characteristics, and business degradation capability data. The business degradation capability is used to indicate whether the current in-vehicle service supports suspension, bitrate reduction, or interruption. The key data is transformed into quantitative indicators by executing preset conversion rules through a business mapping model. The conversion rules are obtained based on the joint modeling results of in-vehicle services and driving scenarios. The desired performance vector is formed by integrating multiple quantitative indicators.

[0202] Optionally, the multi-source data includes vehicle driving data, vehicle positioning data, map data, traffic data, and network status data, and the construction module 402 is specifically used for: The current driving scenario is determined based on at least two types of data from the multi-source data. The business parameter type corresponding to the current driving scenario is determined according to the preset mapping relationship between driving scenarios and parameter types; Read real-time parameter values ​​that conform to the business parameter type from the multi-source data, and then concatenate the real-time parameter values ​​according to a preset structure to form the business evaluation matrix.

[0203] Optionally, the switching module 403 is used for: Hard constraints are determined based on the expected performance vector, wherein the hard constraints are used to indicate the minimum transmission performance indicators required for the normal operation of the current vehicular service. The predicted performance vector of each protocol is compared with the hard constraints one by one; The protocol from which all indices of the predicted performance vector satisfy the hard constraint is selected as a feasible protocol.

[0204] Optionally, the device is also used for: If multiple feasible protocols are retained, then multiple scoring items are determined for each of the feasible protocols; The various scoring items include service-protocol difference score, instability penalty score, and multidimensional correlation penalty score. The service-protocol difference score is used to indicate the degree of dimension-wise difference between the predicted performance vector and the expected performance vector of the feasible protocol. The instability penalty score is used to indicate the fluctuation risk of the feasible protocol in transmission performance. The multidimensional correlation penalty score is used to indicate the degree of comprehensive deviation of the feasible protocol from the requirements of vehicle services in multiple transmission indicators. The weighted summation of the various scoring items yields the preliminary comprehensive utility of the feasible protocol, wherein the preliminary comprehensive utility indicates the degree of matching between the feasible protocol and the vehicle service requirements, as well as the degree of operational risk. Based on the protocol switching cost of switching from the current protocol to the feasible protocol, the preliminary comprehensive utility is adjusted to obtain the adjusted final comprehensive utility; The protocol with the highest overall utility from the final overall utility is selected as the optimal protocol.

[0205] Optionally, the device is also used for: Determine the variance of the predicted performance vector of the feasible protocol; The instability penalty of the feasible protocol is determined based on the preset instability penalty weight and the variance, wherein the instability penalty is inversely related to the protocol stability.

[0206] like Figure 5 As shown, this application provides an electronic device including a processor 501, a communication interface 502, a memory 503, and a communication bus 504, wherein the processor 501, the communication interface 502, and the memory 503 communicate with each other through the communication bus 504.

[0207] Memory 503 is used to store computer programs.

[0208] In one embodiment of this application, the processor 501, when executing the program stored in the memory 503, implements the adaptive switching method of the vehicle protocol provided in any of the foregoing method embodiments.

[0209] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the adaptive switching method for the vehicle protocol as provided in any of the foregoing method embodiments.

[0210] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0211] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0212] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also include the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a particular order described or illustrated unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.

[0213] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. An adaptive switching method for vehicle protocols, characterized in that, The method includes: Acquire real-time multi-source data during vehicle operation, wherein the multi-source data is used to indicate the current driving scenario; Based on the multi-source data, an expected performance vector and a predicted performance vector for each protocol are constructed respectively. The expected performance vector is used to indicate the minimum transmission performance required for the normal operation of vehicle services in the current driving scenario, and the predicted performance vector is used to indicate the network transmission performance of the corresponding protocol in the future within a preset time period. By comparing the expected performance vector with the predicted performance vector of each protocol, protocols that do not meet the minimum transmission performance requirements under the current driving scenario are eliminated, and the remaining feasible protocols are obtained. The current protocol is then switched to the feasible protocol.

2. The method according to claim 1, characterized in that, The multi-source data includes network state data, and the construction of a prediction performance vector for each protocol based on the multi-source data includes: The network indicators in the network status data are combined in a fixed field order to form the network status matrix, which is used to present real-time network transmission characteristics. Based on the network state matrix, historical network data of the protocol within the most recent fixed time window is collected; The basic data indicators in the historical network data are calculated using a set prediction algorithm to obtain multiple basic prediction indicators. Based on the signal strength time-series data and retransmission count time-series data in the historical network data, transmission stability is predicted to obtain a stability prediction index. By integrating the multiple basic prediction metrics and the stability prediction metrics, the prediction performance vector of the protocol is constructed.

3. The method according to claim 1, characterized in that, Constructing the desired performance vector based on the multi-source data includes: A business evaluation matrix is ​​constructed based on at least two types of data from the multi-source data, wherein the business evaluation matrix is ​​used to evaluate in-vehicle business requirements; Multiple key data are extracted from the business evaluation matrix, including business data characteristics, scenario data characteristics, network data characteristics, and business degradation capability data. The business degradation capability is used to indicate whether the current in-vehicle service supports suspension, bitrate reduction, or interruption. The key data is transformed into quantitative indicators by executing preset conversion rules through a business mapping model. The conversion rules are obtained based on the joint modeling results of in-vehicle services and driving scenarios. The desired performance vector is formed by integrating multiple quantitative indicators.

4. The method according to claim 3, characterized in that, The multi-source data includes vehicle driving data, vehicle positioning data, map data, traffic data, and network status data. The business evaluation matrix is ​​constructed based on at least two types of data from the multi-source data, including: The current driving scenario is determined based on at least two types of data from the multi-source data. The business parameter type corresponding to the current driving scenario is determined according to the preset mapping relationship between driving scenarios and parameter types; Read real-time parameter values ​​that conform to the business parameter type from the multi-source data, and then concatenate the real-time parameter values ​​according to a preset structure to form the business evaluation matrix.

5. The method according to claim 1, characterized in that, By comparing the expected performance vector with the predicted performance vector of each protocol, protocols that do not meet the minimum transmission performance requirements for the current driving scenario are eliminated, resulting in the following remaining feasible protocols: Hard constraints are determined based on the expected performance vector, wherein the hard constraints are used to indicate the minimum transmission performance indicators required for the normal operation of the current vehicular service. The predicted performance vector of each protocol is compared with the hard constraints one by one; The protocol from which all indices of the predicted performance vector satisfy the hard constraint is selected as a feasible protocol.

6. The method according to claim 1, characterized in that, After obtaining the retained feasible protocol, the method further includes: If multiple feasible protocols are retained, then multiple scoring items are determined for each of the feasible protocols; The various scoring items include service-protocol difference score, instability penalty score, and multidimensional correlation penalty score. The service-protocol difference score is used to indicate the degree of dimension-wise difference between the predicted performance vector and the expected performance vector of the feasible protocol. The instability penalty score is used to indicate the fluctuation risk of the feasible protocol in transmission performance. The multidimensional correlation penalty score is used to indicate the degree of comprehensive deviation of the feasible protocol from the requirements of vehicle services in multiple transmission indicators. The weighted summation of the various scoring items yields the preliminary comprehensive utility of the feasible protocol, wherein the preliminary comprehensive utility indicates the degree of matching between the feasible protocol and the vehicle service requirements, as well as the degree of operational risk. Based on the protocol switching cost of switching from the current protocol to the feasible protocol, the preliminary comprehensive utility is adjusted to obtain the adjusted final comprehensive utility; The protocol with the highest overall utility from the final overall utility is selected as the optimal protocol.

7. The method according to claim 6, characterized in that, Determining the instability penalty of the feasible protocol includes: Determine the variance of the predicted performance vector of the feasible protocol; The instability penalty of the feasible protocol is determined based on the preset instability penalty weight and the variance, wherein the instability penalty is inversely related to the protocol stability.

8. An adaptive switching device for vehicle protocols, characterized in that, The device includes: The acquisition module is used to acquire real-time multi-source data during vehicle operation, wherein the multi-source data is used to indicate the current driving scenario; The construction module is used to construct the expected performance vector and the predicted performance vector for each protocol based on the multi-source data. The expected performance vector is used to indicate the minimum transmission performance required for the normal operation of the vehicle service under the current driving scenario, and the predicted performance vector is used to indicate the network transmission performance of the corresponding protocol in the future preset time period. The switching module is used to compare the expected performance vector with the predicted performance vector of each protocol, eliminate protocols that do not meet the minimum transmission performance under the current driving scenario, obtain the remaining feasible protocols, and switch from the current protocol to the feasible protocol.

9. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1 to 7.

Images