Deep learning-based dynamic configuration method and system for vehicle-mounted network TSN parameters

Abstract

The application belongs to the technical field of vehicle network communication and scheduling, and particularly relates to a vehicle network TSN parameter dynamic configuration method and system based on deep learning. The method comprises capturing vehicle network messages, extracting core features of the vehicle network messages, predicting vehicle network traffic data in a future period, dividing the vehicle network traffic data in the future period into a high-priority queue and a normal-priority queue, determining traffic values and cycle values of different priority queues respectively in combination with a preset bandwidth decision feature mapping table, allocating bandwidth to the high-priority queue and the normal-priority queue according to a preset bandwidth allocation rule, calculating TAS parameters for the high-priority queue, calculating CBS parameters for the normal-priority queue, and completing dynamic configuration of vehicle network TSN parameters. The application realizes dynamic configuration of vehicle network TSN parameters based on deep learning, and significantly improves the determinacy and real-time performance of the vehicle network in high-load and burst traffic scenarios.

Description

Technical Field

[0001] This invention belongs to the field of vehicle network communication and scheduling technology, and particularly relates to a method and system for dynamic configuration of vehicle network TSN parameters based on deep learning. Background Technology

[0002] Time-Sensitive Networking (TSN) technology in vehicular networks provides deterministic low-latency transmission guarantees for critical data flows through mechanisms such as gated scheduling strategy (TAS) and reputation-based traffic scheduling strategy (CBS). However, existing TSN parameter configurations mainly rely on static pre-configuration methods.

[0003] Currently, the configuration of TSN parameters in vehicular networks is typically optimized offline using simulation software, and then manually programmed and pre-configured into the switching equipment by engineers. This static configuration method cannot proactively detect real-time changes in vehicular network traffic. When the vehicle's operating status changes, the pre-configured TSN parameters cannot be adjusted in time, leading to an imbalance in network resource allocation. For example, when a vehicle enters a highway scenario, the autonomous driving system needs to process a large amount of camera and radar data, significantly increasing network traffic demand. However, the statically configured TSN parameters cannot dynamically expand bandwidth allocation, resulting in queuing delays for critical data transmission. Summary of the Invention

[0004] To overcome the shortcomings of the prior art, this invention provides a method and system for dynamic configuration of TSN parameters in vehicular networks based on deep learning. This method can predict vehicular network traffic in real time and dynamically adjust TSN parameters, thereby improving the determinism and real-time performance of vehicular networks under high load and sudden traffic scenarios. Compared with static configuration schemes, this invention achieves a fundamental shift from passive response to proactive prediction, thus solving the technical problems in the prior art where static TSN parameter configuration cannot proactively adapt to dynamic changes in vehicular network traffic, resulting in uncertain delays and jitter in critical data transmission under high load conditions, as well as the impact of sudden traffic on the determinism of network links.

[0005] To achieve the above objectives, one or more embodiments of the present invention provide the following technical solutions: The first aspect of this invention provides a method for dynamic configuration of TSN parameters in vehicular networks based on deep learning.

[0006] A deep learning-based method for dynamic configuration of TSN parameters in vehicular networks includes the following steps: Capture vehicle network packets and extract their core features; Based on the extracted core features, deep learning methods are used to predict in-vehicle network traffic data for future periods. The vehicle network traffic data for future time periods is divided into high-priority queues and ordinary-priority queues, and the traffic value and period value of different priority queues are determined by combining the preset bandwidth decision feature mapping table. Based on the determined traffic and period values, bandwidth is allocated to high-priority queues and ordinary-priority queues according to the preset bandwidth allocation rules. TAS parameters are calculated for high-priority queues and CBS parameters are calculated for ordinary-priority queues, thus completing the dynamic configuration of TSN parameters for the vehicular network.

[0007] The second aspect of this invention provides a deep learning-based system for dynamic configuration of TSN parameters in vehicular networks.

[0008] A deep learning-based dynamic configuration system for vehicular network (TSN) parameters includes: The data acquisition module is configured to: capture vehicle network packets and extract the core features of the vehicle network packets; The data prediction module is configured to: predict vehicle network traffic data for future periods based on the extracted core features and using deep learning methods; The data partitioning module is configured to divide the vehicle network traffic data for future time periods into high-priority queues and ordinary-priority queues, and determine the traffic value and period value of different priority queues by combining the preset bandwidth decision feature mapping table. The parameter configuration module is configured to: allocate bandwidth to high-priority queues and ordinary-priority queues according to preset bandwidth allocation rules based on the determined traffic and period values, calculate TAS parameters for high-priority queues and CBS parameters for ordinary-priority queues, and complete the dynamic configuration of TSN parameters for the vehicle network.

[0009] A third aspect of the present invention provides a computer-readable storage medium having a program stored thereon, which, when executed by a processor, implements the steps of the deep learning-based dynamic configuration method for vehicular network TSN parameters as described in the first aspect of the present invention.

[0010] The fourth aspect of the present invention provides an electronic device, including a memory, a processor, and a program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps in the deep learning-based dynamic configuration method for vehicular network TSN parameters as described in the first aspect of the present invention.

[0011] The above one or more technical solutions have the following beneficial effects: This invention provides a method and system for dynamic configuration of TSN parameters in vehicular networks based on deep learning. It employs deep learning to predict vehicular network traffic data for future periods, and divides the predicted data into high-priority queues and ordinary-priority queues. Different methods are used to determine the traffic and periodic values ​​for each queue, and sufficient bandwidth is reserved for the high-priority queues to ensure the transmission priority of safety-critical traffic while preventing excessive bandwidth consumption by high-priority traffic, thus ensuring fair allocation of network resources. It can predict vehicular network traffic in real time and dynamically adjust TSN parameters, improving the determinism and real-time performance of vehicular networks under high load and sudden traffic surges.

[0012] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0013] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0014] Figure 1 This is a diagram illustrating the execution steps of Embodiment 1 of the present invention.

[0015] Figure 2 This is a schematic diagram of the overall process of the deep learning-based dynamic configuration method for vehicle network TSN parameters in Embodiment 1 of the present invention.

[0016] Figure 3 This is a flowchart illustrating the data acquisition and feature extraction steps of Embodiment 1 of the present invention.

[0017] Figure 4 This is a flowchart illustrating the traffic prediction and decision triggering steps in Embodiment 1 of the present invention.

[0018] Figure 5 This is a schematic diagram of the Informer deep learning model according to Embodiment 1 of the present invention.

[0019] Figure 6 This is a flowchart illustrating the bandwidth decision and parameter generation steps in Embodiment 1 of the present invention.

[0020] Figure 7 This is a flowchart illustrating the configuration, distribution, and error handling steps in Embodiment 1 of the present invention. Detailed Implementation

[0021] It should be noted that the following detailed descriptions are exemplary and intended to provide further illustration of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0022] It should be noted that the terminology used herein is for the purpose of describing particular implementations only and is not intended to limit the exemplary implementations of the present invention.

[0023] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0024] Example 1 With the rapid development of intelligent driving technology, the number of sensors, controllers, and actuators in vehicular networks has increased dramatically, and network traffic exhibits complex characteristics of mixed periodicity, real-time performance, and burstiness. Time-Sensitive Networking (TSN), as a key technology to ensure deterministic low-latency transmission in vehicular networks, has its parameter configuration directly affecting the real-time performance and reliability of these networks.

[0025] As described in the background section, existing TSN parameter configurations rely on static pre-configuration, which cannot dynamically expand bandwidth allocation, leading to queuing delays in critical data transmission. Furthermore, the following technical issues also exist: Static configurations cannot cope with the dynamic characteristics of vehicular network traffic. Vehicular network traffic exhibits significant dynamism, including three types: periodic traffic, real-time traffic, and burst traffic. Periodic traffic, such as vehicle status monitoring data, is sent at fixed intervals; real-time traffic, such as autonomous driving perception data, requires strict end-to-end latency guarantees; burst traffic, such as OTA upgrade data and emergency event data, is unpredictable. Static TSN parameters are designed based on historical traffic patterns and cannot proactively adapt to real-time traffic changes. Under high load conditions, critical data transmission experiences uncertain latency and jitter. For example, when a vehicle triggers the Automatic Emergency Braking (AEB) system, emergency control data needs to be transmitted to the actuator within a very short time. However, the statically configured TAS gating period cannot reserve a time window for sudden emergency data transmission, leading to delays in emergency data transmission and impacting vehicle safety.

[0026] Static configurations cannot seamlessly adapt to vehicle operating scenarios. Vehicle network traffic requirements vary significantly across different operating scenarios. For example, in congested urban areas, vehicles frequently process close-range following and pedestrian detection data, resulting in network traffic primarily consisting of short-cycle, high-frequency data. On highways, vehicles need to process long-range obstacle detection and lane-keeping data, leading to network traffic primarily consisting of long-cycle, large-packet data. Static TSN parameters cannot dynamically adjust according to vehicle operating scenarios, resulting in low network resource utilization. Furthermore, static configurations cannot respond promptly to changes in scenarios such as driver changes or the activation of high-load infotainment applications, impacting user experience.

[0027] Current technologies lack the ability to proactively predict vehicular network traffic. Static configuration methods, based on historical traffic statistics, are passive response mechanisms that cannot anticipate traffic trends. When network traffic suddenly increases, the statically configured TSN parameters are insufficient to meet real-time demands, requiring only post-event adjustments, leading to network performance degradation. For example, when a vehicle is about to enter a highway, the autonomous driving system will activate highway driving assistance functions, causing a sharp increase in network traffic demand within a short period. However, static configuration cannot predict this change in advance, resulting in network congestion at the moment of system activation.

[0028] Current technologies lack effective mechanisms for handling sudden traffic surges. Sudden traffic surges in vehicular networks, such as OTA upgrade data and emergency event data, are characterized by large volumes, long durations, and unpredictability. Static TSN parameters cannot reserve sufficient network resources for sudden traffic surges. When these surges arrive, they crowd out the bandwidth for other critical data transmission, severely impacting network link determinism. For example, when a vehicle undergoes an OTA upgrade, upgrade data packets are continuously transmitted at a scale of hundreds of megabytes, consuming significant network bandwidth and increasing the latency of autonomous driving perception data transmission, thus affecting vehicle safety.

[0029] In summary, the existing static configuration method of TSN parameters cannot proactively adapt to the dynamic changes in vehicle network traffic, resulting in uncertain latency and jitter in critical data transmission under high load conditions. It cannot cope with the impact of sudden traffic on network link determinism caused by OTA upgrades, emergency events, etc., and cannot achieve seamless integration with vehicle operation scenarios, which seriously restricts the real-time performance and reliability of vehicle networks.

[0030] Based on this, this embodiment discloses a deep learning-based method for dynamic configuration of TSN parameters in vehicular networks, which can achieve: First, this invention uses the Informer deep learning model to predict future vehicular network traffic data in real time, achieving a fundamental shift from passive response to proactive prediction compared to static configuration schemes. The Informer model, based on the ProbSparse self-attention mechanism, can efficiently process long-sequence time-series data in vehicular networks, capturing the periodicity, trend, and burstiness characteristics of traffic. Specifically, it uses the most recent 30 seconds of historical time-series data for inference and divides the predicted next 10 seconds of data into 20 time windows of 500ms each, achieving refined prediction of vehicular network traffic. Experimental data shows that under high-load scenarios, compared to static configuration schemes, this invention reduces key data transmission latency by more than 30% and jitter by more than 40%, significantly improving the determinism and real-time performance of vehicular networks.

[0031] Secondly, this invention combines multi-dimensional triggering conditions based on vehicle operating status to achieve seamless alignment between TSN parameter configuration and vehicle operating scenarios. Dynamically adjusted activation conditions include scenarios such as entering or leaving highways, entering congested road sections, severe weather, driver changes, launching high-load infotainment applications, and pre-activation of automatic emergency braking. Through the fusion of multi-source information from navigation systems, cameras, radar, sensors, and biometrics, the system accurately identifies changes in vehicle operating status. When activation conditions are met, the system immediately initiates traffic prediction and dynamic adjustment of TSN parameters to ensure real-time matching of network resource allocation with the vehicle operating scenario. For example, when a vehicle enters a highway, the system automatically activates traffic prediction for the highway assisted driving function, reserving bandwidth in advance for autonomous driving perception data and avoiding network congestion at the moment of system activation.

