An adaptive hybrid rate CAN XL communication method, apparatus and electronic device

Abstract

The present disclosure provides a kind of adaptive hybrid rate CAN XL communication method, device and electronic equipment, can be combined with the future load of communication flow characteristics and be predicted, and accordingly dynamically adjust protocol selection strategy, bit rate switching strategy and message forwarding strategy, to improve bandwidth utilization, reduce communication delay and delay jitter, reduce message loss, and improve the adaptive capacity and overall communication performance of vehicle-mounted network under complex business scenarios.

Description

Technical Field

[0001] This disclosure relates to the field of intelligent network control technology, and more specifically, to an adaptive hybrid rate CAN XL communication method, apparatus, and electronic device. Background Technology

[0002] With the rapid development of intelligent vehicles, domain controllers, driver assistance devices, and various types of in-vehicle electronic control units, the amount of data that needs to be transmitted in in-vehicle networks continues to increase, and the message types are also showing characteristics of real-time control messages, periodic status messages, sudden event messages, and large data payload messages coexisting. To adapt to different data transmission needs, existing in-vehicle networks typically adopt a hybrid protocol architecture including CAN 2.0, CAN FD, and CAN XL, and use gateways to realize protocol conversion and data forwarding between different protocol networks.

[0003] In existing technologies, most CAN XL communication devices employ static configuration for network management. Specifically, existing devices typically pre-set the bit rate switching point during the design phase, setting a fixed rate for the arbitration segment and a fixed high rate for the data segment, and maintaining this bit rate configuration during device operation. Simultaneously, protocol selection in existing devices is usually based on a static mapping table, where each message ID is pre-bound to a specific protocol among CAN 2.0, CAN FD, or CAN XL. The electronic control unit determines the protocol type by looking up the table based on the message ID during transmission, rather than dynamically adjusting based on the network status during runtime. Furthermore, existing gateways often only perform simple data extraction, re-encapsulation, and forwarding processes when performing cross-protocol forwarding.

[0004] However, the aforementioned existing technologies have at least the following problems: they are difficult to adapt to dynamically changing network traffic loads, which can easily lead to low bandwidth utilization; they cannot flexibly select more suitable transmission protocols based on real-time network status, message size, and service priority, resulting in wasted transmission overhead; and they are difficult to optimize protocol selection and bit rate configuration in a timely manner, leading to insufficient overall network real-time performance, stability, and adaptability. Summary of the Invention

[0005] This disclosure provides at least one adaptive hybrid rate CAN XL communication method, apparatus, and electronic device, which can predict future load by combining communication traffic characteristics and dynamically adjust protocol selection strategy, bit rate switching strategy, and message forwarding strategy accordingly, thereby improving bandwidth utilization, reducing communication latency and latency jitter, reducing message loss, and enhancing the adaptive capability and overall communication performance of the vehicle network in complex business scenarios.

[0006] This disclosure provides an adaptive hybrid rate CAN XL communication method, including: Collect communication traffic characteristic parameters of the vehicle network; Based on the communication traffic characteristic parameters, determine the traffic prediction results and message category results within the target time period; Based on the traffic prediction results and the message category results, a target communication protocol is selected; Based on the traffic prediction results, the bit rate configuration corresponding to the target communication protocol is adaptively adjusted to obtain the target bit rate configuration; Based on the target communication protocol and the target bit rate, the message to be sent is forwarded. Collect performance feedback information corresponding to forwarding and processing, and optimize and adjust subsequent protocol selection and bit rate configuration based on the performance feedback information.

[0007] In one optional implementation, the communication traffic characteristic parameters include at least one of message arrival rate, message size distribution, message identifier distribution, bus load rate, message interval time, error rate, retransmission rate, and priority distribution. Collecting communication traffic characteristic parameters in the vehicular network specifically includes: Traffic data is collected in real time from CAN 2.0 network, CAN FD network and CAN XL network respectively; The traffic data is statistically analyzed according to a preset time window to form a traffic feature set corresponding to each time window; The preset time window includes a prediction window for short-term traffic prediction and a training window for model training and updates.

[0008] In one optional implementation, determining the traffic prediction result and message category result within the target time period based on the communication traffic characteristic parameters specifically includes: Feature extraction is performed on the communication traffic characteristic parameters to obtain a feature vector containing time-domain features, frequency-domain features, and statistical features; The feature vector is input into the AI ​​prediction model to output future load rate prediction results, traffic pattern recognition results, and message category results; The frequency domain features include periodic frequency components and burst flow characteristics obtained through spectrum analysis; The statistical characteristics include at least one of the following: message size distribution entropy, priority distribution coefficient, and message interval time variation coefficient.

[0009] In one optional implementation, the AI ​​prediction model includes at least a time-series prediction model for predicting future load rates, a clustering model for identifying traffic patterns, a classification model for categorizing messages, and a reinforcement learning model for optimizing bit rate configuration and protocol switching actions. The AI ​​prediction model also includes a model integrator, which is used to fuse the outputs of multiple models to generate protocol recommendation results and bit rate recommendation results.

[0010] In one optional implementation, a target communication protocol is selected based on the traffic prediction result and the message category result, specifically including: When the message data length exceeds the first threshold, the CAN XL protocol is selected; When the message data length is no greater than the first threshold but greater than the second threshold, the CAN FD protocol is selected; When the message data length is no greater than the second threshold, the CAN FD protocol or the CAN 2.0 protocol is selected based on the predicted load and message priority. Specifically, when the predicted load is higher than the load threshold and the message to be sent is a delay-sensitive message, the CAN FD protocol is selected. The load threshold is a dynamic threshold, which is adaptively adjusted according to historical performance indicators. The historical performance indicators include at least one of the following: average latency, bandwidth utilization, and message drop rate. When the predicted load is not higher than the load threshold and the data length of the message to be sent does not exceed the preset short message threshold, the CAN 2.0 protocol is selected.

[0011] In one optional implementation, the bit rate configuration corresponding to the target communication protocol is adaptively adjusted based on the traffic prediction result to obtain the target bit rate configuration, specifically including: Determine the arbitration segment bit rate, data segment bit rate, and bit rate switching point based on the predicted load; And increase the data segment bit rate when the current delay is higher than the target delay, or decrease the data segment bit rate when the current delay is lower than the target delay; The bit rate switching point is adjusted based on the prediction accuracy; when the prediction accuracy is higher than the first accuracy threshold, the bit rate switching point is moved forward; when the prediction accuracy is lower than the second accuracy threshold, the bit rate switching point is moved backward.

[0012] In one optional implementation, the forwarding process for the message to be sent is configured based on the target communication protocol and the target bit rate, specifically including: The message to be sent is added to a message queue corresponding to the message priority, wherein the message queue is a multi-priority queue, and the preset scheduling strategy includes at least one of strict priority scheduling and peer queue round-robin scheduling. The target message is extracted from the message queue according to the preset scheduling strategy; When the source protocol and the target communication protocol are inconsistent, a protocol conversion is performed on the target message; Send the target message after protocol conversion or the target message without protocol conversion according to the target bit rate configuration.

[0013] In one optional implementation, performing protocol conversion on the target message specifically includes: When converting CAN XL messages to CAN FD messages, data exceeding the payload of a single CAN FD frame is fragmented. When converting CAN FD messages to CAN 2.0 messages, the data fields are truncated or segmented. Update the frame header fields according to the target protocol.

[0014] This disclosure also provides an adaptive hybrid rate CAN XL communication device, comprising: The traffic monitoring module is used to collect communication traffic characteristic parameters in the vehicle network; An AI prediction engine is used to determine the traffic prediction results and message category results within a target time period based on the communication traffic characteristic parameters. A protocol selector is used to select a target communication protocol based on the traffic prediction result and the message category result; A bit rate controller is used to adaptively adjust the bit rate configuration corresponding to the target communication protocol based on the traffic prediction results to obtain the target bit rate configuration; An adaptive forwarding engine is used to configure the forwarding processing of messages to be sent based on the target communication protocol and the target bit rate. The feedback optimization module is used to collect performance feedback information corresponding to forwarding processing, and to optimize and adjust subsequent protocol selection and bit rate configuration based on the performance feedback information.

[0015] This disclosure also provides an electronic device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they perform the steps of the above-described adaptive hybrid rate CAN XL communication method, or any possible implementation of the above-described adaptive hybrid rate CAN XL communication method.

[0016] This disclosure also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the above-described adaptive mixed-rate CAN XL communication method, or any possible implementation thereof.

[0017] This disclosure also provides a computer program product, including a computer program / instructions, which, when executed by a processor, implement the above-described adaptive mixed-rate CAN XL communication method, or the steps in any possible implementation of the above-described adaptive mixed-rate CAN XL communication method.

[0018] The present disclosure provides an adaptive hybrid rate CAN XL communication method, apparatus, and electronic device that can predict future load by combining communication traffic characteristics and dynamically adjust protocol selection strategy, bit rate switching strategy, and message forwarding strategy accordingly. This improves bandwidth utilization, reduces communication latency and latency jitter, reduces message loss, and enhances the adaptive capability and overall communication performance of the vehicle network in complex business scenarios.