[0032] Third, this invention employs a 110% bandwidth reservation strategy for high-priority queues and a TAS+CBS hybrid scheduling mechanism to effectively address the impact of sudden traffic surges on network link determinism caused by OTA upgrades and emergency events. For high-priority queues with priorities of 5 to 7, this invention takes the maximum traffic value and minimum period value of the corresponding queue within 20 time windows and allocates 110% of the bandwidth for computational traffic, ensuring that high-priority queues still have sufficient bandwidth margins in sudden traffic scenarios. Simultaneously, a fixed time window is allocated to high-priority queues through a TAS gating mechanism, and the traffic transmission rate of ordinary priority queues is controlled through a CBS reputation mechanism, achieving hard real-time assurance for high-priority traffic and flexible scheduling of ordinary priority traffic. Experimental data shows that in OTA upgrade scenarios, this invention's solution can ensure that the end-to-end latency of autonomous driving perception data remains stable within 50 microseconds, avoiding the latency fluctuation problem caused by upgrade data crowding out perception data bandwidth in static configuration schemes.

[0033] Fourth, this invention achieves refined perception and prediction of vehicular network traffic through port mirroring with Outer Tag, 500ms periodic data acquisition, and a 20-time-window prediction mechanism. The port mirroring Outer Tag method accurately distinguishes between mirrored packets and actual interactive packets by marking additional VLAN tags on mirrored packets, preventing mirrored packets from interfering with normal communication. The 500ms periodic data acquisition effectively reduces system resource consumption while ensuring data accuracy, balancing system real-time performance and resource usage. The 20-time-window prediction mechanism divides the traffic data for the next 10 seconds into 500ms intervals, enabling refined identification of high-frequency key signals. Compared to traditional single-point prediction schemes, the prediction accuracy is improved by more than 25%. Experimental data shows that this invention's solution improves vehicular network bandwidth utilization by more than 25% compared to static configuration schemes, while ensuring the determinism and real-time performance of critical data transmission.

[0034] Fifth, this invention ensures the reliability and stability of TSN parameter configuration through NETCONF protocol configuration distribution and error rollback mechanisms. NETCONF, as a standard protocol for network device configuration management, supports transactional configuration operations and configuration verification. This invention achieves standardized TSN parameter distribution by constructing NETCONF messages containing edit-config RPC calls. Simultaneously, this invention designs handling mechanisms for three error types: configuration timeout errors, invalid parameter errors, and communication anomaly errors. When configuration fails, it automatically rolls back to the last correctly configured parameter version and records the error log, avoiding network failures caused by configuration errors. Experimental data shows that this invention achieves a configuration distribution success rate of over 99.9%, and can complete rollback within 1 second when configuration fails, ensuring the stable operation of the vehicular network.

[0035] like Figure 1 As shown, the deep learning-based method for dynamic configuration of TSN parameters in vehicular networks includes the following steps: Capture vehicle network packets and extract their core features; Based on the extracted core features, deep learning methods are used to predict in-vehicle network traffic data for future periods. The vehicle network traffic data for future time periods is divided into high-priority queues and ordinary-priority queues, and the traffic value and period value of different priority queues are determined by combining the preset bandwidth decision feature mapping table. Based on the determined traffic and period values, bandwidth is allocated to high-priority queues and ordinary-priority queues according to the preset bandwidth allocation rules. TAS parameters are calculated for high-priority queues and CBS parameters are calculated for ordinary-priority queues, thus completing the dynamic configuration of TSN parameters for the vehicular network.

[0036] This embodiment uses the Informer deep learning model to predict vehicle network traffic in real time. Combined with multi-dimensional triggering conditions of vehicle operating status, it dynamically calculates and issues TSN scheduling parameters, thereby effectively solving the technical problem that traditional static configuration schemes cannot actively adapt to dynamic changes in vehicle network traffic, and significantly improving the determinism and real-time performance of vehicle networks under high load and sudden traffic scenarios.

[0037] like Figure 2 As shown, the method of the present invention includes a system initialization step, a data acquisition and feature extraction step S100, a traffic prediction and decision triggering step S200, a bandwidth decision and parameter generation step S300, and a configuration distribution and error handling step S400. Each step is described in detail below with reference to the accompanying drawings.

[0038] Step S100: Data acquisition and feature extraction.

[0039] like Figure 2 and Figure 3 As shown, the data acquisition and feature extraction steps capture vehicular network packets in real time through the switch port mirroring function, extract key traffic features, and periodically save them to the database, providing a data foundation for subsequent traffic prediction. Based on the temporal characteristics of vehicular network traffic, this step constructs a traffic temporal database through real-time acquisition and feature extraction, providing historical data required for the training and inference of deep learning models.

[0040] Step S101: System initialization, loading traffic feature identification method.

[0041] Upon system startup, the onboard central processing unit loads a predefined traffic feature identification method. Traffic features are multi-dimensional descriptions of onboard network traffic, used to accurately identify traffic in different functional domains and service types, and to provide a basis for subsequent bandwidth decisions. The key technology in this step lies in achieving refined identification and classification of onboard network traffic through the combination of multi-dimensional traffic features.

[0042] The predefined traffic characteristics include the following seven dimensions: First, VLAN IDs are used to distinguish traffic from different functional domains within the vehicular network. Vehicular networks are typically divided into functional domains such as vehicle control, intelligent driving, chassis, and infotainment, each assigned a unique VLAN ID. For example, the VLAN ID for the vehicle control domain is 10, for the intelligent driving domain it is 20, for the chassis domain it is 30, and for the infotainment domain it is 40. Through VLAN IDs, the vehicular central processing unit can quickly identify the functional domain to which a packet belongs, providing a domain-level distinction for subsequent traffic prediction and bandwidth allocation.

[0043] Second, IP addresses are used to precisely locate specific devices within a functional domain. Each electronic control unit (ECU), sensor, and actuator in the vehicle network is assigned a unique IP address. For example, the IP address for a forward-facing camera is 192.168.10.100, the IP address for a millimeter-wave radar is 192.168.10.101, and the IP address for a lidar is 192.168.10.102. Through these IP addresses, the vehicle's central processing unit can accurately identify the source and destination devices of packets, providing device-level fine-grained information for traffic path analysis and bandwidth allocation.

[0044] Third, the service ID is used to identify the service application. The vehicular network adopts a service-oriented architecture (SOA), where different service applications are assigned a unique service ID. For example, the service ID for camera image data is 1001, for radar point cloud data it's 1002, for vehicle status monitoring it's 1003, and for OTA upgrades it's 2001. Through the service ID, the vehicular central processing unit can identify the service application to which a packet belongs, providing a basis for distinguishing service levels for subsequent traffic prediction and QoS assurance.

[0045] Fourth, the Stream Identifier (ID) is used to identify audio and video streams. Audio and video streams in the vehicular network, such as video streams from vehicle cameras and audio streams from vehicle microphones, are marked with fixed Stream Identifier (IDs). For example, the ID for the front-facing camera video stream is 5001, the ID for the rear-facing camera video stream is 5002, and the ID for the vehicle microphone audio stream is 5003. Through the Stream Identifier (ID), the vehicle's central processing unit can identify the audio and video streams, providing a stream-level distinction for subsequent traffic prediction and bandwidth allocation.

[0046] Fifth, the frame size is used for bandwidth time-series prediction. The frame size is measured in Mbps, representing the amount of data in a packet per unit of time. The onboard central processing unit (CPU) performs real-time statistics on the frame size, constructing time-series traffic data to provide historical data for training and inference of deep learning models. For services with fixed-length packets, such as vehicle status monitoring data, the CPU pre-configures and reads the packet length; for services with dynamic-length packets, such as audio and video stream data, the CPU calculates the packet length in real time.

[0047] Sixth, timestamps are used to analyze traffic periodicity and trends. Timestamps are measured in nanoseconds (ns) and represent the sending or receiving time of a message. For messages containing a sending timestamp field, the vehicle's central processing unit (CPU) directly reads the timestamp; for messages without a sending timestamp field, the CPU uses the message receiving time as the timestamp. Through timestamps, the CPU can analyze the periodic characteristics of traffic, such as the periodic transmission of vehicle status monitoring data, and the trend characteristics, such as the duration of OTA upgrade data, providing time-dimensional feature input for deep learning models.

[0048] Seventh, priority, used to distinguish traffic patterns of different service qualities. Priority values ​​range from 0 to 7, with higher values ​​indicating higher priority. Different service applications in the vehicular network are assigned different priorities based on their real-time and reliability requirements. For example, autonomous driving perception data has a priority of 7, vehicle status monitoring data has a priority of 6, OTA upgrade data has a priority of 3, and infotainment data has a priority of 1. Through priority, the vehicular central processing unit can distinguish traffic patterns of different service qualities, providing a basis for subsequent bandwidth allocation and TSN parameter calculation.

[0049] Table 1 Predefined flow characteristics

[0050] The seven dimensions of traffic characteristics mentioned above constitute a complete description of the vehicle network traffic. The vehicle's central processing unit loads these traffic characteristic identification methods into memory, providing a basis for subsequent packet feature extraction. Specifically, the vehicle's central processing unit extracts VLAN ID, IP address, service ID, flow identifier ID, and priority based on the Ethernet frame header, IP packet header, and application layer fields of the packet; it extracts the traffic size of each frame based on the packet length field or real-time calculation; and it extracts the timestamp based on the packet timestamp field or the reception time.

[0051] Step S102: Capture data packets in real time through port mirroring.

[0052] The vehicle-mounted central processing unit enables port mirroring via a control switch to capture vehicle network packets in real time. Port mirroring technology is a core technology for network traffic monitoring. By copying packets from a specified port and forwarding them to the mirror port, it achieves lossless capture of network traffic. The key technical aspect of this step is accurately distinguishing between mirrored packets and actual interactive packets using the Outer Tag method, thus preventing mirrored packets from interfering with normal communication.

[0053] Specifically, the vehicle-mounted central processing unit (CNU) sends a port mirroring configuration command to the switch via a network management protocol such as NETCONF or SNMP, specifying the source port and destination port to be mirrored. The source port is the switch port in the vehicle network that needs to monitor traffic, such as the port connected to cameras, radar, or lidar; the destination port is the switch port connected to the CNU. After receiving the port mirroring configuration command, the switch starts the port mirroring function, copies all packets from the source port, and forwards them to the destination port.

[0054] To distinguish between mirrored packets and actual exchange packets, the switch encapsulates an additional VLAN tag, the Outer Tag, on the outer layer of the Ethernet frame header of the mirrored packet. The Outer Tag is a VLAN tag defined by the IEEE 802.1Q standard, containing a VLAN ID field and a priority field. The switch assigns a dedicated VLAN ID to the mirrored packet, for example, VLAN ID 4094, and encapsulates it with an Outer Tag in the Ethernet frame header, marking VLAN ID 4094. Through the Outer Tag, the onboard central processing unit can accurately identify mirrored packets and distinguish them from actual exchange packets.

[0055] The vehicle-mounted central processing unit (CLU) receives mirrored packets through the mirroring destination port. Upon receiving a mirrored packet, the CLU first checks the Ethernet frame header to determine if an Outer Tag exists. If an Outer Tag exists and the VLAN ID is 4094, the packet is determined to be a mirrored packet; if no Outer Tag exists or the VLAN ID is not 4094, the packet is determined to be an actual interactive packet and is discarded. For mirrored packets, the CLU removes the Outer Tag, restores the original packet format, and then performs subsequent traffic feature extraction processing.

[0056] Using the Outer Tag method described above, the onboard central processing unit can accurately distinguish between mirrored packets and actual interactive packets, preventing mirrored packets from interfering with normal communication and ensuring the accuracy of data collection. Meanwhile, the port mirroring function has minimal impact on switch performance and will not affect normal communication within the onboard network.

[0057] Step S103: Extract features from each mirrored message in chronological order.

[0058] The onboard central processing unit extracts the traffic characteristics of mirrored packets one by one according to the order of their arrival. The key technology in this step is to maintain the temporal order of traffic data by extracting features in a time sequence, thus providing training and inference data that conforms to the temporal characteristics of the deep learning model.

[0059] Specifically, the onboard central processing unit maintains a message receiving queue and adds mirrored messages to the queue in the order they arrive. The onboard central processing unit retrieves mirrored messages sequentially from the head of the queue and performs feature extraction on each mirrored message. The feature extraction process includes the following steps: The first step is to extract the VLAN ID. The vehicle's central processing unit (CPU) parses the Ethernet frame header of the packet and reads the VLAN ID from the VLAN tag field. The VLAN tag field is located after the source MAC address field in the Ethernet frame header and is 4 bytes long, with the VLAN ID occupying 12 bits. After reading the VLAN ID, the CPU determines the functional domain to which the packet belongs based on the mapping relationship between the VLAN ID and functional domains. For example, if the VLAN ID is 20, the packet is determined to belong to the Intelligent Driving domain.

[0060] The second step is to extract the IP address. The vehicle-mounted central processing unit parses the IP header of the packet, reading the source IP address field and the destination IP address field. The source IP address indicates the sending device of the packet, and the destination IP address indicates the receiving device of the packet. After reading the source and destination IP addresses, the vehicle-mounted central processing unit determines the source and destination devices of the packet based on the mapping relationship between IP addresses and devices. For example, if the source IP address is 192.168.10.100, then it is determined that the packet comes from the forward-facing camera.

[0061] The third step is to extract the service ID. The vehicle-mounted central processing unit parses the application layer fields of the packet and reads the service ID field. The location and length of the service ID field depend on the specific application layer protocol. For example, for the SOME / IP protocol, the service ID field is located in the Service ID field of the SOME / IP packet header and is 2 bytes long. After reading the service ID, the vehicle-mounted central processing unit determines the service application to which the packet belongs based on the mapping relationship between the service ID and the service application. For example, if the service ID is 1001, it is determined that the packet belongs to the camera image data service.

[0062] The fourth step is to extract the stream identifier ID. The vehicle-mounted central processing unit (CPU) parses the application layer fields of the packet and reads the stream identifier ID field. The stream identifier ID field is used to identify the audio and video streams, and its location and length depend on the specific application layer protocol. For example, for the RTP protocol, the stream identifier ID field is located in the SSRC field of the RTP packet header and is 4 bytes long. After reading the stream identifier ID, the CPU determines the audio and video stream to which the packet belongs based on the mapping relationship between the stream identifier ID and the audio and video streams. For example, if the stream identifier ID is 5001, then the packet belongs to the video stream from the front-facing camera.

[0063] The fifth step is to extract the traffic size for each frame. The onboard central processing unit (CPU) extracts the traffic size for each frame based on the message length field or through real-time calculation. For services with fixed-length messages, the CPU pre-configures and reads the message length. For example, if the vehicle status monitoring data message length is fixed at 100 bytes, the CPU pre-configures the message length to 100 bytes and reads it directly. For services with dynamic-length messages, the CPU calculates the message length in real-time. Specifically, the CPU reads the frame length field from the Ethernet frame header of the message, calculates the total message length, and then subtracts the lengths of the Ethernet frame header, IP header, and transport layer header to obtain the length of the application layer data, which is used as the traffic size for each frame.

[0064] Step 6: Extract the timestamp. The onboard central processing unit (CPU) extracts the timestamp based on the message timestamp field or the reception time. For messages containing a transmission timestamp field, the CPU parses the application layer fields of the message and reads the timestamp field. For example, for the IEEE 1588 PTP protocol, the timestamp field is located in the Timestamp field of the PTP message header and is 10 bytes long. After reading the timestamp, the CPU converts it to nanoseconds (ns). For messages that do not contain a transmission timestamp field, the CPU reads the system clock to obtain the message reception time, which is used as the timestamp.

[0065] Step 7: Priority Extraction. The onboard central processing unit parses the Ethernet frame header of the packet and reads the priority field from the VLAN tag field. The priority field is located in the high 3 bits of the VLAN tag field, with a value range of 0 to 7. After reading the priority, the onboard central processing unit determines the quality of service level of the packet. For example, if the priority is 7, the packet is determined to be the highest priority traffic.

[0066] Through the seven steps described above, the vehicle-mounted central processing unit (CLU) completes the traffic feature extraction for a single mirrored packet. The CLU organizes the extracted traffic features into a data record, including seven fields: VLAN ID, IP address, service ID, flow identifier ID, frame size, timestamp, and priority. The CLU extracts the traffic features of each mirrored packet sequentially according to their arrival order, constructing a time-series sequence of traffic features.

[0067] The extraction of the above traffic features has clear technical significance: Service ID, VLAN ID, and IP address are used for accurate traffic identification and path differentiation, providing a basis for traffic classification in subsequent traffic prediction and bandwidth allocation; the size of each frame of traffic is used for bandwidth time-series prediction, providing time-series characteristics of traffic data for deep learning models; timestamps are used to analyze traffic periodicity and trends, providing time-dimensional characteristics of traffic data for deep learning models; priority is used to distinguish traffic patterns of different service qualities, providing a basis for priority in subsequent bandwidth allocation and TSN parameter calculation.

[0068] Step S104: Write the extracted time series features into the database at 500ms intervals.

[0069] The onboard central processing unit writes the extracted time-series features into the database sequentially every 500ms. The key technology in this step is that by writing in batches periodically, it effectively reduces system resource consumption while ensuring data accuracy, thus balancing system real-time performance and resource usage.

[0070] Specifically, the vehicle-mounted central processing unit maintains a traffic feature cache queue, temporarily storing the traffic feature data records extracted in each cycle into the cache queue. When the number of data records in the cache queue reaches a preset threshold or the time interval reaches 500ms, the vehicle-mounted central processing unit batch writes all data records in the cache queue into the database. The batch write operation is implemented through the database's batch insert interface. Compared with inserting records one by one, batch insert can significantly reduce database IO overhead and transaction overhead, and improve write performance.

[0071] The choice of a 500ms period is based on the following technical considerations: a period that is too short, such as 10ms, will significantly increase chip scheduling and storage overhead. The vehicle's central processing unit needs to frequently perform database write operations, consuming significant CPU and I / O resources and affecting the execution of other tasks. Simultaneously, frequent database write operations generate substantial transaction overhead, reducing database performance. A period that is too long, such as 10 seconds, may lead to the loss of high-frequency traffic characteristics, affecting prediction accuracy. High-frequency periodic traffic exists in vehicle networks; for example, vehicle status monitoring data is sent at a 100ms period. If the data acquisition period is 10 seconds, 100 vehicle status monitoring data packets will accumulate within a single period, making it impossible to accurately capture the periodic characteristics of the traffic and affecting the prediction accuracy of the deep learning model.

[0072] A 500ms period effectively reduces system resource consumption while ensuring data accuracy. For the most frequent periodic traffic in the vehicle network, such as vehicle status monitoring data, which is sent at a 100ms period, five data points are collected within a 500ms period, effectively capturing the periodic characteristics of the traffic. Simultaneously, the 500ms periodic database write frequency is moderate, avoiding excessive pressure on the CPU and I / O resources of the vehicle's central processing unit and minimizing impact on database performance.

[0073] The database uses a time-series database, specifically designed for storing and retrieving time-series data.

[0074] The time-series feature data stored in the database provides historical data input for the subsequent traffic prediction module. When performing traffic prediction, the deep learning model needs to obtain historical time-series data, such as the last 30 seconds, as input. The onboard central processing unit quickly queries traffic feature data within a specified time range through the time window query interface of the time-series database, using this data as input for the deep learning model.

[0075] Through the above data acquisition and feature extraction steps, the vehicle-mounted central processing unit realizes real-time monitoring and feature extraction of vehicle network traffic, constructs a traffic time series database, and provides a data foundation for subsequent traffic prediction.

[0076] Step S200: Traffic prediction and decision triggering.

[0077] like Figure 2 and Figure 4 As shown, the traffic prediction and decision triggering step employs an Informer-based time-series prediction model. It predicts future traffic flow based on historical data and combines this with multi-dimensional triggering conditions related to vehicle operating status to determine whether to activate dynamic adjustment of TSN parameters. This step leverages deep learning-based time-series prediction technology and vehicle operating status perception technology to proactively predict traffic flow trends and intelligently determine adjustment timing, thereby achieving dynamic intelligent configuration of TSN parameters.

[0078] Step S201: AI model design and training.

[0079] like Figure 4 As shown, the Informer deep learning model is an improvement on the Transformer architecture, specifically designed for long-sequence time series prediction tasks. The key technical aspect of this step lies in significantly reducing computational complexity through the ProbSparse self-attention mechanism, enabling the model to efficiently process long-sequence time series data in vehicular networks. Simultaneously, it captures multi-dimensional features of traffic data through the Embedding layer, achieving accurate traffic prediction through an encoder-decoder architecture.

[0080] The Informer model consists of three core components: the embedding layer, the encoder, and the decoder. The structure and working principle of each component are described in detail below.

[0081] Embedding layer: The Embedding layer is responsible for mapping the input traffic feature sequence into a high-dimensional vector representation, providing input for the encoder. The Embedding layer consists of three sub-layers: TokenEmbedding, PositionalEmbedding, and TemporalEmbedding.

[0082] First, TokenEmbedding expands the sequence dimension through one-dimensional convolutional operations. The input traffic feature sequence is a multivariate time series, with each time step containing multiple feature dimensions such as VLAN ID, IP address, service ID, and traffic size per frame. TokenEmbedding expands the feature dimension of the input sequence from the original 7 dimensions to the model dimension of 512 dimensions through one-dimensional convolutional operations. Specifically, TokenEmbedding uses a one-dimensional convolutional layer with a kernel size of 1, the number of input channels being the original feature dimension, and the number of output channels being the model dimension. The convolutional layer is followed by a ReLU activation function. Through one-dimensional convolutional operations, TokenEmbedding expands the feature dimension, providing a high-dimensional feature representation for the subsequent encoder.

[0083] Second, PositionalEmbedding performs absolute position encoding. The Transformer architecture itself does not contain position information, so position encoding is needed to assign a unique position vector to each position in the sequence, enabling the model to perceive the position information of elements in the sequence. PositionalEmbedding uses a sine-cosine position encoding method to generate a position vector for each position in the sequence.

[0084] Third, TemporalEmbedding encodes temporal information to capture the trends and seasonal characteristics of traffic data. Vehicle network traffic exhibits significant temporal characteristics, such as traffic differences between weekdays and weekends, peak and off-peak hours, and seasonal variations. TemporalEmbedding decomposes timestamps into multiple time dimensions, such as year, month, day, hour, minute, and second, assigning an independent embedding vector to each time dimension. Then, it sums the embedding vectors for all time dimensions to obtain the temporal embedding vector. Specifically, TemporalEmbedding uses a learnable embedding matrix, assigning an embedding vector to each value of each time dimension. For example, for the hour dimension, with values ​​ranging from 0 to 23, TemporalEmbedding assigns an embedding vector to each hour, resulting in 24 embedding vectors. Through temporal embedding, TemporalEmbedding captures the temporal characteristics of traffic data, enabling the model to learn the trends and seasonal patterns of traffic.

[0085] The output of the Embedding layer is the sum of the outputs of the three sub-layers: TokenEmbedding, PositionalEmbedding, and TemporalEmbedding, which serves as the input to the encoder. Through the Embedding layer, the Informer model achieves high-dimensional feature representation and multi-dimensional feature fusion of the input traffic feature sequence.

[0086] Encoder: The encoder is responsible for extracting and encoding features from the input sequence to generate a high-level feature representation. The encoder consists of multiple stacked coding layers, each of which contains a ProbSparse self-attention layer, a one-dimensional convolutional layer, a normalization layer, and a residual structure.