[0019] To make the above-mentioned objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings used in the embodiments will be briefly described below. These drawings are incorporated in and constitute a part of this specification. They illustrate embodiments conforming to this disclosure and, together with the specification, serve to explain the technical solutions of this disclosure. It should be understood that the following drawings only show some embodiments of this disclosure and should not be considered as limiting the scope. Those skilled in the art can obtain other related drawings based on these drawings without creative effort.

[0021] Figure 1 A flowchart of an adaptive hybrid rate CAN XL communication method provided by an embodiment of this disclosure is shown; Figure 2 A schematic diagram of an adaptive hybrid rate CAN XL communication device provided in an embodiment of this disclosure is shown; Figure 3 A schematic diagram of an electronic device provided in an embodiment of the present disclosure is shown. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. The components of the embodiments of this disclosure described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this disclosure provided in the accompanying drawings is not intended to limit the scope of the claimed disclosure, but merely represents selected embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without inventive effort are within the scope of protection of this disclosure.

[0023] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0024] In this document, the term "and / or" merely describes a relationship, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. Furthermore, the term "at least one" in this document means any combination of at least two of any one or more elements. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C.

[0025] Research has revealed that most existing CAN XL communication devices employ static configuration for network management. These existing technologies suffer from at least the following problems: they struggle to adapt to dynamically changing network traffic loads, leading to low bandwidth utilization; they cannot flexibly select the most suitable transmission protocol based on real-time network status, message size, and service priority, resulting in wasted transmission overhead; and they cannot optimize protocol selection and bit rate configuration in a timely manner, resulting in insufficient overall network real-time performance, stability, and adaptability.

[0026] Based on the above research, this disclosure provides an adaptive hybrid rate CAN XL communication method, device, and electronic device, which can predict future load by combining communication traffic characteristics and dynamically adjust the protocol selection strategy, bit rate switching strategy, and message forwarding strategy accordingly, thereby improving bandwidth utilization, reducing communication latency and latency jitter, reducing message loss, and enhancing the adaptive capability and overall communication performance of the vehicle network in complex business scenarios.

[0027] To facilitate understanding of this embodiment, a detailed description of the adaptive hybrid-rate CAN XL communication method disclosed in this disclosure is provided first. The execution entity of the adaptive hybrid-rate CAN XL communication method provided in this disclosure is generally a computer device with certain computing capabilities. This computer device may include, for example, a terminal device, a server, or other processing devices. The terminal device may be a user equipment (UE), mobile device, user terminal, terminal, cellular phone, cordless phone, personal digital assistant (PDA), handheld device, computing device, in-vehicle device, wearable device, etc. In some possible implementations, this adaptive hybrid-rate CAN XL communication method can be implemented by the processor calling computer-readable instructions stored in memory.

[0028] See Figure 1 The diagram shows a flowchart of an adaptive hybrid rate CAN XL communication method provided in an embodiment of this disclosure. The method includes steps S101 to S106, wherein: S101. Collect communication traffic characteristic parameters in the vehicle network.

[0029] In its implementation, the AI-based adaptive hybrid-rate CAN XL communication method first collects communication traffic characteristic parameters from the vehicular network to provide basic data input for subsequent traffic prediction, message category identification, protocol selection, and adaptive bit rate adjustment. The collection of these communication traffic characteristic parameters can be performed by a traffic monitoring module connected to the CAN 2.0 network, CAN FD network, and CAN XL network, respectively, for unified monitoring and data aggregation of real-time communication status across different protocol networks.

[0030] Specifically, the communication traffic characteristic parameters may include at least one of the following: message arrival rate, message size distribution, message identifier distribution, bus load rate, message interval time, error rate, retransmission rate, and priority distribution. Each of these parameters is used to describe the current communication status in the vehicular network from different dimensions.

[0031] In one specific implementation, different acquisition methods can be used for different communication traffic characteristic parameters. For message arrival rate, a counter combined with a timer can be used to count the number of received messages within a preset sampling period. For message size distribution, the number distribution of messages in different size ranges can be obtained by counting the data length code (DLC) or the corresponding data field length for each message. For message identifier distribution, message IDs can be recorded and a message ID hash table or frequency statistics table can be established to reflect the frequency of occurrence of different types of messages. For bus load rate, it can be obtained by sampling the bus busy time and idle time and calculating their ratio. For message interval time, the time interval between adjacent messages can be obtained by performing differential operations based on the message timestamp. For error rate, at least one of CRC error, ACK error, format error, or bit error can be counted. For retransmission rate, the number of message retransmissions caused by arbitration failure, transmission error, or acknowledgment failure can be counted. For priority distribution, the proportion of messages of different priority levels can be determined according to the priority bits in the message identifier or a preset priority mapping rule.

[0032] Furthermore, regarding the sampling frequency setting, different acquisition cycles can be configured according to the sensitivity and timeliness requirements of different characteristic parameters. For example, message arrival rate can be statistically analyzed at a 10ms granularity, and bus load rate can be sampled at a 1ms granularity to improve the response speed to load fluctuations; error rate and retransmission rate can be accumulated at a 100ms granularity to avoid excessive fluctuations caused by instantaneous errors; message size distribution, message identifier distribution, message interval time and priority distribution can be updated in real time, refreshing the corresponding statistics when each message arrives.

[0033] It should be understood that the above sampling frequency is only an example. In other implementations, the sampling periods can be adaptively adjusted according to the actual scale of the vehicle network, the processing capacity of the controller, and the real-time requirements of the services.

[0034] To enable the collected communication traffic characteristic parameters to be used for both short-term traffic prediction and model training and updates, this embodiment also allows for windowing of the time dimension. Specifically, the collection time can be divided into a prediction window and a training window. The prediction window is used to characterize the current or future short-term traffic trend on a shorter time scale, while the training window is used to accumulate sample data on a longer time scale and support model fine-tuning or retraining.

[0035] For example, the prediction window length can be set to 100ms for short-term traffic prediction; the training window length can be set to 60s for historical sample accumulation and model training. By mapping raw traffic data to different time windows according to different uses, both the real-time nature of online decision-making and the stability of continuous model optimization can be balanced.

[0036] In some implementations, the traffic monitoring module can merge and statistically analyze the original packet-level data within each prediction window to form a window-level feature set corresponding to the current prediction window; at the same time, it can construct a sample sequence within the training window based on multiple consecutive prediction windows, so that the subsequent AI model can learn the load change pattern of the vehicle network from the perspective of temporal evolution.

[0037] In other words, the feature set output by the prediction window focuses more on characterizing short-term transient load states, while the sample sequence obtained by the aggregation of the training window is more suitable for characterizing periodic patterns, burst patterns, and long-term evolutionary trends.

[0038] To facilitate data interaction between modules, the collected communication traffic characteristic parameters can be organized into a preset data structure for storage in this embodiment. This data structure may include fields such as timestamp, message count, total number of bytes, bus load rate, error count, priority distribution, size distribution, and average message interval.

[0039] Among them, the timestamp is used to mark the sampling time corresponding to the current feature set; the message count and total number of bytes are used to characterize the traffic scale within the current window; the bus load rate is used to characterize the link occupancy level of the current window; the error count is used to characterize the link quality; the priority distribution and size distribution are used to characterize the current traffic composition structure; and the average message interval is used to characterize the message arrival rhythm.

[0040] In practical applications, the step of collecting communication traffic characteristic parameters in the vehicle network is not limited to being completed by a separate hardware module. It can also be implemented by the communication management unit in the gateway controller or domain controller, or by the bus monitoring program deployed in the vehicle operating device. As long as the raw data related to communication traffic can be obtained from CAN 2.0, CAN FD, and CAN XL networks, and further formed into a set of parameters reflecting the network status, this step can be considered to have been achieved.

[0041] Furthermore, the collected results can be directly provided to the subsequent AI prediction engine as input, or they can be written into a cache, circular buffer, or historical traffic database and then read by subsequent modules as needed.

[0042] S102. Determine the traffic prediction results and message category results within the target time period based on the communication traffic characteristic parameters.

[0043] In this embodiment, after collecting communication traffic characteristic parameters in the vehicular network, the traffic prediction results and message category results within the target time period are further determined based on the communication traffic characteristic parameters, providing a decision-making basis for subsequent target communication protocol selection, target bit rate configuration adjustment, and message forwarding scheduling. This step can be executed by an AI prediction engine, which can adopt a multi-model integrated architecture, including at least one or more of the following: a feature extraction module, a traffic prediction model, a traffic pattern recognition model, and a message classification model.