[0087] The ProbSparse self-attention layer is a core innovation of the Informer model, significantly reducing computational complexity by sparsifying the attention matrix. Traditional Transformer models' self-attention mechanisms experience a sharp increase in computational complexity when dealing with long sequences, limiting their application in long sequence prediction tasks. The ProbSparse self-attention mechanism, through probabilistic sparsity, calculates only the most important attention weights, reducing computational complexity and enabling the model to efficiently handle long sequence data.

[0088] Specifically, the ProbSparse self-attention mechanism first calculates the similarity matrix between the query vector Q and the key vector K. Then, based on the similarity matrix, it calculates the importance score for each query vector, selects the top-k query vectors with the highest importance scores, and only calculates the attention weights between these query vectors and all key vectors. The attention weights for other query vectors are set to a uniform distribution. Through probabilistic sparsity, the ProbSparse self-attention mechanism significantly reduces computational complexity while maintaining the model's prediction accuracy.

[0089] The encoding layer's processing flow is as follows: First, a multi-head ProbSparse self-attention mechanism is applied to the embedding vector output from the Embedding layer to calculate the attention weights between elements in the sequence, generating an attention output. Then, the attention output is input into a one-dimensional convolutional layer for dimensionality reduction. This one-dimensional convolutional layer uses a convolution operation with a kernel size of 1, with the input channel number equal to the model dimension and the output channel number half that of the model dimension, achieving feature dimensionality reduction. Subsequently, the ProbSparse self-attention mechanism is applied again to further extract high-level features. Finally, the output is processed by a normalization layer. The normalization layer uses LayerNormalization to normalize the features, accelerating model training and improving model stability. The residual structure adds the input and output, preventing gradient vanishing and improving model training performance.

[0090] The encoder extracts high-level features from the input sequence layer by layer by stacking multiple coding layers, such as 3 or 6 layers, to generate the encoder output. The encoder output is a high-dimensional feature representation of the input sequence, containing both global and local information of the sequence, and provides input to the decoder.

[0091] Decoder: The decoder is responsible for generating a prediction sequence based on the encoder output and the ground truth sequence. The decoder consists of multiple stacked decoding layers, each containing a masked multi-head ProbSparse self-attention structure, a multi-head attention structure, and a residual connection structure.

[0092] The decoder takes as input the embedding vector of the ground truth sequence and the encoder output. The ground truth sequence is a continuation of historical traffic data, used to guide the decoder in generating the prediction sequence. The decoder uses a masking mechanism to ensure that only historical information is visible during prediction, preventing information leakage. Specifically, the masked multi-head ProbSparse self-attention performs self-attention calculation on the decoder's input sequence, but when calculating the attention weights, the attention weights for future time steps are set to negative infinity. This ensures that the model can only see information from historical time steps when predicting the current time step, and cannot see information from future time steps, thus preventing information leakage.

[0093] Multi-head attention performs cross-attention calculations on the decoder and encoder outputs. Specifically, multi-head attention uses the decoder output as the query vector Q, the encoder output as the key vector K and value vector V, calculates the attention weights between the query vector and the key vector, and then performs a weighted sum of the value vectors based on these attention weights to generate the cross-attention output. Through cross-attention, the decoder can extract information relevant to the current prediction time from the encoder output, improving prediction accuracy.

[0094] The residual connection structure adds the input and output, preventing gradient vanishing and improving model training performance. The decoder generates high-level feature representations of the predicted sequence layer by layer by stacking multiple decoding layers, such as 3 or 6 layers.

[0095] The final output of the decoder is used by a fully connected layer to generate a prediction sequence. The fully connected layer maps the high-dimensional feature representation of the decoder output to predicted values, with the output dimension being the number of predicted variables. For example, if the predicted variable is the traffic size per frame, the output dimension is 1; if the predicted variables are multiple variables such as VLAN ID, IP address, service ID, and traffic size per frame, the output dimension is the number of variables.

[0096] Model training: Model training is not limited to in-vehicle central computing units; it can also be conducted in the cloud. The training process includes steps such as data preparation, model initialization, forward propagation, loss function calculation, backpropagation, and parameter updates.

[0097] The first step is data preparation. The onboard central processing unit queries historical traffic data from the time-series database to construct a training dataset. The training dataset contains multiple training samples, each containing an input sequence and a target sequence. The input sequence is historical traffic data of length L, and the target sequence is future traffic data of length H. For example, if the input sequence length L is 60, it corresponds to one data point every 500ms for the traffic data of the most recent 30 seconds, for a total of 60 data points; the target sequence length H is 20, it corresponds to one data point every 500ms for the traffic data of the next 10 seconds, for a total of 20 data points.

[0098] The second step is model initialization. The onboard central processing unit initializes the parameters of the Informer model, including the parameters of the embedding layer, encoder, and decoder. Parameter initialization uses Xavier initialization or He initialization methods to ensure that the initial values ​​of the parameters are reasonably distributed, thus accelerating model training.

[0099] The third step is forward propagation. The onboard central processing unit inputs the input sequence of the training samples into the Informer model, which then passes through the embedding layer, encoder, and decoder to generate the predicted sequence.

[0100] The fourth step is loss function calculation. The onboard central processing unit calculates the loss function between the predicted sequence and the target sequence. This invention uses the root mean square error (RMSE) and the mean absolute error (MAE) as the loss function. The formulas for calculating RMSE and MAE are as follows:

[0101]

[0102] Where N is the total number of observations, and These are the true value and the predicted value of observation i.

[0103] RMSE penalizes larger prediction errors more severely, while MAE penalizes all prediction errors equally. By using both RMSE and MAE as loss functions, the model can reduce both the average error and the maximum error, thereby improving prediction accuracy.

[0104] The fifth step is backpropagation. The onboard central processing unit calculates the gradient of the model parameters based on the loss function, and uses the backpropagation algorithm to propagate the gradient from the output layer to the input layer, calculating the gradient of each parameter.

[0105] Step 6: Parameter Update. The onboard central processing unit updates the model parameters based on the parameter gradient, using the Adam optimizer to adaptively adjust the learning rate, accelerating model training and improving model stability.

[0106] The onboard central processing unit repeats the above forward propagation, loss function calculation, backpropagation, and parameter update steps until the model converges or reaches the preset number of training epochs. The criterion for model convergence is that the loss function on the validation set no longer decreases for several consecutive epochs.

[0107] During training, the onboard central processing unit sets the `features` parameter of the Informer model to `M` to perform multivariate prediction tasks. The `features` parameter represents the number of variables the model predicts; setting it to `M` means the model predicts `M` variables simultaneously. For example, if the predicted variables are 7 variables such as VLAN ID, IP address, service ID, and frame size, then the `features` parameter is set to 7. Through multivariate prediction, the model can simultaneously predict multiple traffic features, improving the comprehensiveness and accuracy of the prediction.

[0108] Through the above training process, the vehicle-mounted central processing unit completes the training of the Informer deep learning model, which can accurately predict future traffic data based on historical traffic data.

[0109] Step S202: Load the trained Informer model.

[0110] The trained Informer model is converted into a low-power, lightweight format that can run efficiently on the central processing unit. Through model compression, computation optimization, and memory reduction, its deployment efficiency in resource-constrained environments is improved, ultimately achieving integration on the central processing unit.

[0111] Step S203: Determine whether the vehicle status meets the activation conditions for dynamic adjustment.

[0112] The onboard central processing unit comprehensively determines whether to activate deep learning prediction and dynamic adjustment of TSN parameters based on multi-dimensional triggering conditions of the vehicle's operating status. The key technology in this step lies in accurately identifying changes in the vehicle's operating status through multi-source information fusion, intelligently determining the timing for dynamic adjustment of TSN parameters, avoiding frequent triggering that would waste system resources, and ensuring timely activation of dynamic adjustment in critical scenarios.

[0113] The dynamic adjustment activation conditions include scenarios such as entering or leaving a highway, entering a congested section of road, severe weather, driver change, launching a high-load infotainment application, and pre-activation of automatic emergency braking. The triggering reasons, signal sources, and technical implementations for each scenario are described in detail below.

[0114] Table 2 Model Predicted Activation Conditions

[0115] First, entering or leaving the highway.

[0116] Triggering reason: When a vehicle enters a highway, the autonomous driving system will activate the highway driving assistance function, causing a sharp increase in network traffic demand in a short period of time. It is necessary to adjust the TSN parameters in advance to reserve bandwidth for the highway driving assistance function. When the vehicle leaves the highway, the autonomous driving system will deactivate the highway driving assistance function, and network traffic demand will decrease. It is necessary to adjust the TSN parameters again to release reserved bandwidth.

[0117] Signal Sources: The navigation system uses high-precision maps and route planning to determine whether a vehicle is about to enter or leave the highway. Specifically, based on the vehicle's current location and direction of travel, the navigation system queries the high-precision map for road type information. When it detects that a vehicle is about to enter the highway from a regular road or leave the highway onto a regular road, the navigation system sends an entry or exit signal to the vehicle's central processing unit. The camera determines whether a vehicle is about to enter or leave the highway by recognizing road signs such as highway entrance or exit signs. Specifically, the camera captures images of the road ahead and uses image recognition algorithms to detect road signs. When it detects a highway entrance or exit sign, the camera sends an entry or exit signal to the vehicle's central processing unit.

[0118] Technical implementation: The onboard central processing unit subscribes to signals from the navigation system and cameras. When it receives signals of entering or leaving the highway, it sets a dynamic adjustment activation flag, triggering traffic prediction and dynamic adjustment of TSN parameters.

[0119] Second, enter congested sections of road.

[0120] Triggering reason: When a vehicle enters a congested section of road, it needs to frequently process close-range following and pedestrian detection data. The network traffic is mainly short-cycle, high-frequency data, so the TSN parameters need to be adjusted to allocate bandwidth for short-cycle, high-frequency data.

[0121] Signal sources: Navigation systems determine whether a vehicle is about to enter a congested section by using real-time traffic information. Specifically, the navigation system obtains real-time traffic information from a cloud server, queries the congestion status of the road ahead based on the vehicle's current location and direction of travel, and sends an entry signal to the vehicle's central processing unit when congestion is detected. V2X (Vehicle-to-Everything) systems determine whether a vehicle is about to enter a congested section by receiving congestion messages broadcast by other vehicles or roadside equipment. Specifically, the V2X system receives CAM (Camera-based Collaborative Awareness) messages broadcast by other vehicles or DENM (Distributed Environment Notification) messages broadcast by roadside equipment. When a congestion message is detected, the V2X system sends an entry signal to the vehicle's central processing unit. Radar and cameras determine whether a vehicle is about to enter a congested section by detecting the distance to vehicles ahead. Specifically, radar measures the distance to vehicles ahead, and cameras identify the number of vehicles ahead. When the distance to vehicles ahead is less than a threshold (e.g., 20 meters) and the number of vehicles ahead is greater than a threshold (e.g., 5 vehicles), radar and cameras send an entry signal to the vehicle's central processing unit.

[0122] Technical implementation: The onboard central processing unit subscribes to signals from the navigation system, V2X system, radar, and camera. When it receives a signal to enter a congested section, it sets a dynamic adjustment activation flag to trigger traffic prediction and dynamic adjustment of TSN parameters.

[0123] Third, severe weather.

[0124] Triggering reason: When a vehicle encounters severe weather such as heavy rain or snow, the perception capabilities of sensors such as cameras and radar decrease, requiring increased redundant transmission and data fusion of sensor data, increasing network traffic demand, and necessitating the adjustment of TSN parameters to allocate more bandwidth to sensor data.

[0125] Signal sources: Rain and light sensors determine whether severe weather is encountered by measuring rainfall and light intensity. Specifically, the rain sensor measures rainfall per unit time; when the rainfall exceeds a threshold such as 10 mm per hour, the rain sensor sends a heavy rain signal to the vehicle's central processing unit. The light sensor measures ambient light intensity; when the light intensity is less than a threshold such as 100 lux, the light sensor sends a low light signal to the vehicle's central processing unit. Cloud-based weather services determine whether severe weather is encountered by pushing real-time weather information. Specifically, the vehicle's central processing unit obtains real-time weather information for the vehicle's current location from a cloud-based weather server; when severe weather such as heavy rain, heavy snow, or dense fog is detected, the cloud-based weather service sends a severe weather signal to the vehicle's central processing unit.

[0126] Technical implementation: The onboard central processing unit subscribes to signals from rain sensors, light sensors, and cloud-based weather services. When it receives severe weather signals, it sets a dynamic adjustment activation flag to trigger traffic forecasting and dynamic adjustment of TSN parameters.

[0127] Fourth, the driver was replaced.

[0128] Triggering reason: When the driver changes, the new driver's driving habits and preferences may be different. The vehicle system needs to relearn the driver's characteristics, and the network traffic pattern may change. The TSN parameters need to be adjusted to adapt to the new traffic pattern.

[0129] Signal Sources: The biometric system determines whether the driver has been changed through facial recognition. Specifically, the vehicle's camera captures the driver's facial image and compares it with pre-stored driver facial features using a facial recognition algorithm. When a mismatch is detected, the biometric system sends a driver change signal to the vehicle's central processing unit. The smart key or UWB (Ultra-Wideband) system determines whether the driver has been changed by detecting the key or UWB tag. Specifically, the vehicle detects the unique identifier of the smart key or UWB tag. When a mismatch is detected, the smart key or UWB system sends a driver change signal to the vehicle's central processing unit. The mobile phone Bluetooth pairing system determines whether the driver has been changed by detecting the mobile phone's Bluetooth device. Specifically, the vehicle detects the MAC address of the mobile phone's Bluetooth device. When a mismatch is detected, the mobile phone Bluetooth pairing system sends a driver change signal to the vehicle's central processing unit.

[0130] Technical implementation: The vehicle's central processing unit subscribes to signals from the biometric system, smart key, or UWB system and the mobile phone Bluetooth pairing system. When it receives a driver change signal, it sets a dynamic adjustment activation flag, triggering traffic prediction and dynamic adjustment of TSN parameters.

[0131] Fifth, launch high-load infotainment applications.

[0132] Triggering reason: When users launch high-load infotainment applications such as video playback applications, the network traffic demand increases sharply, requiring adjustment of TSN parameters to allocate bandwidth to infotainment applications, while ensuring the transmission priority of autonomous driving perception data.

[0133] Signal Sources: The central control screen system monitors user operations to determine whether the user has launched a high-load infotainment application. Specifically, the central control screen system monitors user clicks on the video playback application icon. When it detects a click, the central control screen system sends a signal to the vehicle's central processing unit to launch the high-load infotainment application. The voice recognition system recognizes user voice commands to determine whether the user has launched a high-load infotainment application. Specifically, the voice recognition system recognizes user voice commands such as "play video." When it detects a user issuing a video playback command, the voice recognition system sends a signal to the vehicle's central processing unit to launch the high-load infotainment application.

[0134] Technical implementation: The vehicle's central processing unit subscribes to signals from the central control screen system and the voice recognition system. When it receives a signal to start a high-load infotainment application, it sets a dynamically adjusted activation flag, triggering traffic prediction and dynamic adjustment of TSN parameters.

[0135] Sixth, automatic emergency braking pre-activation.

[0136] Triggering reason: When the forward fusion perception system detects a collision risk, the automatic emergency braking (AEB) system will be pre-activated. Emergency control data needs to be transmitted to the actuator in a very short time. Therefore, the TSN parameter needs to be adjusted to allocate the highest priority and maximum bandwidth to the emergency control data.

[0137] Signal Source: The forward-facing fusion perception system determines the existence of collision risk by fusing radar and camera data. Specifically, the forward-facing fusion perception system calculates the distance to the obstacle ahead, the relative speed, and the time to collision (TTC). When the TTC is less than a threshold, such as 2 seconds, the forward-facing fusion perception system sends a collision warning signal to the vehicle's central processing unit.

[0138] Technical implementation: The onboard central processing unit subscribes to the signals of the forward fusion perception system. When a collision warning signal is received, it sets a dynamic adjustment activation flag to trigger traffic prediction and dynamic adjustment of TSN parameters.

[0139] Through the multi-dimensional triggering conditions of the above six scenarios, the vehicle central processing unit can accurately identify changes in vehicle operating status and intelligently determine the timing for dynamic adjustment of TSN parameters. When the vehicle status does not meet the dynamic adjustment activation conditions, the vehicle central processing unit executes step S2031; when the vehicle status meets the dynamic adjustment activation conditions, the vehicle central processing unit executes step S2032.

[0140] Step S2031: The vehicle status does not meet the activation conditions for dynamic adjustment.

[0141] When the vehicle status does not meet the activation conditions for dynamic adjustment, the onboard central processing unit extends the judgment period to 1 second and enters monitoring mode, recording only critical events and logs to reduce system resource consumption. The key technology of this step lies in avoiding frequent judgments that waste system resources by extending the judgment period and entering monitoring mode, while ensuring timely detection when the vehicle status changes.

[0142] Specifically, the vehicle-mounted central processing unit (CNU) extends the judgment period from the default period, such as 100ms, to 1 second, reducing the judgment frequency and minimizing CPU resource consumption. The CNU enters monitoring mode, refraining from traffic prediction and dynamic adjustment of TSN parameters, and only records key events such as vehicle position changes, speed changes, and sensor status changes, along with logs, to provide data support for subsequent analysis. Every second, the CNU re-evaluates whether the vehicle status meets the dynamic adjustment activation conditions; if so, it exits monitoring mode and executes step S2032.

[0143] Through the above mechanism, the on-board central processing unit can effectively reduce system resource consumption when the vehicle status does not meet the activation conditions for dynamic adjustment, while ensuring that dynamic adjustment can be detected and activated in a timely manner when the vehicle status changes.

[0144] Step S2032: The vehicle status meets the activation conditions for dynamic adjustment.

[0145] When the vehicle status meets the activation conditions for dynamic adjustment, the onboard central processing unit sets a status flag and initiates the following concurrent tasks. The key technology in this step lies in achieving parallel execution of traffic prediction and configuration distribution through a concurrent task mechanism, thereby improving system response speed, while avoiding frequent triggering that would waste system resources through monitoring threads.

[0146] Task 1: Main thread.

[0147] The main thread is responsible for performing traffic prediction and dynamic adjustment of TSN parameters. The specific process is as follows: The first step is to connect to the database. The onboard central processing unit establishes a connection with the time-series database, preparing to query historical time-series data.

[0148] The second step is to obtain historical time-series data for the most recent 30 seconds. The vehicle's central processing unit queries the traffic characteristic data for the 30 seconds preceding the current time through the time window query interface of the time-series database. The query result is a time-series sequence containing 60 data points, one data point every 500ms. Each data point contains seven feature dimensions: VLAN ID, IP address, service ID, flow identifier ID, traffic size per frame, timestamp, and priority.

[0149] The third step is data cleaning and normalization. The onboard central processing unit (CPU) cleans the retrieved historical time-series data, removing outliers and missing values. Outlier detection uses a 3-standard-deviation method, calculating the mean and standard deviation for each feature dimension and removing data points exceeding the mean ± 3 standard deviations. Missing values ​​are filled using linear interpolation. After data cleaning, the CPU normalizes the data, mapping the values ​​of each feature dimension to the range of 0 to 1. Normalization eliminates numerical differences between different feature dimensions, improving model training and inference performance.

[0150] The fourth step involves inputting the loaded Informer deep learning model for inference. The onboard central processing unit inputs the cleaned and normalized historical time-series data into the loaded Informer deep learning model, performs model inference, and predicts traffic data for the next 10 seconds. The model inference process includes forward propagation calculations of the embedding layer, encoder, and decoder. The output is a prediction sequence of length 20, with one data point every 500ms. Each data point contains predicted values ​​for seven feature dimensions: VLAN ID, IP address, service ID, flow identifier ID, traffic size per frame, timestamp, and priority.

[0151] The fifth step involves dividing the predicted data for the next 10 seconds into 20 time windows of 500ms each. The onboard central processing unit divides the model's output prediction sequence into 20 time windows in chronological order, with each time window corresponding to traffic prediction data over a 500ms period. By dividing the data into time windows, the onboard central processing unit can more precisely identify high-frequency key signals, providing fine-grained traffic prediction data for subsequent bandwidth decisions.

[0152] The sixth step involves transmitting the prediction results to the bandwidth decision and parameter generation module. The onboard central processing unit transmits the predicted traffic data for 20 time windows to the bandwidth decision and parameter generation module, triggering bandwidth decision and TSN parameter calculation.

[0153] Task 2: Monitor the thread.

[0154] The monitoring thread is responsible for monitoring the model inference status to avoid frequent model inference triggers that could waste system resources. The specific process is as follows: The first step is to set an inference cooldown flag when the activation conditions are met and the model inference is completed, with a cooldown time of 10 seconds.

[0155] The second step is to prevent the monitoring thread from triggering the model inference function during the cooling-off period, even if the vehicle status meets the dynamic adjustment activation conditions again. This avoids frequent triggering and waste of system resources.

[0156] Third, after the cooldown period ends, the monitoring thread clears the inference cooldown flag, allowing the model inference function to be triggered again.

[0157] Through the aforementioned monitoring thread mechanism, the vehicle central processing unit avoids frequently triggering model inference in a short period of time after the activation conditions are met, effectively reducing system resource consumption, while ensuring that it can respond to vehicle status changes again after the cooling time ends.

[0158] Through the above traffic prediction and decision triggering steps, the vehicle central processing unit realizes vehicle network traffic prediction based on the Informer deep learning model. Combined with multi-dimensional triggering conditions of vehicle operating status, it intelligently judges the timing of dynamic adjustment of TSN parameters, providing accurate traffic prediction data for subsequent bandwidth decision-making and parameter generation.

[0159] Step S300: Bandwidth decision and parameter generation.

[0160] like Figure 2 and Figure 6 As shown, the bandwidth decision and parameter generation step dynamically calculates and allocates bandwidth for each queue based on the traffic data output by the prediction model and a preset bandwidth decision feature mapping table, generating TSN scheduling parameters. The design principle of this step is based on the priority queue bandwidth allocation strategy and the TSN scheduling parameter calculation method. By reserving sufficient bandwidth for high-priority queues and rationally allocating remaining bandwidth to ordinary priority queues, it achieves optimized allocation of network resources.

[0161] Step S301: Obtain the features of the output data of the prediction model.

[0162] The onboard central processing unit acquires the predicted traffic data features output by the Informer deep learning model. The data features output by the prediction module include six dimensions: VLAN ID, IP address, service ID, flow identifier ID, total traffic volume, and priority.

[0163] Table 3. Output characteristics of the prediction module

[0164] Specifically, the onboard central processing unit receives traffic data for 20 predicted time windows from the traffic prediction and decision triggering module. Each time window contains multiple traffic data records, and each traffic data record contains six fields: VLAN ID, IP address, service ID, flow identifier ID, total traffic size, and priority. Among them, the VLAN ID is used to distinguish functional domains, the IP address is used to accurately identify specific devices within a functional domain, the service ID is used to distinguish service types, the flow identifier ID is used to identify audio and video streams, the total traffic size is in Mbps representing the predicted traffic size, and the priority value ranges from 0 to 7 to represent the service quality level of the traffic.

[0165] Based on the aforementioned data characteristics and in conjunction with a preset bandwidth decision feature mapping table, the on-board central processing unit performs subsequent bandwidth decisions and parameter generation.

[0166] Step S302: Combine the preset bandwidth decision features.

[0167] The onboard central processing unit reads the pre-configured bandwidth decision feature mapping table and combines it with traffic identification features to assist in bandwidth decision-making and TSN parameter calculation. The bandwidth decision feature mapping table includes five dimensions: maximum frame length, period, maximum latency requirement, whether it is reliable traffic, and a list of data path switches for each type of traffic.

[0168] Table 4 Bandwidth Decision Characteristics