[0044] Specifically, determining the traffic prediction result and message category result within the target time period based on the communication traffic feature parameters may include: extracting features from the communication traffic feature parameters to obtain a feature vector corresponding to the current time or the current prediction window; inputting the feature vector into a traffic prediction model to output the future load rate prediction result within the target time period; inputting the feature vector into a traffic pattern recognition model to identify the pattern category to which the current traffic belongs; and inputting the message-level features into a message classification model to output the message category result corresponding to the message to be sent.

[0045] In one implementation, the feature extraction module extracts time-domain features, frequency-domain features, and statistical features from the raw data collected by the traffic monitoring module. The time-domain features may include at least one of the following: sliding window average load rate, load change rate, message arrival rate, message arrival rate variance, and peak detection results. Specifically, the sliding window average load rate reflects the average resource utilization over a given period; the load change rate reflects the rate of load change between adjacent time points; the message arrival rate and message arrival rate variance reflect the activity level and fluctuation of messages entering the network; and the peak detection results identify whether a traffic surge has occurred within a short period.

[0046] Furthermore, the frequency domain features can be obtained by performing spectral analysis on the communication traffic sequence. For example, a Fast Fourier Transform can be performed on the load rate sequence, message arrival rate sequence, or total byte count sequence in multiple consecutive prediction windows to extract the dominant frequency components and their amplitude information corresponding to the periodic components, so as to identify whether there are stable periodic traffic, repetitive pulse traffic, or sudden change patterns in the network. In some embodiments, the first few dominant frequency components can be selected as frequency domain features and input into the subsequent model.

[0047] In addition, the statistical features may include at least one of the following: message size distribution entropy, priority distribution Gini coefficient, message interval time variation coefficient, and statistics related to the degree of distribution balance. Specifically, the message size distribution entropy characterizes the dispersion of messages of different data lengths within the current window; the priority distribution Gini coefficient characterizes the distribution balance between high-priority and low-priority messages in the overall traffic; and the message interval time variation coefficient characterizes the stability of message arrival intervals.

[0048] In a specific implementation, the aforementioned time-domain features, frequency-domain features, and statistical features can be combined to form the feature vector corresponding to the current moment. The feature vector can be composed of multiple feature components, such as the sliding window average load rate, load change rate, message arrival rate, message arrival rate variance, proportion of messages of each priority level, proportion of messages of each size segment, the first few main frequency components, distribution entropy, Gini coefficient, coefficient of variation, and peak flag, etc.

[0049] It should be understood that the specific number and arrangement of features in the feature vector are not limited and can be adjusted according to the model structure, computing power, and application requirements.

[0050] In terms of traffic prediction, the traffic prediction model can be used to predict the future load rate within a target time period based on the feature vectors of the current moment and several historical time steps. In one embodiment, the traffic prediction model can be a time-series prediction model, using a sequence of feature vectors corresponding to multiple consecutive prediction windows as input, and outputting the load rate prediction result for the next prediction window or several subsequent prediction windows. The load rate prediction result can be a single value or a sequence containing multiple predicted values ​​for future moments. The duration between the current moment and the predicted moment can be defined as the target time period, such as 100ms, 200ms, or a longer short-term prediction interval. In this way, the system can anticipate potential high load, low load, or sudden load changes before actual traffic changes occur, thereby preparing for protocol switching and rate adjustment actions in advance.

[0051] In one specific implementation, the traffic prediction model can employ a Long Short-Term Memory (LSTM) network structure. This type of model can receive a sequence of feature vectors arranged chronologically and learn the correlation between short-term fluctuations and long-term dependencies. By receiving feature vectors from multiple time steps at the input layer, extracting temporal evolution relationships in intermediate network layers, and generating future load rate predictions at the output layer, it can better adapt to mixed traffic scenarios in vehicular networks that exhibit both periodicity and burstiness. Of course, in other implementations, gated recurrent unit networks, temporal convolutional networks, Transformer temporal models, or other machine learning models suitable for sequence prediction can also be used to predict future load rates.

[0052] In addition to predicting future load rates, the AI ​​prediction engine can also perform traffic pattern recognition. Specifically, the feature vectors corresponding to the current window or multiple consecutive windows can be input into the traffic pattern recognition model to identify whether the current traffic belongs to one or more of the following patterns: periodic low load pattern, periodic high load pattern, burst traffic pattern, mixed traffic pattern, or abnormal traffic pattern. The traffic pattern recognition model can be implemented using unsupervised clustering algorithms. For example, preliminary clustering can be performed on the feature vectors first, and then anomaly identification can be performed on outlier samples to obtain more granular pattern labels. By identifying the current traffic pattern, more scenario-aware auxiliary information can be provided for subsequent selection of target communication protocols and configuration of target bit rates. For example, when the current traffic pattern is identified as burst traffic, the ability to handle burst messages with high load can be improved in subsequent decisions; when the current traffic pattern is identified as periodic low load, priority can be given to reducing communication resource consumption.

[0053] Regarding message category determination, this embodiment can not only generate overall network-level traffic prediction results based on window-level traffic characteristics, but also perform category identification for messages to be sent. Specifically, based on message-level characteristics such as message size, message priority, sending frequency, and time sensitivity flags, a message classification model can be used to classify each message to be sent to obtain the corresponding message category results. The message category results can be used to characterize the differences in message attributes in terms of business, for example, messages can be divided into real-time critical messages, non-real-time high-volume messages, and non-real-time low-volume messages.

[0054] In one specific implementation, the message classification model can employ a supervised learning classifier, such as a random forest classifier. The system first constructs a training set based on historical communication samples, using message size, priority, sending frequency, and time sensitivity as input features, and manually labeled or rule-defined message categories as labels to train the classification model. During online runtime, the relevant features of the message to be sent are input into the trained classification model to output the corresponding category label.

[0055] Furthermore, the traffic prediction results and message category results can be output separately to subsequent modules, or they can be fused within the AI ​​prediction engine by the model integrator. The model integrator can combine future load rate predictions, traffic pattern labels, and message category labels to generate a unified decision reference result. For example, the model integrator can determine whether the network is likely to enter a high-load state within a target time period based on future load rate predictions, determine whether the current traffic is sudden or abnormal based on traffic pattern labels, and then combine this with message category labels to determine whether the message to be sent is a real-time critical message, thus forming a more complete state description.

[0056] In some implementations, the traffic prediction results for the target time period can be represented as a predicted load rate range, a predicted load level, or a load rate sequence corresponding to multiple future time points. For example, future load rates can be divided into three levels: low load, medium load, and high load, or specific load rate values ​​corresponding to one or more future prediction windows can be given. Correspondingly, the message category results can be represented as discrete category labels or as probability distributions corresponding to each category. When the aforementioned results are output in probabilistic form, subsequent modules can determine the dominant category based on the probability magnitude, or retain uncertainty information for implementing more conservative or more aggressive strategy configurations.

[0057] To improve the model's adaptability during long-term operation, in this embodiment, the step of determining the traffic prediction results and message category results within the target time period based on the communication traffic characteristic parameters can also be linked to the model update process.

[0058] Specifically, the system can continuously record prediction results, actual load results, and actual message processing results during operation, and perform fine-tuning updates on the traffic prediction model and message classification model based on new data within the recent training window; incremental learning or retraining can also be triggered when a decrease in prediction accuracy is detected or a new traffic pattern appears.

[0059] S103. Select the target communication protocol based on the traffic prediction result and the message category result.

[0060] In practice, after determining the traffic prediction results and message category results within the target time period, a target communication protocol is selected based on the traffic prediction results and message category results, so that the message to be sent can achieve a more compatible protocol match among the three protocols: CAN 2.0, CAN FD, and CAN XL.

[0061] This step can be performed by a protocol selector, which is connected to an AI prediction engine to receive future load rate prediction results, traffic pattern recognition results, and message category results. It then combines these with attributes such as the data length, priority, and time sensitivity of the message to be sent to output the target communication protocol corresponding to the current message.

[0062] Specifically, the step of selecting a target communication protocol based on the traffic prediction result and the message category result may include: obtaining the data length information of the message to be sent; determining whether the data length of the message to be sent is greater than a first threshold; when the data length is greater than the first threshold, selecting CAN XL as the target communication protocol; when the data length is not greater than the first threshold, further selecting a target communication protocol between CAN FD and CAN 2.0 by combining the traffic prediction result and the message category result.

[0063] In one implementation, the first threshold can be set to 64 bytes. That is, when the data length of the message to be sent is greater than 64 bytes but does not exceed the maximum payload range that the CAN XL protocol can carry, the CAN XL protocol can be preferentially selected as the target communication protocol to fully utilize CAN XL's capacity to carry large data payload messages. Correspondingly, when the message length is no greater than 64 bytes, the choice between CAN FD and CAN 2.0 can be further made based on the load status, service real-time requirements, and message type.

[0064] Furthermore, when the data length of the message to be sent is not greater than the first threshold, a more granular target communication protocol can be determined by combining the traffic prediction result and the message category result. Specifically, when the predicted load is higher than the load threshold and the message to be sent is a delay-sensitive message, CAN FD can be selected as the target communication protocol; when the predicted load is not higher than the load threshold and the data length of the message to be sent is short, CAN 2.0 can be selected as the target communication protocol.