[0169] First, the maximum frame length for each type of traffic. The maximum frame length is measured in bytes and represents the maximum length of a single packet for that type of traffic. The maximum frame length is used for credit calculation in CBS parameter calculation. For example, the maximum frame length for camera image data is 1500 bytes, and the maximum frame length for radar point cloud data is 2000 bytes.

[0170] Second, the period. The period is measured in milliseconds (ms) and represents the transmission cycle of this type of traffic. The period is used to determine the total gating scheduling cycle in TAS parameter calculation. For example, the period for vehicle status monitoring data is 100ms, and the period for camera image data is 33ms, corresponding to 30 frames per second.

[0171] Third, maximum latency requirement. The maximum latency requirement is measured in milliseconds (ms) and represents the maximum end-to-end latency requirement for this type of traffic. The maximum latency requirement is used to determine the total gating scheduling cycle in TAS parameter calculation. For example, the maximum latency requirement for autonomous driving perception data is 50 microseconds, and the maximum latency requirement for vehicle status monitoring data is 500 microseconds.

[0172] Fourth, is it reliability traffic? The "Reliability Traffic" setting is either "Yes" or "No," indicating whether this type of traffic requires redundant path transmission to improve reliability. For safety-critical traffic such as autonomous driving perception data and emergency control data, setting it to "Yes" enables redundant path transmission; for non-safety-critical traffic such as infotainment data, setting it to "No" disables redundant path transmission.

[0173] Fifth, the data path switch list. The data path switch list is a list of switch numbers, indicating the switching devices that the transmission path of this type of traffic passes through. The data path switch list is used for traffic path binding to ensure that traffic is transmitted along a specified path. For example, the data path switch list for camera image data might be Switch 1, Switch 2, Switch 3, indicating that the camera image data originates from the camera, passes through Switch 1, Switch 2, and Switch 3 in sequence, and finally reaches the central computing platform.

[0174] The vehicle-mounted central processing unit (CLU) maps the traffic data characteristics output by the prediction model to specific bandwidth decision parameters through a bandwidth decision feature mapping table. Specifically, based on the VLAN ID, IP address, service ID, and flow identifier ID in the traffic data characteristics, the CLU queries the bandwidth decision feature mapping table for the corresponding maximum frame length, period, maximum latency requirement, whether it is reliable traffic, and the list of data path switches. The query results are then combined with the traffic data characteristics to form complete bandwidth decision input data.

[0175] Step S303: Calculation of flow rate and cycle based on multi-window prediction results.

[0176] The onboard central processing unit processes the traffic prediction data for 20 time windows output by the prediction module. The key technology in this step is to reserve sufficient bandwidth and time windows for high-priority queues through a differentiated multi-window data aggregation strategy, ensuring the transmission priority of safety-critical traffic, while rationally allocating bandwidth to ordinary priority queues to improve bandwidth utilization.

[0177] Specifically, the onboard central processing unit adopts the following strategies according to priority: For high-priority queues --- priority 5 to 7.

[0178] Priority is not directly involved in the calculation. Instead, queues are first distinguished by priority, and each queue calculates CBS and TAS based on parameters such as its period and bandwidth.

[0179] The traffic value is taken as the maximum value of the corresponding queue within 20 windows. Specifically, the onboard central processing unit traverses 20 time windows, and for each high-priority queue, finds the maximum traffic value of that queue within the 20 time windows, using it as the calculated traffic value for that queue. By taking the maximum value, the onboard central processing unit reserves sufficient bandwidth margin for high-priority queues, ensuring that even under peak traffic conditions, high-priority queues still have enough bandwidth to transmit data, avoiding data loss or increased latency due to insufficient bandwidth.

[0180] The calculation of high-priority queue traffic values ​​in this step: calculate the bandwidth of priorities 5, 6, and 7 in the 20 windows respectively, and select the maximum calculated value for each priority.

[0181] The period value is taken as the minimum value of the corresponding queue within 20 windows. Specifically, the onboard central processing unit traverses 20 time windows, and for each high-priority queue, finds the minimum period value of that queue within the 20 time windows, which is used as the calculation period value for that queue. By taking the minimum value, the onboard central processing unit allocates shorter transmission periods to high-priority queues, increasing data transmission frequency, reducing end-to-end latency, and meeting the real-time requirements of high-priority traffic.

[0182] The calculation cycle value of the high-priority queue determined in this step is used for the calculation of the total gating scheduling cycle in the subsequent TAS parameter calculation.

[0183] For ordinary priority queues --- priority 0 to 4.

[0184] The traffic value is calculated as the average of the corresponding queues across 20 windows. Specifically, the onboard central processing unit (CPU) iterates through 20 time windows and, for each ordinary priority queue, calculates the average traffic value of that queue across the 20 time windows, using this average as the calculated traffic value for that queue. By taking the average, the CPU allocates appropriate bandwidth to ordinary priority queues, avoiding excessive bandwidth reservation that leads to waste, while ensuring that ordinary priority queues have sufficient bandwidth to transmit data, thus improving bandwidth utilization.

[0185] The period value is taken as the average of the corresponding queues across 20 windows. Specifically, the onboard central processing unit traverses 20 time windows, and for each ordinary priority queue, calculates the average of the period values ​​for that queue across the 20 time windows, using this average as the calculated period value for that queue. By taking the average, the onboard central processing unit allocates a suitable transmission period to the ordinary priority queues, avoiding excessively frequent transmissions that could lead to network congestion while ensuring that the ordinary priority queues can send data in a timely manner.

[0186] How the calculation cycle values ​​of different queues are used in the subsequent TAS calculation is clearly explained in the subsequent step S3051. Here is an example: Suppose we have a periodic data A with a period of 10ms. We need to design a gate scheduling strategy. Gated scheduling has two parameters: total scheduling time and queue scheduling time. Queue scheduling time is the time each queue's gate is allowed to open and send packets. Total scheduling time is the time it takes for all queues to complete one full execution according to the configured gate list.

[0187] The first design principle is that the total scheduling time should be less than the transmission period of data A, for the following reasons: Assuming the total scheduling time is designed to be 20ms, the queue for data A opens once within 0-10ms. However, within the time span of 10-20ms, data A (with a period of 10ms) also needs to transmit a message. At this time, the gate for data A is closed. This data will either be discarded or stored in memory to be transmitted together when the gate opens again (there will be a 10ms delay). Neither of these situations is ideal.

[0188] The second design principle is that the total scheduling period is a divisible number of the data period, for the following reasons: Assuming we design the total scheduling period to meet the first requirement—less than the data A transmission period, but not divisible by 10ms (choosing 3ms)—the gate for data A opens within the first 100µs of each 3ms scheduling period. The first data A packet is successfully transmitted within 0-100µs of the first total scheduling period. The second packet, 10ms apart from the first, needs to be transmitted after 1000µs of the fourth total scheduling period. However, since the gate is opened within 0-100µs, it has already closed by 1000µs, and the second packet will again face the problem of being dropped or waiting.

[0189] Based on these two principles, the total scheduling time can be calculated.

[0190] Through the aforementioned differentiated multi-window data aggregation strategy, the onboard central processing unit reserves sufficient bandwidth and time windows for high-priority queues to ensure the transmission priority of safety-critical traffic, while rationally allocating bandwidth to ordinary priority queues to improve bandwidth utilization.

[0191] Step S304: Allocate bandwidth according to priority.

[0192] The onboard central processing unit allocates bandwidth according to queue priorities and preset bandwidth allocation rules. The key technology in this step is to optimize network resource allocation by reserving 110% bandwidth for high-priority queues and limiting the proportion of total bandwidth for high-priority queues, thus ensuring the transmission priority of high-priority traffic while preventing excessive bandwidth consumption by high-priority traffic from causing ordinary priority traffic to be unable to be transmitted.

[0193] Step S3041: High-priority bandwidth allocation principle.

[0194] For high-priority queues with priorities 5 to 7, the onboard central processing unit allocates bandwidth of 110% of the calculated total high-priority traffic, and the total high-priority bandwidth occupies at least 10% and no more than 80% of the total bandwidth. The specific allocation is based on the calculated traffic ratio for each queue.

[0195] The bandwidth allocation formula is as follows:

[0196]

[0197] in, To allocate the total bandwidth to high priority, For the bandwidth allocated to high-priority queue i, To calculate the high-priority total flow, To calculate the bandwidth of high-priority queue i, This represents the total bandwidth of the link.

[0198] The technical meaning of the above formula is as follows: First, This indicates that 110% of the bandwidth is reserved for the high-priority queue. By reserving 110% of the bandwidth, the onboard central processing unit provides sufficient bandwidth margin for the high-priority queue, ensuring that the high-priority queue still has enough bandwidth to transmit data under traffic fluctuations, and avoiding data loss or increased latency due to insufficient bandwidth.

[0199] second, This indicates that at least 10% of the total bandwidth is allocated to high-priority traffic. By setting a minimum percentage, the onboard central processing unit ensures that even if high-priority traffic is low, a certain amount of bandwidth is reserved for the high-priority queue to guarantee the transmission priority of high-priority traffic.

[0200] third, This indicates that the total bandwidth for high-priority traffic should not exceed 80% of the total bandwidth. By setting a maximum percentage, the onboard central processing unit avoids excessive bandwidth consumption by high-priority traffic, which could prevent the transmission of ordinary-priority traffic, thus ensuring a fair allocation of network resources.

[0201] fourth, This represents the proportion of traffic in high-priority queue i to the total high-priority traffic. By allocating bandwidth proportionally, the onboard central processing unit fairly allocates the total high-priority bandwidth according to the traffic requirements of each high-priority queue, preventing any high-priority queue from excessively consuming bandwidth.

[0202] Through the above bandwidth allocation rules, the on-board central processing unit reserves sufficient bandwidth for high-priority queues, ensuring the transmission priority of safety-critical traffic, while avoiding excessive bandwidth consumption by high-priority traffic, thus ensuring the fair allocation of network resources.

[0203] Step S3042: Bandwidth allocation principle for normal priority For ordinary priority queues with priorities of 0 to 4, the onboard central processing unit shares the remaining bandwidth and allocates it according to the traffic ratio calculated for each queue.

[0204] The bandwidth allocation formula is as follows:

[0205]

[0206] in, The total bandwidth allocated to normal priority, For the bandwidth allocated to the normal priority queue i, For calculating the total flow rate of normal priority, Let be the bandwidth of the ordinary priority queue i.

[0207] The technical meaning of the above formula is as follows: First, This indicates that the ordinary priority queues share the remaining bandwidth. By sharing the remaining bandwidth, the onboard central processing unit can fully utilize the remaining bandwidth and improve bandwidth utilization while ensuring the transmission priority of high-priority traffic.

[0208] second, This represents the proportion of traffic in ordinary priority queue i to the total ordinary priority traffic. By allocating bandwidth proportionally, the onboard central processing unit fairly allocates the total bandwidth for ordinary priority queues based on their traffic demands, preventing any particular ordinary priority queue from over-consuming bandwidth.

[0209] Based on the above bandwidth allocation rules, the on-board central processing unit can reasonably allocate the remaining bandwidth to the ordinary priority queue, making full use of the remaining bandwidth and improving bandwidth utilization while ensuring the transmission priority of high-priority traffic.

[0210] Step S305: Calculate the TSN scheduling parameters.

[0211] The onboard central processing unit calculates the TSN scheduling parameters based on the bandwidth allocation results. The calculation of TSN parameters involves two protocols: the gate-based scheduling policy TAS and the reputation-based traffic scheduling policy CBS. The key technical aspect of this step is to allocate fixed time windows to high-priority queues through TAS and control the traffic transmission rate of ordinary priority queues through CBS, thereby achieving hard real-time assurance for high-priority traffic and flexible scheduling of ordinary priority traffic.

[0212] The onboard central processing unit first calculates the TAS parameters for the following reasons: The role of TAS gating is to ensure whether traffic can be sent. Only when the gate is allocated a time for the queue to open can the queue send traffic. Reasonable TAS planning can provide hard and interference-free transmission guarantee for periodic critical messages.

[0213] Step S3051: Calculate TAS parameters.