[0065] In other words, for messages whose length does not meet the priority application conditions of CAN XL, CAN FD or CAN 2.0 will not be directly and fixedly used. Instead, a differentiated matching will be made based on future load conditions and message timeliness requirements.

[0066] In one specific implementation, a second threshold, such as 8 bytes, can be set to distinguish between small and medium-sized messages that are more suitable for CAN 2.0 or CAN FD. When the data length of the message to be sent is greater than 8 bytes but not greater than 64 bytes, CAN FD can be selected first; when the data length of the message to be sent is not greater than 8 bytes, if the current predicted load is not high and the message is not a high real-time message, CAN 2.0 can be selected.

[0067] In this way, the protocol selector can form a hierarchical decision logic: for messages larger than 64 bytes, CANXL is preferred; for messages between 8 and 64 bytes, CAN FD is preferred; for messages no larger than 8 bytes, the decision on whether to use CAN 2.0 or CAN FD is further made based on the predicted load and service attributes.

[0068] In this embodiment, the message category result can be used to characterize the differences in service attributes of the messages to be sent. For example, the message category result may include at least one of real-time critical messages, non-real-time high-volume messages, and non-real-time low-volume messages. For real-time critical messages, even if their data length does not exceed the typical bearer threshold of CAN FD or CAN XL, they can be preferentially allocated to CAN FD when the predicted load is high or the link contention is strong, in order to improve their transmission efficiency and timeliness guarantee capability; for non-real-time high-volume messages, they can be preferentially allocated to CAN XL when the length meets the condition, in order to take advantage of high-load transmission; for non-real-time low-volume messages, CAN 2.0 can be preferentially matched, in order to reduce the occupation of high-specification protocol resources.

[0069] Furthermore, the traffic prediction result can represent not only the future load rate value, but also the future load level or the congestion risk level within a target time period. In one implementation, the protocol selector can determine whether to favor a higher-speed data transmission protocol based on whether the future load rate is higher than a preset load threshold. When the predicted load is high, it indicates that future bus contention may intensify. In this case, for delay-sensitive messages, CAN FD can be used more aggressively, or even high-speed protocol forwarding preparation can be prioritized. When the predicted load is low, it indicates that bus resources are relatively sufficient, and a more conservative protocol selection can be made to reduce unnecessary protocol switching and high-speed resource consumption.

[0070] To improve the adaptability of the protocol selection strategy to long-term operational changes, in some implementations, the load threshold can be set as a dynamic threshold rather than a fixed threshold. Specifically, the load threshold can be adaptively adjusted based on historical performance metrics. These historical performance metrics may include at least one of average latency, bandwidth utilization, and message drop rate.

[0071] For example, the deviation between the average latency and the target latency can be continuously recorded during system operation, and the load threshold can be reduced when the average latency is higher than the target latency, making the protocol selector more inclined to use high-speed protocols; the load threshold can also be increased when the bandwidth utilization is lower than the preset utilization target, making the protocol selector more conservative in adopting high-speed protocols, thereby avoiding resource waste.

[0072] In a specific implementation example, the dynamic threshold can be adjusted as follows: A base threshold is set as TH_base, and an adjustment amount ΔTH corresponding to the system's historical performance status is set. The current load threshold can then be expressed as TH_load = TH_base + ΔTH. When the system detects that the average latency is consistently higher than the target latency, ΔTH can be decreased so that more messages are allocated to CAN FD or CAN XL when the predicted load is slightly higher. When the system detects that bandwidth utilization is consistently low, ΔTH can be increased so that high-speed protocol allocation is triggered only at higher predicted load levels.

[0073] Furthermore, in actual operation, if the protocol selection is based solely on the current input and switching directly, it may cause frequent switching between different target communication protocols, thereby increasing control overhead and affecting stability. Therefore, in some implementations, the protocol selector can also maintain a protocol switching counter, the current protocol state, and the protocol switching cooldown time.

[0074] Specifically, a cooldown timer is started after each protocol switch. Before the cooldown time ends, the current protocol can remain unchanged even if the new input conditions meet the selection rules of another protocol. Only after the cooldown time ends is it allowed to re-evaluate and switch the target communication protocol.

[0075] In one specific implementation, the protocol switching cooldown time can be set to the millisecond level, such as 10ms. The protocol selector can record the timestamp of the last protocol switch, and if the interval between the current time and the last switch time is less than the cooldown time, it directly maintains the current protocol as the target communication protocol. Only when the time interval reaches or exceeds the cooldown time will a new round of protocol decision-making be performed based on the data length, predicted load, and message category results.

[0076] In other implementations, the selection of the target communication protocol based on the traffic prediction results and the message category results can also be achieved using a model fusion approach. Specifically, a model integrator can synthesize the traffic pattern recognition results, message classification results, and the recommendation results output by the optimized model to calculate protocol recommendation scores for CAN XL, CAN FD, and CAN 2.0 respectively, and select the protocol with the highest score as the target communication protocol.

[0077] Compared to a single rule-based judgment method, this integrated approach can balance rule interpretability and model self-learning ability, making the protocol selection process more suitable for complex traffic patterns and multi-objective optimization scenarios.

[0078] It should be noted that the above-mentioned selection logic for the target communication protocol is not limited to a specific combination of thresholds, a specific judgment order, or a specific model form. Any implementation method that dynamically matches and adaptively selects the communication protocol in CAN 2.0, CAN FD, and CAN XL based on traffic prediction results and message category results can be included within the scope of protection of this application.

[0079] In practical applications, the length threshold, load threshold, priority conditions, and switching suppression parameters can be adjusted according to the vehicle's electronic and electrical architecture, controller processing capabilities, message service distribution characteristics, and target performance requirements.

[0080] S104. Based on the traffic prediction results, adaptively adjust the bit rate configuration corresponding to the target communication protocol to obtain the target bit rate configuration.

[0081] In this embodiment, after selecting the target communication protocol, the bit rate configuration corresponding to the target communication protocol is adaptively adjusted based on the traffic prediction results to obtain the target bit rate configuration. This step can be executed by a bit rate controller, which is connected to an AI prediction engine and is used to receive future load rate prediction results, prediction accuracy information, and current performance feedback information. Combined with the type of the target communication protocol, the controller outputs the arbitration segment bit rate, data segment bit rate, and bit rate switching point adapted to the target communication protocol.

[0082] Specifically, the step of adaptively adjusting the bit rate configuration corresponding to the target communication protocol based on the traffic prediction result to obtain the target bit rate configuration may include: determining the arbitration segment bit rate, data segment bit rate, and bit rate switching point corresponding to the target communication protocol based on the predicted load; after obtaining the current delay and the target delay, adjusting the data segment bit rate by increasing, decreasing, or keeping it unchanged based on the deviation between the current delay and the target delay; and shifting the bit rate switching point forward or backward based on the prediction accuracy to generate the final target bit rate configuration.

[0083] In one implementation, the bit rate controller can pre-maintain a set of basic bit rate configuration relationships corresponding to the predicted load range. That is, the future load rate can be divided into multiple load intervals, and corresponding arbitration segment bit rate, data segment bit rate, and switching point position can be configured for each load interval.

[0084] For example, when the predicted load is in a low range, the arbitration segment bit rate can be set to a low fixed value, and the data segment bit rate can be set to a relatively low high rate to balance transmission requirements and power consumption control. When the predicted load increases to a medium or high range, the data segment bit rate can be increased, and if necessary, the arbitration segment bit rate can be increased simultaneously, and the bit rate switching point can be moved forward to increase the proportion of the high-speed transmission phase in the whole frame.

[0085] In a specific implementation example, the predicted load can be divided into four intervals: when the predicted load is between 0% and 30%, the arbitration segment bit rate can be set to 500kbps, the data segment bit rate can be set to 2Mbps, and the bit rate switching point can be set before the CRC segment; when the predicted load is between 30% and 60%, the arbitration segment bit rate can still be kept at 500kbps, while the data segment bit rate is increased to 5Mbps; when the predicted load is between 60% and 80%, the data segment bit rate can be further increased to 8Mbps, and the bit rate switching point can be moved forward to after the frame header; when the predicted load is between 80% and 100%, the arbitration segment bit rate can be increased to 1Mbps, the data segment bit rate can be increased to 10Mbps, and the switching point can be kept after the frame header.

[0086] It should be noted that the arbitration segment bit rate is mainly used to ensure the stability and compatibility of the arbitration phase, the data segment bit rate is mainly used to determine the actual transmission rate of the payload, and the bit rate switching point is used to determine the specific location for switching from the arbitration segment rate to the data segment rate.

[0087] Therefore, in this embodiment, the target bit rate configuration is not simply adjusting a single rate parameter, but rather forming a comprehensive rate scheme that adapts to different load scenarios through the coordinated control of the arbitration segment bit rate, the data segment bit rate, and the switching point.

[0088] Furthermore, after determining the basic configuration based on the predicted load, this embodiment can also incorporate latency feedback information during operation to adaptively fine-tune the data segment bit rate. Specifically, the current latency and target latency can be obtained, and it can be determined whether the current latency is higher or lower than the target latency. When the current latency is higher than the target latency, it indicates that the existing rate configuration is insufficient to support the current message processing requirements, and the data segment bit rate can be increased. When the current latency is lower than the target latency, it indicates that the current system has a certain latency margin, and the data segment bit rate can be appropriately reduced to reduce resource consumption while meeting latency requirements. When the current latency is near the target latency, the current data segment bit rate can be kept unchanged to avoid unnecessary frequent fluctuations.

[0089] In a more specific embodiment, the following adjustment logic can be adopted: when the current delay is greater than 1.2 times the target delay, the data segment bit rate is increased proportionally or by a fixed step, but not exceeding a preset maximum bit rate; when the current delay is less than 0.8 times the target delay, the data segment bit rate is decreased proportionally or by a fixed step, but not lower than a preset minimum bit rate; when the current delay is between 0.8 and 1.2 times the target delay, the data segment bit rate remains unchanged. By setting such upper and lower limit ranges, the system can avoid frequent bit rate adjustments due to small fluctuations, thereby improving control stability.

[0090] In some implementations, increasing the data segment bit rate can be achieved using at least one of two methods. One method is proportional adjustment, which involves multiplying the original data segment bit rate by a preset amplification factor; the other method is step adjustment, which involves increasing the original data segment bit rate by a preset step size. Correspondingly, decreasing the data segment bit rate can also be achieved using at least one of proportional reduction and step reduction methods.

[0091] In addition to adjusting the data segment bit rate based on delay feedback, this embodiment can also optimize the bit rate switching point based on prediction accuracy. The prediction accuracy can be obtained by comparing the predicted load with the actual load, or it can be directly output by the AI ​​prediction engine.

[0092] When the prediction accuracy is high, it indicates that the system's judgment on future load trends is relatively reliable. In this case, the bit rate switching point can be moved forward, for example, from a position close to the CRC segment to a position after the frame header, so as to enter the high-speed transmission stage as early as possible, thereby maximizing the high-speed utilization time of the data segment. When the prediction accuracy is low, it indicates that there is a large uncertainty in the future load trend. In this case, the bit rate switching point can be moved backward, for example, delayed until before the CRC segment before performing the rate switching, in order to reduce the configuration risk and transmission instability risk caused by early switching.

[0093] In a specific implementation, a first accuracy threshold and a second accuracy threshold can be set. For example, when the prediction accuracy is higher than 90%, the bit rate switching point is moved forward to immediately after the frame header; when the prediction accuracy is lower than 70%, the bit rate switching point is moved backward to before the CRC segment; when the prediction accuracy is between the two, the current switching point position can be maintained, or an intermediate position can be used as a compromise.

[0094] In some implementations, the adaptive adjustment of the bit rate configuration corresponding to the target communication protocol based on the traffic prediction result may also be combined with the type of the target communication protocol itself to perform differentiated processing.

[0095] For example, when the target communication protocol is CAN 2.0, since it typically uses a single rate for transmission, only a single bit rate parameter needs to be adjusted, without configuring a dedicated data segment bit rate and switching point; when the target communication protocol is CANFD or CAN XL, the arbitration segment bit rate and data segment bit rate can be configured simultaneously, and the bit rate switching point can be determined.

[0096] In other words, the target bit rate configuration does not require that all protocols contain the exact same fields, but can be adapted to the characteristics of the target communication protocol.

[0097] To facilitate the controller's execution of the target bit rate configuration, in this embodiment, the target bit rate configuration can be encapsulated into a preset data structure. This data structure may include an arbitration segment bit rate field, a data segment bit rate field, a switching point location field, and a transmission delay compensation field. The transmission delay compensation field can be used to compensate for physical link delays during high-speed data segment transmission, thereby improving the matching between sampling points and transmission timing.

[0098] Furthermore, after the target bit rate configuration is generated, the bit rate controller can call the configuration interface to write the target bit rate configuration into the corresponding register of the communication controller. Specifically, the arbitration segment bit rate can be written to the arbitration segment bit rate register, the data segment bit rate can be written to the data segment bit rate register, the transmission delay compensation value can be written to the compensation register, and the switching point position can be written to the bit rate switching point control register. After completing the above writing, the communication controller can execute the transmission of subsequent message frames according to the new target bit rate configuration.

[0099] In other implementations, the target bitrate configuration can also be generated with the assistance of a model integrator or a bitrate optimization model. That is, in addition to adjustments based on rule tables and latency feedback, current load rate, predicted load rate, protocol type, message priority, and queue length can be used as state inputs to the optimization model. The optimization model then outputs action suggestions such as "maintain current configuration," "increase data segment rate," and "decrease data segment rate," which are then fused with the rule results to generate the final target bitrate configuration.

[0100] It should be understood that the specific values ​​for the target bit rate configuration, the load interval division method, the latency threshold ratio, the accuracy threshold, and the switching point location mentioned above can all be adjusted according to the actual application scenario, and do not constitute a limitation on the scope of protection of this application. Any implementation method that dynamically configures the rate parameters and switching timing corresponding to the target communication protocol based on traffic prediction results to obtain a target bit rate configuration that adapts to the current and future network conditions can be included in the scope of protection of this application.

[0101] S105. Based on the target communication protocol and the target bit rate, configure the forwarding process for the message to be sent.

[0102] In this embodiment, after selecting the target communication protocol and generating the target bit rate configuration, the message to be sent is further forwarded based on the target communication protocol and the target bit rate configuration. This step can be executed by an adaptive forwarding engine, which is connected to the protocol selector and the bit rate controller. The adaptive forwarding engine receives the target communication protocol and the target bit rate configuration, and performs operations such as queuing management, scheduling extraction, protocol conversion, controller configuration, and message sending on the message to be sent.

[0103] Specifically, the forwarding process of the message to be sent based on the target communication protocol and the target bit rate configuration may include: adding the message to be sent to a message queue corresponding to the message priority; extracting the target message from the message queue according to a preset scheduling strategy; performing protocol conversion on the target message when the source protocol and the target communication protocol are inconsistent; writing the target bit rate configuration into the communication controller; and sending the target message after protocol conversion or the target message that does not require protocol conversion according to the target communication protocol and the target bit rate configuration.

[0104] In one implementation, the adaptive forwarding engine employs a multi-priority queue architecture for queue management of messages to be sent. Specifically, messages to be sent can be written into different priority queues according to their priority level, such as a highest priority queue for real-time critical messages, a high-priority message queue, a normal message queue, and a low-priority message queue. Each queue can be implemented using an independent buffer or by logical partitioning within a unified buffer.

[0105] Furthermore, regarding queue scheduling, the preset scheduling strategy may include at least one of strict priority scheduling and round-robin scheduling of peer queues. In a more specific implementation, the adaptive forwarding engine first checks whether the highest priority queue is empty. When there is a message to be sent in the highest priority queue, the target message is extracted from that queue first; only when the queue is empty does it continue to check the next highest priority queue, and so on. For multiple messages to be sent in the same priority queue, a round-robin method can be used to extract them sequentially, so as to avoid messages that entered earlier in the peer queue occupying the sending opportunity for a long time, thereby preventing peer message starvation.

[0106] In practical applications, the message to be sent may include, in addition to the message payload, additional fields such as source protocol identifier, target protocol identifier, message identifier, priority identifier, timestamp, and target bit rate configuration index.

[0107] Among them, the source protocol identifier is used to represent the original communication protocol to which the current message belongs, the target protocol identifier is used to represent the target communication protocol determined by the protocol selector, the priority identifier is used for queue mapping, the timestamp is used for subsequent end-to-end delay statistics, and the target bit rate configuration index is used to quickly obtain the corresponding target bit rate configuration before sending.

[0108] In one implementation, after the target message is retrieved from the corresponding queue, the adaptive forwarding engine first determines whether the source protocol of the target message is consistent with the target communication protocol. If the source protocol is consistent with the target communication protocol, the process can directly proceed to the bit rate configuration and transmission stage; if the source protocol is inconsistent with the target communication protocol, a protocol conversion must first be performed on the target message. This protocol conversion may include, but is not limited to, data field reassembly, frame header field update, data length adaptation, checksum-related field update, and encapsulation processing to match the target protocol format.

[0109] In scenarios where CAN XL messages are converted to CAN FD messages, since the single-frame payload capacity of CAN FD is less than that of CAN XL, when the data length of the target message exceeds the maximum payload length allowed by CAN FD, the target message can be fragmented. Specifically, the original data can be divided into multiple data segments according to the maximum payload length allowed by the target protocol, and a corresponding CAN FD target frame can be generated for each data segment. These segments are then written sequentially into the transmission queue or sent sequentially by the current forwarding process.