[0214] The onboard central processing unit calculates the TAS parameters for high-priority queues. The TAS parameters include the total gating scheduling cycle and the queue opening time.

[0215] Gating total scheduling cycle The overall gating scheduling period is determined based on the periodic characteristics of the high-priority queues. Specifically, the onboard central processing unit sets the overall gating scheduling period to an integer divisible by the smallest period among all high-priority queues to ensure that critical data is sent periodically.

[0216] For example, assuming the high-priority queue contains three queues, with queue 1 having a period of 10ms, queue 2 having a period of 20ms, and queue 3 having a period of 30ms, then the minimum period among all high-priority queues is 10ms. The onboard central processing unit sets the total gating scheduling period to an integer divisible by 10ms, with selectable values ​​including 1ms, 2ms, 5ms, and 10ms. The onboard central processing unit comprehensively considers system resource consumption and scheduling accuracy to select an appropriate total gating scheduling period. For example, if 1ms is selected as the total gating scheduling period, then within 1ms, the onboard central processing unit allocates opening time for all high-priority queues, achieving periodic scheduling.

[0217] By setting the total gating scheduling period to an integer divisible by the smallest period among all high-priority queues, the onboard central processing unit ensures that critical data can be sent periodically, meeting real-time requirements.

[0218] Queue opening time The queue opening time is determined based on the proportion of the bandwidth allocated to the queue to the total bandwidth. Specifically, the onboard central processing unit calculates the opening time of queue i within a single gating scheduling cycle based on the proportion of the bandwidth allocated to high-priority queue i to the total link bandwidth.

[0219] The calculation formula is as follows:

[0220] in, Let be the opening time of queue i within a single gating total scheduling cycle. This is the total scheduling cycle for gating.

[0221] For example, assuming a data request on a 1000Mbps link requires 10Mbps of bandwidth, and the total gating scheduling time is set to 1ms, the data queue opening time is calculated as follows:

[0222] That is, the opening time of this data queue within a single gating total scheduling cycle of 1ms is 10 microseconds.

[0223] Based on the TAS parameter calculations mentioned above, the onboard central processing unit allocates a fixed time window to the high-priority queue, ensuring deterministic, low-latency transmission of safety-critical traffic.

[0224] Step S3052: CBS parameter calculation.

[0225] The onboard central processing unit calculates the CBS parameters for the ordinary priority queue. The CBS parameters are used for flow control of the ordinary priority queue within a uniform open time period. The formula for calculating the CBS parameters is as follows:

[0226]

[0227]

[0228]

[0229] in, Let i be the idle slope. Let i be the sending slope. The scheduling cycle for Qbv gating. This represents the cumulative door-opening time of queue i within a single scheduling cycle. Let i be the minimum reputation of queue i. Let i be the maximum reputation of queue i.

[0230] The technical meaning of the above formula is as follows: First, idle slope This represents the rate at which the reputation of queue i accumulates during idle periods. When queue i has no data to send, its reputation accumulates at an idle slope, and the accumulated reputation is used for subsequent data transmissions.

[0231] Second, the sending slope This represents the rate at which reputation is consumed by queue i when sending data. When queue i sends data, reputation is consumed at a sending slope, and the consumed reputation is equal to the bandwidth occupied by the data being sent.

[0232] Third, minimum credit This represents the lower limit of the reputation of queue i. When the reputation of queue i drops to the minimum, queue i stops sending data and waits for the reputation to accumulate to a positive value before resuming sending.

[0233] Fourth, utmost credibility This represents the reputation cap for queue i. When the reputation of queue i reaches the maximum, queue i stops accumulating reputation to avoid excessive reputation accumulation leading to sudden traffic spikes.

[0234] Using the CBS parameters mentioned above, the onboard central processing unit controls the traffic transmission rate of the ordinary priority queue, preventing ordinary priority traffic from occupying too much bandwidth and affecting the transmission of high priority traffic, while ensuring that ordinary priority traffic can fairly share the remaining bandwidth.

[0235] Through the above bandwidth decision and parameter generation steps, the on-board central processing unit dynamically calculates and allocates bandwidth for each queue based on the traffic data output by the prediction model and in conjunction with the preset bandwidth decision feature mapping table, generating TSN scheduling parameters to provide parameter input for subsequent configuration distribution.

[0236] Step S400: Configuration distribution and error handling.

[0237] like Figure 2 and Figure 7 As shown, the configuration distribution and error handling steps distribute TSN parameters to the switch via the NETCONF protocol, and an error handling and rollback mechanism is designed to ensure the reliability and stability of the system configuration. The design principle of this step is based on the NETCONF standard protocol for network device configuration management and the fault-tolerant mechanism for configuration error handling. Through standardized configuration distribution and automated error handling, the accuracy and reliability of TSN parameter configuration are ensured.

[0238] Step S401: Receive parameters and convert the format.

[0239] The onboard central processing unit receives the TSN parameters output by the bandwidth decision and parameter generation module, and fills the parameters into an XML template according to the built-in YANG model mapping relationship to generate standard NETCONF configuration data. The key technology in this step is to standardize the representation of TSN parameters by defining the data structure through the YANG model and formatting the configuration data using an XML template, which facilitates subsequent distribution to the switch via the NETCONF protocol.

[0240] Specifically, the received parameters are unstructured TSN parameters, including the TAS parameter gating total scheduling period, queue opening time, and CBS parameter idle slope, transmission slope, minimum reputation, and maximum reputation. The onboard central processing unit maps the TSN parameters into XML format according to the data structure defined by the YANG model.

[0241] The vehicle-mounted central processing unit (CLU) populates the TSN parameters into the XML template based on the YANG model mapping relationship. Specifically, the CLU iterates through the TSN parameters, queries the corresponding data structure in the YANG model for each parameter, generates the corresponding XML element according to the format defined in the XML template, and finally combines all the XML elements into complete XML configuration data.

[0242] In addition to the TAS and CBS parameters, the XML configuration file also contains the following fields: First, the TimeStamp is the timestamp at which the configuration takes effect. The TimeStamp represents the effective time of the TSN parameter configuration, measured in nanoseconds (ns). The onboard central processing unit calculates the timestamp of the configuration taking effect based on the system clock and populates it into the XML configuration file. Through the TimeStamp, the switch can ensure that the configuration takes effect at a specified time, achieving precise configuration synchronization.

[0243] Second, the SwitchID identifies the switch device. The SwitchID represents the target switch device configured in the TSN parameters and uses a unique identifier such as a MAC address or device number. The onboard central processing unit determines the target switch device configured in the TSN parameters based on the data path switch list and populates it into the XML configuration file.

[0244] Third, PortName identifies the switch port. PortName indicates the target switch port configured in the TSN parameters, using port names such as eth0 and eth1. The onboard central processing unit determines the target switch port configured in the TSN parameters based on the data path switch list and populates it into the XML configuration file.

[0245] Meanwhile, the onboard central processing unit adds transaction identifiers and version tags to the XML configuration files, supporting configuration tracking and management. The transaction identifier assigns a unique identifier to each configuration distribution, used to track the configuration distribution process and query the distribution results. The version tag records the configuration version number, used for configuration version management and rollback operations.

[0246] Through YANG model mapping and XML template population, the vehicle-mounted central processing unit converts TSN parameters into standard NETCONF configuration data, which is then distributed to the switch via the NETCONF protocol.

[0247] Step S402: Construct a NETCONF message and send it.

[0248] The onboard central processing unit constructs a NETCONF message containing an edit-config RPC call and sends it to the target switch via the NETCONF session channel. The key technical aspect of this step is to standardize the distribution of TSN parameters through the NETCONF protocol, ensuring the accuracy and reliability of the configuration.

[0249] The vehicle-mounted central processing unit constructs an edit-config RPC call, using the generated XML configuration data as the payload of the RPC call. Specifically, the vehicle-mounted central processing unit creates an edit-config RPC request message, sets the operation type to merge to indicate that the new configuration data will be merged into the existing configuration, and populates the config element of the RPC request message with the XML configuration data.

[0250] The onboard central processing unit encapsulates RPC messages, adding necessary protocol elements such as message identifiers and session identifiers. The message identifier assigns a unique identifier to each RPC request message, used to match RPC request and response messages. The session identifier identifies the NETCONF session, used to distinguish between different NETCONF sessions.

[0251] The onboard central processing unit (CPU) sends RPC messages to the target switch via a NETCONF session channel. The NETCONF session channel is established based on transport layer protocols such as SSH or TLS, providing a secure communication channel. During system startup, the CPU establishes a NETCONF session channel with the target switch; this channel remains persistent for subsequent configuration distribution.

[0252] The onboard central processing unit starts a distribution timer to monitor the configuration distribution process and sets a reasonable response timeout threshold. The distribution timer records the sending time of RPC request packets. If no RPC response packet is received after the response timeout threshold is exceeded, it is determined to be a configuration timeout error, triggering the error handling process. The response timeout threshold is set according to network latency and switch processing time, with typical values ​​ranging from 1 to 5 seconds.

[0253] Through the NETCONF protocol, the on-board central processing unit can standardize the distribution of TSN parameters to the switch, ensuring the accuracy and reliability of the configuration.

[0254] Step S403: Verify the configuration execution result.

[0255] The onboard central processing unit receives the configuration response message from the switch and verifies the configuration execution result. The key technology in this step is to determine whether the configuration was successfully executed by parsing the RPC response message, providing a basis for subsequent error handling.

[0256] Specifically, the onboard central processing unit receives RPC response messages from the switch via the NETCONF session channel. The RPC response message contains the response status and, possibly, error information. The response status is either "OK" (success) or "Error" (failure). A successful response indicates that the switch successfully performed the configuration operation; a failed response indicates that the switch failed to perform the configuration operation, and the RPC response message contains error information describing the reason for the failure.

[0257] The onboard central processing unit parses the RPC response message, extracting the response status and error information. If the response status is successful, the onboard central processing unit determines that the configuration was successfully executed, records the configuration parameters, and uploads the success log to the log server for subsequent analysis. The success log includes information such as configuration time, configuration parameters, target switch, and target port.

[0258] If the response status is failure, the vehicle central processing unit determines that the configuration has failed, activates the error handling process, and executes step S404.

[0259] By verifying the configuration execution results, the vehicle-mounted central processing unit can promptly detect configuration failures and initiate error handling mechanisms to ensure the reliability and stability of system configuration.

[0260] Step S404: Handle configuration failure scenarios.

[0261] When configuration delivery fails, the onboard central processing unit implements different error handling mechanisms based on the different error types. The key technology in this step is to improve the system's fault tolerance by classifying error types and designing targeted error handling mechanisms, ensuring that it can quickly recover to a stable state when configuration fails.

[0262] Error types include configuration timeout errors, invalid parameter errors, and communication exception errors. The detection methods and handling mechanisms for each error type are described in detail below.

[0263] Table 5 Configure and distribute error types

[0264] First, a configuration timeout error occurred.

[0265] Detection method: Timeout detection via a timer. After the onboard central processing unit sends an RPC request message, a timer is started. If no RPC response message is received after the response timeout threshold is exceeded, it is determined to be a configuration timeout error.

[0266] Handling Mechanism: The onboard central processing unit (CPU) retransmits the configuration request three times every 500ms. Specifically, when a configuration timeout error is detected, the CPU waits 500ms and then retransmits the RPC request message, repeating this process three times. If no RPC response message is received after three retransmissions, the configuration is considered to have failed, and a rollback operation is performed. The rollback operation restores the switch configuration to the last correctly configured parameter version. The CPU maintains a configuration history record, recording the parameter version and configuration time for each configuration. When a rollback is needed, the CPU queries the configuration history for the last correctly configured parameter version, constructs an edit-config RPC call, and restores the switch configuration to the last correctly configured parameter version. After the rollback is complete, the CPU records an error log and uploads it to a log server for subsequent analysis. The error log includes information such as error type, error time, target switch, target port, and error details.

[0267] Second, invalid parameter error.

[0268] Detection method: Invalid parameter detection is performed by the switch. When the switch receives an RPC request message, it parses the configuration data. If it finds that the configuration data does not conform to the data structure or constraints defined in the YANG model, it returns an invalid parameter error message.

[0269] Handling Mechanism: The onboard central processing unit directly performs the rollback operation. Specifically, when an invalid parameter error is detected, the onboard central processing unit determines that the configuration parameter is incorrect, does not resend, directly performs the rollback operation, restores the switch configuration to the previously correctly configured parameter version, records the error log, and uploads it to the log server.

[0270] Third, a communication error occurred.

[0271] Detection method: Detection is performed using NETCONF session loss. A communication error is identified when the NETCONF session channel between the vehicle's central processing unit and the switch is disconnected. Reasons for a disconnected NETCONF session channel include network failure, switch failure, or a break in the transport layer protocol connection.

[0272] Handling Mechanism: The onboard central processing unit switches transmission paths. Specifically, when a communication error is detected, the onboard central processing unit determines that the current transmission path is unavailable and attempts to switch to an alternate transmission path. The alternate transmission path is a pre-configured redundant communication path connected to the switch via a different network link. The onboard central processing unit re-establishes the NETCONF session channel through the alternate transmission path and resends the RPC request message. If the alternate transmission path is also unavailable, it is determined that the configuration has failed, a rollback operation is performed, the switch configuration is restored to the last correctly configured parameter version, and an error log is recorded and uploaded to the log server.

[0273] Through the above error handling mechanism, the vehicle central processing unit can take targeted measures according to the error type when configuration fails, improve the system's fault tolerance, ensure that it can quickly recover to a stable state when configuration fails, and guarantee the stable operation of the vehicle network.

[0274] Through the above configuration distribution and error handling steps, the vehicle-mounted central processing unit distributes TSN parameters to the switch via the NETCONF protocol, and has designed a comprehensive error handling and rollback mechanism to ensure the reliability and stability of TSN parameter configuration.

[0275] In summary, this invention achieves dynamic configuration of TSN parameters for vehicular networks based on deep learning through four major steps: data acquisition and feature extraction, traffic prediction and decision triggering, bandwidth decision and parameter generation, and configuration distribution and error handling. This effectively solves the technical problem that traditional static configuration schemes cannot proactively adapt to dynamic changes in vehicular network traffic, and significantly improves the determinism and real-time performance of vehicular networks under high load and sudden traffic scenarios.

[0276] Example 2 This embodiment discloses a deep learning-based dynamic configuration system for vehicle network TSN parameters.

[0277] A deep learning-based dynamic configuration system for vehicular network (TSN) parameters includes: The data acquisition module is configured to: capture vehicle network packets and extract the core features of the vehicle network packets; The data prediction module is configured to: predict vehicle network traffic data for future periods based on the extracted core features and using deep learning methods; The data partitioning module is configured to divide the vehicle network traffic data for future time periods into high-priority queues and ordinary-priority queues, and determine the traffic value and period value of different priority queues by combining the preset bandwidth decision feature mapping table. The parameter configuration module is configured to: allocate bandwidth to high-priority queues and ordinary-priority queues according to preset bandwidth allocation rules based on the determined traffic and period values, calculate TAS parameters for high-priority queues and CBS parameters for ordinary-priority queues, and complete the dynamic configuration of TSN parameters for the vehicle network.

[0278] Example 3 The purpose of this embodiment is to provide a computer-readable storage medium.

[0279] A computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the steps in the deep learning-based dynamic configuration method for vehicular network TSN parameters as described in Embodiment 1 of this disclosure.

[0280] Example 4 The purpose of this embodiment is to provide an electronic device.

[0281] An electronic device includes a memory, a processor, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps in the deep learning-based dynamic configuration method for vehicular network (TSN) parameters as described in Embodiment 1 of this disclosure.

[0282] The steps and methods involved in the apparatuses of Embodiments 2, 3, and 4 above correspond to those in Embodiment 1. For specific implementation details, please refer to the relevant description section of Embodiment 1. The term "computer-readable storage medium" should be understood as a single medium or multiple media including one or more instruction sets; it should also be understood as including any medium capable of storing, encoding, or carrying an instruction set for execution by a processor and enabling the processor to perform any of the methods in this invention.

[0283] Those skilled in the art will understand that the modules or steps of the present invention described above can be implemented using general-purpose computer devices. Optionally, they can be implemented using computer-executable program code, thereby allowing them to be stored in a storage device for execution by a computer device, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. The present invention is not limited to any particular combination of hardware and software.

[0284] While the specific embodiments of the present invention have been described above in conjunction with the accompanying drawings, this is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solutions of the present invention are still within the scope of protection of the present invention.

Claims

1. A deep learning-based method for dynamic configuration of TSN parameters in vehicular networks, characterized in that, Includes the following steps: Capture vehicle network packets and extract their core features; Based on the extracted core features, deep learning methods are used to predict in-vehicle network traffic data for future periods. The vehicle network traffic data for future time periods is divided into high-priority queues and ordinary-priority queues, and the traffic value and period value of different priority queues are determined by combining the preset bandwidth decision feature mapping table. Based on the determined traffic and period values, bandwidth is allocated to high-priority queues and ordinary-priority queues according to the preset bandwidth allocation rules. TAS parameters are calculated for high-priority queues and CBS parameters are calculated for ordinary-priority queues, thus completing the dynamic configuration of TSN parameters for the vehicular network.

2. The method for dynamic configuration of TSN parameters in vehicular networks based on deep learning as described in claim 1, characterized in that, The core characteristics of vehicular network packets include VLAN ID, IP address, service ID, flow identifier ID, frame size, timestamp, and priority, among which: VLAN ID, IP address, and service ID are used for accurate traffic identification and path differentiation; the size of each traffic frame is used for bandwidth timing prediction; timestamps are used to analyze traffic periodicity and trends; and priority is used to distinguish traffic patterns with different service qualities. For VLAN ID, IP address, service ID, and priority characteristics, read directly from the packet fields; For the traffic size characteristics of each frame, if the service length is a fixed value, it is pre-configured for writing and reading; if the length is a dynamic value, it is calculated in real time. For timestamp features, if the service contains a sending timestamp, it is read directly; otherwise, the receiving time of the vehicle's central processing unit is used as the timestamp.

3. The method for dynamic configuration of TSN parameters in a vehicular network based on deep learning as described in claim 1, characterized in that, Based on the vehicle's operating status, multi-dimensional triggering conditions are set to trigger the vehicle network traffic data for predicted future periods. These multi-dimensional triggering conditions include entering or leaving a highway, entering a congested section, severe weather, driver change, launching a high-load infotainment application, and pre-activation of automatic emergency braking scenarios. or, The Informer deep learning model is used to predict future vehicular network traffic data, including VLAN ID, IP address, service ID, flow identifier ID, total traffic volume, and priority. The Informer deep learning model includes an Embedding layer, an encoder, and a decoder. The Embedding layer includes TokenEmbedding, PositionalEmbedding, and TemporalEmbedding. The TokenEmbedding expands the sequence dimension through a one-dimensional convolution operation, the PositionalEmbedding performs absolute position encoding, and the TemporalEmbedding encodes time information to capture the trend and seasonality characteristics of traffic data. The encoder consists of stacked ProbSparse self-attention layers, one-dimensional convolutional layers, normalization layers, and residual structures. The decoder is composed of multiple stacked decoding layers, each layer containing a mask multi-head ProbSparse self-attention, multi-head attention, and residual connection structure.

4. The method for dynamic configuration of TSN parameters in a vehicular network based on deep learning as described in claim 1, characterized in that, The in-vehicle network traffic data for future time periods will be divided into a high-priority queue and a normal-priority queue, specifically as follows: Queues with priority levels 5 to 7 are classified as high-priority queues; Queues with priorities of 0 to 4 are classified as ordinary priority queues; or, The preset bandwidth decision feature mapping table specifically includes the maximum frame length, period, maximum latency requirement, whether it is reliable traffic, and a list of data path switches for each type of traffic.

5. The method for dynamic configuration of TSN parameters in a vehicular network based on deep learning as described in claim 4, characterized in that, Determine the flow and periodicity values ​​for queues of different priorities, specifically including: Divide future vehicle network traffic data into multiple time windows; For high-priority queues, the maximum flow rate and minimum periodicity of the corresponding queues within multiple time windows are used as the flow rate and periodicity values ​​for calculation. For ordinary priority queues, the average flow rate and average periodicity of the corresponding queues are taken from multiple time windows as the flow rate and periodicity values ​​used for calculation.

6. The method for dynamic configuration of TSN parameters in a vehicular network based on deep learning as described in claim 1, characterized in that, Based on the determined traffic and period values, bandwidth is allocated to high-priority queues and ordinary-priority queues according to preset bandwidth allocation rules, specifically: For high-priority queues, the allocated bandwidth is 110% of the calculated total high-priority traffic, and the high-priority bandwidth must occupy at least 10% and no more than 80% of the total bandwidth. The specific allocation is based on the calculated traffic proportion for each queue, and the calculation formula is as follows: ； in, To allocate the total bandwidth to high priority, For the bandwidth allocated to high-priority queue i, To calculate the high-priority total flow, To calculate the bandwidth of high-priority queue i, This represents the total bandwidth of the link. For regular priority queues, the remaining bandwidth is shared and allocated according to the traffic ratio calculated for each queue, as follows: ； ； in, The total bandwidth allocated to normal priority, For the bandwidth allocated to the normal priority queue i, For calculating the total flow rate of normal priority, The bandwidth of the ordinary priority queue i is calculated; Calculate TAS parameters for high-priority queues. The TAS parameters include the total gating period and the queue opening time. The total gating period is set as an integer divisor of the smallest period among all high-priority queues. The queue opening time is determined based on the proportion of queue allocated bandwidth to total bandwidth. The CBS parameter is calculated for a normal priority queue, and the formula for calculating the CBS parameter is as follows: ； ； ； ； in, Let i be the idle slope. Let i be the sending slope. The scheduling cycle for Qbv gating; This represents the cumulative door-opening time of queue i within a single scheduling cycle. Let i be the minimum reputation of queue i. Let i be the maximum reputation of queue i.

7. The method for dynamic configuration of TSN parameters in a vehicular network based on deep learning as described in claim 1, characterized in that, It also includes configuration distribution and error handling steps: Based on the built-in YANG model mapping relationship, the TSN parameter is populated into the XML template to generate NETCONF configuration data, and a transaction identifier and version tag are added to the XML configuration file; Construct a NETCONF message and send it to the target switch through the NETCONF session channel; Monitor the configuration distribution process, receive configuration response messages from the target switch, and verify the configuration execution results; When configuration fails, the corresponding error handling mechanism is executed according to the error type, which includes: If a configuration timeout error occurs, the configuration will be sent three times in a cycle. If it still fails, a rollback will be performed. If a parameter invalidation error occurs, the switch will return a parameter invalidation message to detect it and immediately perform a rollback. A communication error occurred. The sending path was switched. If the error persists, a rollback will be performed.

8. A deep learning-based dynamic configuration system for vehicular network (TSN) parameters, characterized in that, include: The data acquisition module is configured to: capture vehicle network packets and extract the core features of the vehicle network packets; The data prediction module is configured to: predict vehicle network traffic data for future periods based on the extracted core features and using deep learning methods; The data partitioning module is configured to divide the vehicle network traffic data for future time periods into high-priority queues and ordinary-priority queues, and determine the traffic value and period value of different priority queues by combining the preset bandwidth decision feature mapping table. The parameter configuration module is configured to: allocate bandwidth to high-priority queues and ordinary-priority queues according to preset bandwidth allocation rules based on the determined traffic and period values, calculate TAS parameters for high-priority queues and CBS parameters for ordinary-priority queues, and complete the dynamic configuration of TSN parameters for the vehicle network.

9. A computer-readable storage medium having a program stored thereon, characterized in that, When executed by the processor, the program implements the steps in the deep learning-based dynamic configuration method for vehicular network TSN parameters as described in any one of claims 1-7.

10. An electronic device comprising a memory, a processor, and a program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps in the deep learning-based vehicular network TSN parameter dynamic configuration method as described in any one of claims 1-7.

Images