[0110] In some implementations, the fragmentation process may further include adding a fragment sequence number field, a total fragment count identifier field, or a fragment verification field to each data fragment, so that the receiving end can reassemble the data based on this additional information. Fragment division can be performed using a fixed length method or by padding the last fragment. For messages with high real-time requirements but slightly exceeding the length limit, key fields can be retained first, and non-key fields can be sent in subsequent fragments.

[0111] It should be understood that the above fragmentation details can be adjusted according to actual application needs. The core is to enable messages that exceed the single-frame carrying capacity of the target protocol to be adapted to the target protocol for forwarding.

[0112] In scenarios where CAN FD messages are converted to CAN 2.0 messages, the single-frame payload capacity of CAN 2.0 is further reduced, so truncation and / or segmentation of the data fields can be performed. In one specific implementation, the data fields in the CAN FD message can be truncated to the target length, for example, retaining the first few bytes of critical payload data, and the message frame can be repackaged based on the target protocol format. In another implementation, the original data can be divided into multiple CAN 2.0 message frames and sent in batches. If the message category result indicates that the message is a non-real-time message, segmented transmission can be used to prioritize integrity; if the message category result indicates that the message is more sensitive to latency, critical data can be sent first under certain conditions.

[0113] During protocol conversion, in addition to fragmenting, truncating, or reassembling data fields, the frame header fields also need to be updated. Specifically, the protocol identifier field in the message can be updated to the target communication protocol identifier, and the corresponding fields in the message header, such as length-related fields, control fields, and flag fields, can be reconstructed according to the target protocol format. Message identifier information common to different protocols can be directly inherited; for fields that are only valid in a specific protocol, they can be deleted, replaced, or regenerated according to the requirements of the target protocol.

[0114] After completing the protocol conversion or confirming that no protocol conversion is needed, the adaptive forwarding engine further configures the communication controller according to the target bit rate configuration. Specifically, it can obtain the current target bit rate configuration from the bit rate controller and call the controller configuration interface to write the arbitration segment bit rate, data segment bit rate, switching point position, and transmission delay compensation value into the corresponding registers or configuration units. After configuration, the communication controller can then execute the actual transmission of the target message to be sent according to the target bit rate configuration.

[0115] In one implementation, the controller configuration step can be performed after protocol conversion to ensure that the converted target protocol is consistent with the controller's current rate configuration. In another implementation, controller configuration can be performed immediately after retrieving the target message from the queue to reduce the waiting time after conversion. Regardless of the order, as long as the controller is in a working state matching the target bit rate configuration before the message is actually sent, this step can be considered to have been implemented.

[0116] Furthermore, during the sending phase, the adaptive forwarding engine can call the sending interface to write the target message into the controller's sending buffer and trigger a sending action on the corresponding protocol network. When a message is successfully sent, the sending result information corresponding to that message can be recorded; when message sending fails, sending failure processing is performed. The sending failure processing may include at least one of the following: re-queueing, incrementing the error count, recording the failure reason, triggering a link retry, and reporting the failure information to the upper-layer control module after reaching a preset number of failures.

[0117] In some implementations, after the target message is successfully sent, the adaptive forwarding engine can record the performance metrics corresponding to the message. These performance metrics may include at least one of end-to-end latency, bandwidth utilization, message drop rate, protocol switching frequency, and prediction accuracy.

[0118] The end-to-end latency can be calculated by the difference between the sending timestamp and the receiving acknowledgment timestamp; bandwidth utilization can be obtained by statistically analyzing the effective transmission time; message drop rate can be obtained by statistically analyzing the number of queue overflows or timeout drops; protocol switching frequency can be obtained by recording the number of times the target communication protocol changes per unit time; and prediction accuracy can be obtained by comparing the predicted load with the actual load. These performance metrics can be fed back to the bitrate controller, protocol selector, and AI prediction engine for subsequent optimization.

[0119] Furthermore, during queue management, queue length thresholds and message waiting time thresholds can be set. When the length of a priority queue exceeds the queue length threshold, queue congestion handling can be triggered, such as increasing the scheduling priority of messages in the queue, restricting the entry of low-priority messages, or remapping some messages to other protocol channels. When the waiting time of a message to be sent in the queue exceeds the message waiting time threshold, timeout handling can also be triggered, such as prioritizing transmission, discarding, or reselecting the target communication protocol.

[0120] In practical deployments, the adaptive forwarding engine can be implemented as a software module in a gateway controller, as a communication management component within a domain controller, or through a combination of software and hardware. For example, message queue management and protocol conversion can be handled by software, while bit rate configuration and underlying transmission actions can be executed by a hardware controller. Any message that can undergo the aforementioned forwarding processing based on the target communication protocol and target bit rate configuration is eligible for protection under this application.

[0121] S106. Collect performance feedback information corresponding to forwarding processing, and optimize and adjust subsequent protocol selection and bit rate configuration based on the performance feedback information.

[0122] In this embodiment, after the message to be sent is forwarded based on the target communication protocol and the target bit rate configuration, performance feedback information corresponding to the forwarding process is further collected, and subsequent protocol selection and bit rate configuration are optimized and adjusted based on the performance feedback information. This step can be executed by a performance monitoring and feedback module, which is connected to the adaptive forwarding engine, protocol selector, bit rate controller, AI prediction engine, and model updater. This module is used to quantitatively evaluate the system's performance after the actual message forwarding is completed and to send the evaluation results back to the corresponding decision-making module.

[0123] Specifically, the performance feedback information corresponding to the collection and forwarding processing may include monitoring and statistically analyzing at least one of the following: end-to-end latency, bandwidth utilization, message drop rate, protocol switching frequency, and prediction accuracy. These metrics characterize the execution effect of the forwarding processing from different perspectives. End-to-end latency characterizes the total time elapsed from when a message enters the sending process to when it is sent or acknowledged; bandwidth utilization characterizes the degree to which bus resources are effectively utilized; message drop rate characterizes packet loss during queue management and sending; protocol switching frequency characterizes the stability of the protocol dynamic adjustment process; and prediction accuracy characterizes the consistency between the aforementioned traffic prediction results and the actual operating state.

[0124] In one implementation, the end-to-end delay can be obtained using a timestamp differential method. Specifically, a start timestamp can be recorded when a message to be sent enters the sending queue, and an end timestamp can be recorded when the message is sent, a successful transmission confirmation is received, or a predetermined transmission completion condition is met. The end-to-end delay corresponding to the message is then determined based on the difference between the end timestamp and the start timestamp.

[0125] Furthermore, the average delay can be obtained by averaging the end-to-end delays of multiple messages within a unit of time; or the distribution of end-to-end delays over a period of time can be statistically analyzed to obtain the 95th percentile delay, the maximum delay, and the delay jitter value.

[0126] Furthermore, the bandwidth utilization rate can be obtained by statistically analyzing the relationship between effective transmission time, effective payload bytes, and the available transmission capacity of the bus. In one specific implementation, the length of time the bus is in an effective data transmission state within a preset statistical period and the actual amount of effective data carried during that time can be statistically analyzed. The ratio of the actual effective data transmission volume to the theoretical maximum transmission capacity can then be calculated to obtain the bandwidth utilization rate. Alternatively, bandwidth utilization rates can be statistically analyzed separately for different protocol channels and then globally fused to obtain the overall bandwidth utilization rate under a multi-protocol hybrid network.

[0127] In one implementation, the message drop rate can be obtained by counting the number of times the queue overflows, the number of times messages are dropped due to timeout, and the number of times messages are retried after a failed transmission. Specifically, when a message fails to be sent because the priority queue is full, the waiting time exceeds a threshold, or the number of retries exceeds the upper limit, the message can be counted as a dropped message. At the same time, the total number of messages within the statistical period is recorded, and the ratio between the number of dropped messages and the total number of messages is used as the message drop rate.

[0128] Regarding protocol switching frequency, in one implementation, a protocol selector or performance monitoring and feedback module can maintain a protocol switching counter and record the number of times the target communication protocol changes within a preset time period. If the number of protocol switching times per unit time is too high, it indicates that the current strategy is sensitive to boundary load conditions or short-term fluctuations, which may lead to frequent system switching; if the number of protocol switching times is too low, it may also indicate that the current dynamic strategy is not fully utilizing its adaptive capabilities. By monitoring the protocol switching frequency, it is possible to help determine whether the protocol selection rules, load thresholds, and switching cooling mechanisms are set reasonably.

[0129] Regarding prediction accuracy, in one implementation, the predicted load rate in the aforementioned traffic prediction results can be compared with the actual load rate collected during actual operation to determine the prediction error and further form a prediction accuracy index. For example, the prediction accuracy can be inferred from the absolute error, relative error, or mean square error between the predicted and actual values; alternatively, an accuracy interval can be set in the prediction task, and the prediction is considered valid when the predicted value falls within this interval. By continuously monitoring the prediction accuracy, it can be determined whether the AI ​​prediction engine is still suitable for the current traffic scenario and whether it is necessary to adjust the bit rate switching point or trigger a model update.

[0130] In this embodiment, the collected performance feedback information is not uniformly sent to a single module, but can be fed back to different decision-making units according to the indicator category. Specifically, end-to-end latency can be fed back to the bit rate controller for subsequent adjustment of the data segment bit rate and / or arbitration segment bit rate; bandwidth utilization can be fed back to the AI ​​prediction engine and / or model integrator for assisting in optimizing subsequent bit rate recommendations and strategy evaluation; message drop rate can be fed back to the protocol selector for correcting the subsequent target communication protocol selection strategy; protocol switching frequency can be fed back to the model updater and / or protocol selector for adjusting the switching cooldown time or switching sensitivity; prediction accuracy can be fed back to the AI ​​prediction engine and bit rate controller for respectively executing model updates and bit rate switching point corrections.

[0131] Furthermore, the optimization and adjustment of subsequent protocol selection based on the performance feedback information may include at least one of the following methods: adjusting the protocol selection threshold according to the message drop rate; adjusting the usage preference of high-speed protocols according to the average latency; adjusting the protocol switching cooldown time according to the protocol switching frequency; and updating the protocol recommendation priority in different scenarios according to the historical success rate.

[0132] For example, when a message drop rate is detected to be continuously increasing under high load scenarios, the load threshold can be appropriately reduced so that more medium-length or high-priority messages can be allocated to CAN FD or CAN XL earlier; when the protocol switching frequency is too high, the switching cooldown time can be appropriately extended to avoid frequent back-and-forth switching between CAN 2.0 and CAN FD; when the actual transmission success rate and latency performance of a certain type of message under a certain protocol are consistently better, the recommendation weight of that protocol in similar scenarios can also be increased.

[0133] In a more specific implementation, the protocol selector can continue to modify the protocol selection rules using dynamic thresholds. For example, the load threshold can be maintained at TH_load = TH_base + ΔTH, and ΔTH can be set as an adaptive adjustment amount driven by performance feedback. When the average latency is detected to be higher than the target latency, ΔTH can be reduced to make the protocol selector more inclined to enable high-speed protocols under lower predicted loads; when the bandwidth utilization is detected to be lower than the preset utilization target, ΔTH can be increased to reduce the overuse of high-speed protocols; when the message drop rate is higher than the preset drop rate threshold, ΔTH can be further reduced to improve the overall carrying capacity.

[0134] Accordingly, the optimization and adjustment of subsequent bit rate configuration based on the performance feedback information may include at least one of the following methods: adjusting the data segment bit rate according to the deviation between the current latency and the target latency; adjusting the combination relationship between the arbitration segment bit rate and the data segment bit rate according to the bandwidth utilization; adjusting the bit rate switching point position according to the prediction accuracy; increasing the target bit rate in short-term high-load scenarios according to the message drop rate and queue congestion; and appropriately reducing the target bit rate to reduce power consumption according to the idle state in low-load scenarios.

[0135] In one specific embodiment, when the end-to-end delay is higher than the target delay for multiple consecutive statistical periods, the bit rate controller can increase the current data segment bit rate by a preset step size or adjust it proportionally; when the end-to-end delay is lower than the target delay for multiple consecutive statistical periods and the bandwidth utilization is low, the current data segment bit rate can be appropriately reduced to balance latency requirements and energy consumption optimization; when the prediction accuracy is higher than the first accuracy threshold, the bit rate switching point can be moved forward to extend the duration of the high-speed data segment; when the prediction accuracy is lower than the second accuracy threshold, the bit rate switching point can be moved backward to reduce the instability risk caused by premature switching.

[0136] In some implementations, the performance feedback information can also be persistently stored in a historical traffic database. In addition to storing timestamps, message counts, total bytes, bus load rate, error counts, and feature vectors, the historical traffic database can also store actual load, predicted load, the selected protocol, and bit rate configuration.

[0137] Furthermore, the performance feedback information can also be used to trigger the model updater to perform model fine-tuning, incremental learning, or full retraining. In one implementation, full retraining can be triggered immediately when the prediction accuracy falls below a preset threshold; incremental learning can be triggered when a new traffic pattern is detected; and the model can be fine-tuned based on the most recent training window data when a preset update cycle is reached, such as every 60 seconds. The model updater can read recently generated feedback samples from the historical traffic database, calculate the distribution difference between the new data and the historical data, and fine-tune the existing model when the difference is small, and retrain the model when the difference is large.

[0138] In other implementations, the system can also set up a configuration strategy library to store historical configuration strategies that have shown superior performance in different scenarios. Specifically, the predicted load range, message priority range, and message length range corresponding to a certain operating scenario can be associated and stored with the actual average latency, bandwidth utilization, and success rate. When a similar scenario is subsequently detected, similar historical strategies can be retrieved from the configuration strategy library, and the preferred strategy can be selected or recommended after being sorted by performance indicators.

[0139] It should be noted that the collection period, statistical method, feedback destination, and optimization method of the aforementioned performance feedback information do not constitute a limitation. Any method that collects the actual operating performance after forwarding processing and sends the collection results back to the subsequent protocol selection and bit rate configuration processes to correct the implementation of subsequent decision logic, threshold parameters, rate parameters, or model parameters can be included within the scope of protection of this application. In practical applications, the sampling frequency, statistical window, and optimization sensitivity of different performance indicators can be flexibly configured according to the vehicle's communication architecture, message service type, and controller computing power.

[0140] The adaptive hybrid rate CAN XL communication method provided in this disclosure can predict future load by combining communication traffic characteristics, and dynamically adjust the protocol selection strategy, bit rate switching strategy and message forwarding strategy accordingly, thereby improving bandwidth utilization, reducing communication latency and latency jitter, reducing message loss, and improving the adaptive capability and overall communication performance of the vehicle network in complex business scenarios.

[0141] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0142] Based on the same inventive concept, this disclosure also provides an adaptive mixed-rate CAN XL communication device corresponding to the adaptive mixed-rate CAN XL communication method. Since the principle of the device in this disclosure for solving the problem is similar to the adaptive mixed-rate CAN XL communication method described above in this disclosure, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0143] Please see Figure 2 , Figure 2 This is a schematic diagram of an adaptive hybrid rate CAN XL communication device provided in an embodiment of this disclosure. Figure 2 As shown in the illustration, the adaptive hybrid rate CAN XL communication device 200 provided in this embodiment includes: The traffic monitoring module 210 is used to collect communication traffic characteristic parameters in the vehicle network.

[0144] AI prediction engine 220 is used to determine the traffic prediction results and message category results within the target time period based on the communication traffic characteristic parameters.

[0145] Protocol selector 230 is used to select a target communication protocol based on the traffic prediction result and the message category result.

[0146] The bit rate controller 240 is used to adaptively adjust the bit rate configuration corresponding to the target communication protocol based on the traffic prediction result to obtain the target bit rate configuration.

[0147] An adaptive forwarding engine 250 is configured to forward messages to be sent based on the target communication protocol and the target bit rate.

[0148] The feedback optimization module 260 is used to collect performance feedback information corresponding to forwarding processing, and to optimize and adjust subsequent protocol selection and bit rate configuration based on the performance feedback information.

[0149] The processing flow of each module in the device and the interaction flow between each module can be referred to the relevant descriptions in the above method embodiments, and will not be detailed here.

[0150] The present disclosure provides an adaptive hybrid rate CAN XL communication device that can predict future load by combining communication traffic characteristics, and dynamically adjust the protocol selection strategy, bit rate switching strategy and message forwarding strategy accordingly, thereby improving bandwidth utilization, reducing communication latency and latency jitter, reducing message loss, and enhancing the adaptive capability and overall communication performance of the vehicle network in complex business scenarios.

[0151] Corresponding to Figure 1 The adaptive hybrid rate CAN XL communication method in this disclosure also provides an electronic device 300, such as... Figure 3 The diagram shown is a structural schematic of an electronic device 300 provided in an embodiment of this disclosure, including: Processor 31, memory 32, and bus 33; memory 32 is used to store execution instructions, including main memory 321 and external memory 322; the main memory 321, also called internal memory, is used to temporarily store the computational data in processor 31, as well as the data exchanged with external memory 322 such as hard disk. Processor 31 exchanges data with external memory 322 through main memory 321. When the electronic device 300 is running, processor 31 and memory 32 communicate through bus 33, enabling processor 31 to execute... Figure 1 The steps of the adaptive hybrid rate CAN XL communication method.

[0152] This disclosure also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the adaptive mixed-rate CAN XL communication method described in the above-described method embodiments. The storage medium can be a volatile or non-volatile computer-readable storage medium.

[0153] This disclosure also provides a computer program product, which includes computer instructions. When the computer instructions are executed by a processor, they can perform the steps of the adaptive mixed-rate CAN XL communication method described in the above method embodiments. For details, please refer to the above method embodiments, which will not be repeated here.

[0154] The aforementioned computer program product can be implemented through hardware, software, or a combination thereof. In one optional embodiment, the computer program product is specifically embodied in a computer storage medium; in another optional embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0155] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the device described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here. In the several embodiments provided in this disclosure, it should be understood that the disclosed device and method can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection may be through some communication interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0156] 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 units can be selected to achieve the purpose of this embodiment according to actual needs.

[0157] In addition, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0158] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0159] Finally, it should be noted that the above-described embodiments are merely specific implementations of this disclosure, used to illustrate the technical solutions of this disclosure, and not to limit it. The protection scope of this disclosure is not limited thereto. Although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this disclosure. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this disclosure, and should all be covered within the protection scope of this disclosure. Therefore, the protection scope of this disclosure should be determined by the protection scope of the claims.

Claims

1. An adaptive hybrid rate communication method, characterized in that, include: Collect communication traffic characteristic parameters of the vehicle network; Based on the communication traffic characteristic parameters, determine the traffic prediction results and message category results within the target time period; Based on the traffic prediction results and the message category results, a target communication protocol is selected, wherein the target communication protocol includes CAN 2.0 network, CAN FD network or CAN XL network; Based on the traffic prediction results, the bit rate configuration corresponding to the target communication protocol is adaptively adjusted to obtain the target bit rate configuration; Based on the target communication protocol and the target bit rate, the message to be sent is forwarded. Collect performance feedback information corresponding to forwarding and processing, and optimize and adjust subsequent protocol selection and bit rate configuration based on the performance feedback information; Specifically, end-to-end latency is fed back to the bitrate controller to adjust the data segment bitrate and / or arbitration segment bitrate; bandwidth utilization is fed back to the AI ​​prediction engine and / or model integrator to assist in optimizing subsequent bitrate recommendations and strategy evaluation; message drop rate is fed back to the protocol selector to correct the selection strategy of subsequent target communication protocols; protocol switching frequency is fed back to the model updater and / or protocol selector to adjust the switching cooldown time or switching sensitivity; and prediction accuracy is fed back to the AI ​​prediction engine and bitrate controller to perform model updates and bitrate switching point corrections, respectively. Based on the performance feedback information, subsequent protocol selection is optimized and adjusted, including at least one of the following methods: adjusting the protocol selection threshold according to the message drop rate; adjusting the usage preference of high-speed protocols according to the average latency; adjusting the protocol switching cooldown time according to the protocol switching frequency; and updating the protocol recommendation priority in different scenarios according to the historical success rate. The performance feedback information is persistently saved in a historical traffic database, which stores timestamps, number of messages, total number of bytes, bus load rate, error count, feature vectors, actual load, predicted load, selected protocol, and bit rate configuration.

2. The method according to claim 1, characterized in that, The communication traffic characteristic parameters include at least one of message arrival rate, message size distribution, message identifier distribution, bus load rate, message interval time, error rate, retransmission rate, and priority distribution. The communication traffic characteristic parameters collected from the vehicular network specifically include: Traffic data is collected in real time from CAN 2.0 network, CAN FD network and CAN XL network respectively; The traffic data is statistically analyzed according to a preset time window to form a traffic feature set corresponding to each time window; The preset time window includes a prediction window for short-term traffic prediction and a training window for model training and updates.

3. The method according to claim 1, characterized in that, Based on the aforementioned communication traffic characteristic parameters, the traffic prediction results and message category results for the target time period are determined, specifically including: Feature extraction is performed on the communication traffic characteristic parameters to obtain a feature vector containing time-domain features, frequency-domain features, and statistical features; The feature vector is input into the AI ​​prediction engine to output future load rate prediction results, traffic pattern recognition results, and message category results; The frequency domain features include periodic frequency components and burst flow characteristics obtained through spectrum analysis; The statistical characteristics include at least one of the following: message size distribution entropy, priority distribution coefficient, and message interval time variation coefficient.

4. The method according to claim 3, characterized in that: The AI ​​prediction engine includes at least a time-series prediction model for predicting future load rates, a clustering model for identifying traffic patterns, a classification model for categorizing messages, and a reinforcement learning model for optimizing bit rate configuration and protocol switching actions. The AI ​​prediction engine also includes a model integrator, which is used to fuse the outputs of multiple models to generate protocol recommendation results and bitrate recommendation results.

5. The method according to claim 1, characterized in that, Based on the traffic prediction results and the message category results, a target communication protocol is selected, specifically including: When the message data length exceeds the first threshold, the CAN XL protocol is selected; When the message data length is no greater than the first threshold but greater than the second threshold, the CAN FD protocol is selected; When the message data length is no greater than the second threshold, the CAN FD protocol or the CAN 2.0 protocol is selected based on the predicted load and message priority. Specifically, when the predicted load is higher than the load threshold and the message to be sent is a delay-sensitive message, the CAN FD protocol is selected. The load threshold is a dynamic threshold, which is adaptively adjusted according to historical performance indicators. The historical performance indicators include at least one of the following: average latency, bandwidth utilization, and message drop rate. When the predicted load is not higher than the load threshold and the data length of the message to be sent does not exceed the preset short message threshold, the CAN 2.0 protocol is selected.

6. The method according to claim 1, characterized in that, Based on the traffic prediction results, the bit rate configuration corresponding to the target communication protocol is adaptively adjusted to obtain the target bit rate configuration, which specifically includes: Determine the arbitration segment bit rate, data segment bit rate, and bit rate switching point based on the predicted load; And increase the data segment bit rate when the current delay is higher than the target delay, or decrease the data segment bit rate when the current delay is lower than the target delay; The bit rate switching point is adjusted based on the prediction accuracy; when the prediction accuracy is higher than the first accuracy threshold, the bit rate switching point is moved forward; when the prediction accuracy is lower than the second accuracy threshold, the bit rate switching point is moved backward.

7. The method according to claim 1, characterized in that, Based on the target communication protocol and the target bit rate, the message to be sent is forwarded, specifically including: The message to be sent is added to a message queue corresponding to the message priority, wherein the message queue is a multi-priority queue; The target message is extracted from the message queue according to a preset scheduling strategy, wherein the preset scheduling strategy includes at least one of strict priority scheduling and peer queue round-robin scheduling. When the source protocol and the target communication protocol are inconsistent, a protocol conversion is performed on the target message; Send the target message after protocol conversion or the target message without protocol conversion according to the target bit rate configuration.

8. The method according to claim 7, characterized in that, Performing protocol conversion on the target message specifically includes: When converting CAN XL messages to CAN FD messages, data exceeding the payload of a single CAN FD frame is fragmented. When converting CAN FD messages to CAN 2.0 messages, the data fields are truncated or segmented. Update the frame header fields according to the target protocol.

9. An adaptive hybrid rate communication device, characterized in that, include: The traffic monitoring module is used to collect communication traffic characteristic parameters in the vehicle network; An AI prediction engine is used to determine the traffic prediction results and message category results within a target time period based on the communication traffic characteristic parameters. A protocol selector is used to select a target communication protocol based on the traffic prediction result and the message category result, wherein the target communication protocol includes CAN 2.0 network, CAN FD network or CAN XL network; A bit rate controller is used to adaptively adjust the bit rate configuration corresponding to the target communication protocol based on the traffic prediction result to obtain the target bit rate configuration; An adaptive forwarding engine is used to configure the forwarding processing of messages to be sent based on the target communication protocol and the target bit rate. The feedback optimization module is used to collect performance feedback information corresponding to forwarding processing, and to optimize and adjust subsequent protocol selection and bit rate configuration based on the performance feedback information. Specifically, end-to-end latency is fed back to the bitrate controller to adjust the data segment bitrate and / or arbitration segment bitrate; bandwidth utilization is fed back to the AI ​​prediction engine and / or model integrator to assist in optimizing subsequent bitrate recommendations and strategy evaluation; message drop rate is fed back to the protocol selector to correct the selection strategy of subsequent target communication protocols; protocol switching frequency is fed back to the model updater and / or protocol selector to adjust the switching cooldown time or switching sensitivity; and prediction accuracy is fed back to the AI ​​prediction engine and bitrate controller to perform model updates and bitrate switching point corrections, respectively. Based on the performance feedback information, subsequent protocol selection is optimized and adjusted, including at least one of the following methods: adjusting the protocol selection threshold according to the message drop rate; adjusting the usage preference of high-speed protocols according to the average latency; adjusting the protocol switching cooldown time according to the protocol switching frequency; and updating the protocol recommendation priority in different scenarios according to the historical success rate. The performance feedback information is persistently saved in a historical traffic database, which stores timestamps, number of messages, total number of bytes, bus load rate, error count, feature vectors, actual load, predicted load, selected protocol, and bit rate configuration.

10. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is in operation, the processor communicates with the memory via the bus, and the machine-readable instructions, when executed by the processor, perform the steps of the adaptive hybrid rate communication method as described in any one of claims 1 to 8.

Images