A low latency communication method and apparatus
Patent Information
- Application Number
- CN202611073622.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-20
- Publication Date
- 2026-09-15
AI Technical Summary
[0004]现有方案在拥塞、抖动或丢包场景下,常缺乏针对关键事件的抢占保障、冗余加固以及接收侧统一校时和重排恢复机制,容易造成告警延迟、乱序显示和恢复不平滑
[0028] 1. By using fast and slow dual channels and a segment-level preemption mechanism, it is beneficial to reduce the end-to-end latency of critical risk events under limited bandwidth.
Smart Images

Figure CN122765031A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the fields of communication between dual-domain controllers of two-wheeled vehicles, real-time bus scheduling and embedded data transmission technology, and in particular to a low-latency communication method and apparatus between dual-domain controllers. Background Technology
[0002] In a dual-domain controller architecture, the safety control domain and the intelligent cockpit domain need to continuously transmit various types of information, including risk events, attitude information, speed synchronization, navigation updates, media data, and log data. Existing unified queue or single-channel transmission methods are prone to causing high-priority critical events to be blocked by slow-channel, large-volume traffic.
[0003] As in-vehicle electronic and electrical architecture continues to evolve towards higher integration and software-defined architecture, inter-domain communication increasingly needs to balance the determinism of critical business operations, the throughput of general business operations, and configuration scalability. For two-wheeled vehicles, the constraints of controller computing power, bandwidth, and cost are even tighter, requiring a simple and implementable fast and slow dual-channel and priority mapping mechanism.
[0004] Existing solutions often lack preemption guarantees, redundancy reinforcement, and unified time synchronization and reordering recovery mechanisms for critical events in congestion, jitter, or packet loss scenarios, which can easily lead to alarm delays, out-of-order display, and uneven recovery.
[0005] In addition, existing publications often discuss priority scheduling, message preemption, redundant transmission, or receiver reordering separately, but rarely combine fast and slow dual channels, segment-level preemption, breakpoint recovery, transmitting-side encapsulation, receiving-side reordering, and threshold-linked redundant switching into a complete low-latency communication closed loop in the communication scenario for dual-domain controllers of two-wheeled vehicles. Summary of the Invention
[0006] To address the aforementioned issues, this invention provides a low-latency communication method and apparatus between dual-domain controllers to achieve low-latency transmission of critical events, reliable retransmission of slow-channel services, priority protection in congestion scenarios, and unified recovery output on the receiving side.
[0007] This invention provides a low-latency communication method, the method comprising:
[0008] Obtain the event attribute model of the event to be sent, wherein the event attribute model includes at least the event priority and the maximum allowable inter-domain communication delay;
[0009] The events to be sent are classified according to the event attribute model. Events with priority P1 or P2 and maximum allowable inter-domain communication latency less than or equal to a first preset threshold are assigned to the fast channel, while other events are assigned to the slow channel. Here, P1 and P2 are high priority levels in the preset priority levels. The fast channel has higher scheduling priority, shorter transmission waiting time, or higher preemption authority than the slow channel. The high priority events are those with priority P1 or P2 and maximum allowable inter-domain communication latency less than or equal to the first preset threshold. The slow channel events are those that have not been assigned to the fast channel.
[0010] The slow channel event is divided into slow channel event segments according to a preset segment length, maximum transmission unit, protocol frame boundary, or fragmentable transmission unit boundary, and the slow channel event segments are transmitted through the slow channel.
[0011] During the transmission of the slow channel event fragment, if a high-priority event is detected, and continuing to transmit the current slow channel event fragment until the next interruptible boundary would cause the sum of the current waiting time of the high-priority event, the expected blocking time from the current scheduling time to the next interruptible boundary, and the expected transmission time of the high-priority event to be greater than the maximum allowable inter-domain communication delay of the high-priority event, then the preset preemption trigger condition is determined to be met. For subsequent interruptible data units that have not yet been written to the physical link, transmission is paused at the level of the transmission buffer, the queue to be transmitted, or the fragmentable transmission unit, and the sequence number of the slow channel event and the next position to be transmitted are recorded. The next position to be transmitted includes the fragment index and the byte offset within the fragment when the next position to be transmitted is within the current slow channel event fragment. For physical frames that have been written to the physical link and are uninterruptible, the transmission of subsequent slow channel event data is paused after the physical frame is transmitted, and the next position to be transmitted is recorded.
[0012] The high-priority events are sent preferentially through the fast channel;
[0013] After the high-priority event is sent, the transmission of the remaining data of the slow channel event is resumed based on the sequence number and the next to be sent position. Wherein, when the transmission confirmation mechanism is not enabled, the completion of the transmission of the last uninterruptible physical frame corresponding to the high-priority event is used as the condition for determining the completion of the high-priority event transmission. When the transmission confirmation mechanism is enabled, the receipt of confirmation feedback indicating that the high-priority event transmission is completed is used as the condition for determining the completion of the high-priority event transmission.
[0014] Preferably, the method further includes:
[0015] Before actually sending the event data corresponding to the event to be sent, the high-priority event, or the slow channel event segment, write the timestamp, sequence number, segment index, and total number of segments or end identifier into the event data;
[0016] The timestamp, sequence number, fragment index, and total number of fragments or end identifier are used by the receiving side to perform deduplication, out-of-order recovery, missing fragment judgment, and missing fragment filling on the data from the fast channel and the slow channel based on a preset rearrangement time window; the missing fragment filling is completed by using the corresponding missing fragments from the slow channel resumed or retransmitted, or by using the duplicate fragments from the redundant transmission.
[0017] Preferably, the method further includes link status monitoring and redundancy assurance steps:
[0018] Configure a link state model, which includes at least the queuing delay statistics for high-priority events, available bandwidth, packet loss rate, and queue backlog.
[0019] Redundancy protection is triggered when at least one of the following conditions is detected: the available bandwidth is less than the preset minimum available bandwidth, the packet loss rate is greater than the preset packet loss threshold, the queuing delay statistics of high-priority events are greater than the preset delay threshold, or the queue backlog is greater than the preset backlog threshold. When a backup communication link is configured and the backup communication link is available, the high-priority event is switched from the primary communication link to the backup communication link for transmission. When no backup communication link is configured, the backup communication link is unavailable, or at least one of the aforementioned conditions is still detected after transmission through the backup communication link, the high-priority event is retransmitted on the currently available communication link. Wherein, when the switch to the backup communication link has been successfully completed, the currently available communication link is the backup communication link; otherwise, it is the primary communication link.
[0020] Preferably, the event attribute model further includes data length and event type;
[0021] The event priority is divided into four levels, P1 to P4. P1 is used for collision alarms, fall risk alarms, roll risk alarms or braking abnormality alarms, P2 is used for attitude or speed synchronization, P3 is used for navigation refresh, and P4 is used for media data or log data.
[0022] The first preset threshold is 20 ms.
[0023] The present invention also provides a low-latency communication device applied to the transmitting side of a dual-domain controller for a two-wheeled vehicle, the device comprising:
[0024] The classification and priority module is used to obtain the event attribute model of the events to be sent, and classify the events to be sent according to the event attribute model. Events with event priorities of P1 or P2 and maximum allowable inter-domain communication latency less than or equal to a first preset threshold are assigned to the fast channel, and other events are assigned to the slow channel. The event attribute model includes at least event priority and maximum allowable inter-domain communication latency. P1 and P2 are high priority levels in the preset priority hierarchy. The fast channel has higher scheduling priority, shorter transmission waiting time, or higher preemption authority than the slow channel. The high priority events are those with event priorities of P1 or P2 and maximum allowable inter-domain communication latency less than or equal to the first preset threshold. The slow channel events are those not assigned to the fast channel. The classification and priority module is also used to divide the slow channel events into slow channel event fragments according to a preset fragment length, maximum transmission unit, protocol frame boundary, or fragmentable transmission unit boundary.
[0025] A preemptive scheduler is configured to determine if, during the transmission of the slow-channel event segment, a high-priority event is detected, and if continuing to transmit the current slow-channel event segment until the next interruptible boundary would result in the sum of the current waiting time of the high-priority event, the expected blocking time from the current scheduling time to the next interruptible boundary, and the expected transmission time of the high-priority event being greater than the maximum allowable inter-domain communication delay of the high-priority event, then a preset preemptive trigger condition is met. For subsequent interruptible data units that have not yet been written to the physical link, transmission is paused at the level of the transmission buffer, the waiting queue, or the fragmentable transmission unit, and the sequence number and the next waiting position of the slow-channel event are recorded. The next waiting position includes the segment index and the position at which the next waiting position is located within the current slow-channel event segment. The byte offset within the segment; for physical frames that have been written to the physical link and are uninterruptible, the transmission of subsequent slow channel event data is paused after the physical frame is transmitted, and the next transmission position is recorded; the preemption scheduler is also used to control the communication interface module to transmit the high-priority event first through the fast channel, and after the high-priority event is transmitted, the transmission of the remaining data of the slow channel event is resumed based on the sequence number and the next transmission position; wherein, when the transmission confirmation mechanism is not enabled, the completion of the transmission of the last uninterruptible physical frame corresponding to the high-priority event is used as the condition for the completion of the transmission of the high-priority event; when the transmission confirmation mechanism is enabled, the receipt of confirmation feedback indicating that the high-priority event has been transmitted is used as the condition for the completion of the transmission of the high-priority event.
[0026] The communication interface module is used to send the high-priority event through the fast channel and to send the slow channel event fragment through the slow channel.
[0027] The technical effects of this invention are:
[0028] 1. By using fast and slow dual channels and a segment-level preemption mechanism, it is beneficial to reduce the end-to-end latency of critical risk events under limited bandwidth.
[0029] 2. By using a breakpoint recovery mechanism, large packets on slow channels are prevented from being completely discarded, thereby improving the integrity and throughput stability of general services.
[0030] 3. By using timestamps, sequence numbers, fragment indexes, total number of fragments or end markers and reordering time windows, the risk of out-of-order output and missing fragments caused by multi-channel transmission can be reduced.
[0031] 4. Improve the arrival rate of critical events and system robustness through congestion detection, threshold triggering, redundant transmission, or primary / backup link switching.
[0032] 5. It is compatible with the low computing power, low cost and high reliability requirements of two-wheeled vehicles, and is easy to reuse in different dual-domain architectures. Attached Figure Description
[0033] Figure 1 This is a structural diagram of the low-latency communication device for the dual-domain controller of the present invention.
[0034] Figure 2 This is a flowchart of the present invention. Detailed Implementation
[0035] The inventive concept of this invention will be described below.
[0036] Terminology Explanation:
[0037] A "domain" is a logical or physical collection of functions and resources in the process of system control architecture evolving towards centralization. Its core logic is to integrate dispersed subsystems or control units onto a specific centralized computing platform according to task attributes, real-time requirements, and functional safety levels. In specific technical implementations, a complete "domain" is mainly defined through the following three dimensions: First, the logical aggregation of functions and tasks, that is, classifying tasks with similar attributes according to the relevance of control objectives, such as physically centralizing security control functions or independently encapsulating information interaction functions; second, an independent hardware and software operating environment, where each domain relies on core hardware that matches its task characteristics as physical computing power support, such as using highly reliable microcontrollers or high-performance system-on-chips (SoCs), and simultaneously carrying matching underlying software, such as a real-time operating system with strong real-time capabilities or a general-purpose operating system supporting high concurrency; third, clear resource and permission boundaries, where different domains are decoupled and isolated at the underlying computing and storage resources, and cross-domain data and instruction calls must be conducted through a clearly defined inter-domain communication network to construct physical and logical boundaries, preventing non-real-time or low-security tasks from crowding out core control resources.
[0038] The safety control domain carries the core safety and driving control logic of the vehicle, specifically handling power output control, braking system control, vehicle attitude risk assessment, and related safety output tasks. In the cross-domain architecture's permission design, the safety control domain acts as the legality reviewer and final executor of control commands. It is responsible for receiving high-risk action requests initiated by external domains, performing boundary condition verification based on real-world vehicle conditions such as current vehicle speed, braking status, fault status, riding mode constraints, and side stand status, and outputting a confirmation response and physically driving the corresponding actuator action if the verification passes.
[0039] The intelligent cockpit domain is used to handle non-real-time, high-concurrency information processing and human-machine interaction loads. It primarily handles connectivity and information-related tasks such as Human-Machine Interface (HMI) display, navigation and voice interaction, upper-layer application services, Over-the-Air (OTA) system upgrades, and log data management. Within the system's control authority boundaries, the intelligent cockpit domain does not have the hardware-driven permissions to directly execute high-risk actions; for operations that may interfere with vehicle power or braking performance, this domain only generates and sends action request messages across domains.
[0040] In the dual-domain controller architecture of two-wheeled vehicles, frequent data interactions occur between the safety control domain and the intelligent cockpit domain, encompassing high-priority events such as collision warnings, as well as slow-channel services with large data volumes, such as navigation updates and media streams. Limited by the computing power, bandwidth, and cost constraints of the two-wheeled vehicle controller, using conventional unified queuing or single-channel transmission schemes can easily cause high-throughput general services to block high-priority events, leading to latency fluctuations and channel congestion for critical safety data. To address the uncontrollable latency and packet loss issues caused by such mixed data streams, this solution establishes a low-latency communication mechanism based on dual channels and breakpoint recovery.
[0041] In this invention, fast channels and slow channels can be different priority logical queues, different virtual channels, or different transmit buffer queues on the same physical communication bus, or they can be different physical links. Fast channels have higher scheduling priority, shorter transmit waiting time, or higher preemption privileges compared to slow channels. Slow channel events can be divided into slow channel event segments according to a preset segment length, maximum transmission unit, protocol frame boundary, or fragmentable transmit unit boundary. One slow channel event segment can correspond to one or more data units to be scheduled and can be encapsulated into one or more physical frames according to the underlying protocol. The next transmit position is used to identify the recovery starting point after the pause, including the segment index and the byte offset within the segment when the recovery starting point is within the current segment. Offset represents the length of data that has been transmitted within the segment before this pause. When the recovery starting point is at the beginning of the next segment, the byte offset within the segment can be omitted or taken as 0. For subsequent interruptible data units that have not yet been written to the physical link, the preemptive scheduler pauses transmission at the level of the transmission buffer, the queue to be transmitted, or the fragmentable transmission unit, and records the sequence number Seq and the next position to be transmitted. For physical frames that have been written to the physical link and are uninterruptible, the preemptive scheduler waits for the current physical frame to be transmitted before pausing the transmission of subsequent slow channel event data, and records the next position to be transmitted after the physical frame is transmitted. High-priority event transmission completion refers to the completion of transmission of the last physical frame of the high-priority event; when configuring transmission acknowledgment feedback in the communication protocol, transmission acknowledgment feedback can also be received as a condition for determining transmission completion.
[0042] The low-latency communication device of the present invention can be composed of a classification and priority module in the transmission domain, as well as a fast channel, a slow channel, a preemption scheduler, and a communication interface module in the communication device. Figure 1The communication device 530 is the transmission processing part of the low-latency communication device. The communication interface module includes interfaces associated with the fast channel 531 and the slow channel 532. The breakpoint recovery function is executed by the preemption scheduler 533, and no separate transmission recovery module is provided. The communication bus is the physical or logical transmission carrier that the low-latency communication device can use. The main communication link, the backup communication link, or the redundant link can all be used as specific link resources in the communication bus. The backup communication link is also called the redundant link. The availability of the backup communication link means that the backup communication link handshake is successful, the confirmation feedback is normal, and the packet loss rate is less than or equal to the preset backup link packet loss threshold. Redundant transmission includes performing at least one repeated transmission of the same high-priority event on the currently available communication link, except for the first transmission, preferably making the total number of transmissions no less than two. When general services are not allocated to the fast channel, they are all treated as slow channel events or slow channel services.
[0043] In this invention, the event priorities P1 to P4 are predetermined according to the potential security consequences of the event, the urgency of the event needing to be handled, and the business type to which the event belongs. Among them, the priority of P1 is higher than that of P2, the priority of P2 is higher than that of P3, and the priority of P3 is higher than that of P4.
[0044] When an event to be sent enters the event queue, the classification and priority module reads the event identifier, event source module, event status, data length, and event type carried by the event to be sent, and queries the pre-stored event attribute configuration table to determine the basic priority and maximum allowable inter-domain communication latency of the event. When the event to be sent also carries candidate maximum allowable inter-domain communication latency, the smaller value between the candidate maximum allowable inter-domain communication latency and the corresponding value in the event attribute configuration table is determined as the maximum allowable inter-domain communication latency of the event.
[0045] Events that may directly affect vehicle driving safety or require an immediate control response from the safety control domain are identified as P1 events, including collision warnings, fall risk warnings, roll risk warnings, brake anomaly warnings, anti-lock braking system (ABS) anomaly warnings, traction control system (TCS) anomaly warnings, and traction control anomaly warnings.
[0046] Events used for synchronizing control states between the safety control domain and the smart cockpit domain, where transmission delays may affect state consistency but do not typically trigger emergency control actions, are identified as P2 events, including vehicle attitude synchronization events and vehicle speed synchronization events.
[0047] An event used for navigation display, human-machine interface refresh, or general status prompts, which allows transmission to be completed within one or more refresh cycles, is identified as a P3 event.
[0048] Events used for media data transmission, operation log uploads, diagnostic records, or background data transmission are identified as P4 events.
[0049] When the same event to be sent simultaneously meets multiple event type conditions in the event attribute configuration table, the classification and priority module selects the highest priority from the corresponding multiple priorities as the final priority of the event, and selects the minimum value from the corresponding multiple maximum permissible inter-domain communication delays as the final maximum permissible inter-domain communication delay of the event. Since P1 has a higher priority than P2, when the same event simultaneously meets the determination conditions of both P1 and P2 events, the event is determined to be event P1.
[0050] When multiple events to be sent have the same priority, the event with the smaller remaining allowed delay is sent first; the remaining allowed delay is the difference between the maximum allowed inter-domain communication delay for that event and the current waiting time for that event. When multiple events have the same priority and remaining allowed delay, they are sent according to their timestamps or the order in which they entered the sending queue.
[0051] Collision warning, fall risk warning, roll risk warning P1 No more than 20 ms Vehicle safety events that require immediate transmission Braking malfunction, ABS malfunction, TCS malfunction, or traction control malfunction P1 No more than 20 ms Events that may affect braking or vehicle stability Attitude synchronization, velocity synchronization P2 Determined based on the control cycle; the time required to enter the fast lane should not exceed 20 ms. Control state synchronization events Navigation refresh, general status prompts P3 Determined based on the navigation or interface refresh cycle, typically greater than 20 ms. Information services that allow short delays Media data, logs, diagnostic records P4 Determined based on the backend business cycle, typically greater than 20 ms Backend or large data volume business
[0052] The communication mechanism is based on establishing an attribute model for the events to be transmitted and monitoring the link status. Data streams are allocated to fast or slow channels based on the event's priority and the maximum allowable inter-domain communication delay. A preemption scheduler is configured on the transmitting side. When a high-priority event arrives, and the sum of the high-priority event's current waiting time, the estimated blocking time for continuing to transmit the current slow-channel event segment until the next interruptible boundary, and the high-priority event's estimated transmission time exceeds its maximum allowable inter-domain communication delay, a preset preemption trigger condition is determined to be met. For subsequent interruptible data units not yet written to the physical link, the preemption scheduler pauses transmission and records the Seq and the next pending transmission position. For physical frames already written to the physical link and uninterruptible, the preemption scheduler pauses subsequent slow-channel event data after the current physical frame is transmitted and records the next pending transmission position after the physical frame is transmitted. After the high-priority event is transmitted, the system resumes transmission of the remaining slow-channel event data from the next pending transmission position.
[0053] During the dual-channel splitting and preemptive scheduling process, the order in which data arrives at the receiving end may differ from the actual order in which it was generated. To address this, the sending end writes a timestamp, sequence number, fragment index, and the total number of fragments or an end marker for each event during packet encapsulation. A priority field can also be written. Based on these identifiers, the receiving end performs unified time synchronization, deduplication, out-of-order recovery, fragment missing detection, fragment completion, or missing data marking on the fast and slow channels within a set rearrangement time window, ultimately integrating and outputting a time-consistent data sequence. Furthermore, considering the uncertainty of the two-wheeled vehicle communication environment, the solution incorporates dynamic redundancy triggering logic. When the real-time monitored packet loss rate, high-priority event queuing delay statistics, or queue backlog exceeds a preset threshold, the system switches from the primary communication link to the backup communication link for transmission, provided a backup communication link is configured and available. If no backup communication link is configured, the backup communication link is unavailable, or the link status still exceeds the corresponding safety threshold after transmission via the backup communication link, the system initiates repeated transmission for high-priority events on the currently available communication link.
[0054] Example 1: In a normal communication scenario, after the sending domain collects different types of events, the classification and priority module puts the events into the fast channel or the slow channel according to the priority P1 to P4 and the maximum allowable delay of inter-domain communication; the communication device sends according to the default strategy, and the receiving domain restores the data into a unified output sequence through the receiving buffer and the event restorer.
[0055] Example 2: When a P1-level risk alarm arrives and the preset preemption trigger condition is met, for P4 media data units that have not yet been written to the physical link, the preemption scheduler pauses transmission and records the Seq and the next pending transmission position; for physical frames that have been written to the physical link and cannot be interrupted, subsequent media data is paused after the physical frame is sent and the next pending transmission position after the physical frame is sent is recorded. Then, the P1 event is sent preferentially through the fast channel; after the P1 event is sent, the remaining data of the slow channel event continues to be sent from the next pending transmission position.
[0056] Example 3: When the available bandwidth is detected to be lower than the preset minimum available bandwidth, or when the packet loss rate, queue backlog, or high-priority event queuing delay statistics exceed the corresponding threshold, the system enters the congestion detection state; when a backup communication link is configured and the backup communication link is available, the system switches the high-priority event from the main communication link to the backup communication link for transmission; when no backup communication link is configured, the backup communication link is unavailable, or the link status requirements are still not met after switching, the high-priority event is repeatedly transmitted on the currently available communication link to improve the reachability of critical events.
[0057] Example 4: On the receiving side, if the data from the fast and slow channels arrive in different orders, correction and rearrangement are performed within the rearrangement time window based on the timestamp and sequence number to form a unified and orderly output queue for use by the intelligent cockpit domain or the security control domain.
[0058] Example 5: In a dual-domain controller platform for motorcycles or electric two-wheelers, the classification and prioritization module determines event priorities based on a pre-stored event attribute configuration table. Collision alarms, fall risk alarms, tilt risk alarms, braking anomaly alarms, or traction control anomaly alarms are identified as P1 events; attitude synchronization or speed synchronization is identified as P2 events; navigation refresh is identified as P3 events; and media data or log data is identified as P4 events. P1 has a higher priority than P2, P2 has a higher priority than P3, and P3 has a higher priority than P4. When the same event matches multiple event types simultaneously, the highest priority is used, along with the minimum value among the maximum allowable inter-domain communication delays. This invention improves the transmission determinism of high-priority events (P1 or P2) with a maximum allowable inter-domain communication delay less than or equal to a first preset threshold in low-cost bus and limited bandwidth scenarios.
[0059] Example 6: Perform the following method,
[0060] Collect events to be sent and construct an event attribute model, which includes at least event priority P, maximum allowable inter-domain communication delay T_req, data length L, and event type Type.
[0061] Construct a link state model, which includes at least the high-priority event queuing delay statistics T_cur, available bandwidth B, packet loss rate R_loss, and queue backlog Q.
[0062] The current waiting time T_wait is used to determine whether a single high-priority event needs to be preempted. T_wait strictly represents the actual waiting time of the high-priority event from entering the transmission queue to the current scheduling time, excluding the future blocking time that may occur from the current scheduling time. The high-priority event queuing delay statistic T_cur is used to reflect the overall queuing status of high-priority events within the preset monitoring window. T_cur is the maximum value or the 95th percentile value of the queuing time of each high-priority event within the preset monitoring window. Available bandwidth B is obtained by the ratio of the amount of data successfully transmitted within the preset sampling period to the preset sampling period; packet loss rate R_loss is obtained by the ratio of the number of transmission frames that did not receive acknowledgment feedback or were reported as transmission failures by the underlying communication interface within the preset monitoring window to the total number of transmission frames; queue backlog Q is the total number of bytes of data that have not yet been transmitted in the current transmission queue, including the payload length and the corresponding protocol overhead length.
[0063] The estimated blocking duration T_block represents the estimated duration from the current scheduling time to the next interruptible boundary, assuming continued transmission on the current slow channel. For subsequent interruptible data units that have not yet been written to the physical link, T_block is the estimated duration to continue sending the currently selected data unit to its interruptible boundary; when the current scheduling time itself is an interruptible boundary, T_block is 0. For physical frames that have been written to the physical link and are uninterruptible, T_block is the estimated transmission duration of the unsent portion of the current physical frame, excluding other segments or physical frames after that physical frame. The estimated transmission duration T_hi for high-priority events is determined based on the payload length of the high-priority event, the protocol overhead length, the acknowledgment feedback or link control overhead length of the first transmission, the estimated retransmission overhead length, and the currently available bandwidth. Preferably, T_hi = (L_hi + L_head + L_ack + L_retry) / B, where L_hi is the payload length of the high-priority event, L_head is the protocol overhead length, L_ack is the acknowledgment feedback or link control overhead length corresponding to the first transmission, and L_retry is the estimated retransmission overhead length.
[0064] The estimated retransmission overhead length L_retry is determined based on the actual packet loss or retransmission situation of the current communication link within the most recent monitoring window. The sending side counts the number of sent frames N_send and the number of frames without acknowledgment N_fail within a preset monitoring window; when N_send > 0, the estimated packet loss rate R_est is calculated according to R_est = N_fail / N_send. When the communication protocol directly provides retransmission counts, the estimated packet loss rate can also be determined based on the ratio of retransmitted frames to the initial sent frames within the preset monitoring window.
[0065] When 0 ≤ R_est < 1, the estimated number of retransmissions N_retry_est is determined according to N_retry_est = min(N_retry_max, R_est / (1-R_est)), where N_retry_max is the maximum estimated number of retransmissions allowed to be included in the transmission duration estimation; when R_est = 1, N_retry_est is N_retry_max; when N_send = 0 or no effective statistics have been formed, N_retry_est is the pre-configured initial estimated number of retransmissions N_retry_init.
[0066] The expected retransmission overhead length L_retry is determined according to L_retry = N_retry_est × (L_hi + L_head + L_ack), where L_hi is the payload length of the high-priority event, L_head is the protocol header length corresponding to each transmission, and L_ack is the acknowledgment feedback or link control overhead length corresponding to each transmission. When no acknowledgment feedback is needed, or when acknowledgment feedback is sent using a separate link and does not consume current link bandwidth, L_ack is set to 0.
[0067] N_retry_est is a statistical estimate used to calculate the expected transmission duration. When the transmission scheduler uses an integer number of retransmissions for resource reservation, N_retry_est is rounded up to calculate L_retry. When the system first starts up, the cumulative number of transmitted frames has not reached the preset statistical number, or N_send=0, L_retry is calculated using N_retry_init. Once the cumulative number of transmitted frames reaches the preset statistical number, the calculation switches to dynamic calculation based on R_est. The preset monitoring window can be the last 100 transmitted frames or the transmitted frames within the last 100 ms.
[0068] The rearrangement time window W can be determined based on the statistical difference in transmission delay between fast and slow channels, jitter margin, and the maximum allowable inter-domain communication delay for high-priority events. For example, W = min(T_req_hi, max(ΔT_fast_slow, Jitter_margin)), where T_req_hi is the maximum allowable inter-domain communication delay for the current high-priority event. When no high-priority event exists, T_req_hi takes the minimum maximum allowable inter-domain communication delay for fast channel events in the event attribute configuration table; if no fast channel event is configured, the preset initial delay T_req_init is used. ΔT_fast_slow is the statistical difference in transmission delay between fast and slow channels, and Jitter_margin is the currently used jitter margin. When the system starts up and no effective statistical data has been generated, W takes the pre-configured initial rearrangement time window W_init. When unifying time synchronization, the sending side timestamp TS can use the same vehicle controller system clock, communication bus synchronization clock, or be corrected by the receiving side in combination with the receiving time and preset clock offset; when there is a clock deviation between the sending side and the receiving side, the receiving side can estimate the deviation and correct the TS based on the periodic synchronization message.
[0069] The preset jitter margin is determined based on the transmission delay fluctuations of fast and slow channel data packets within a preset statistical window. The sending side writes a transmission timestamp TS_send into the data packet, and the receiving side records the corresponding data packet's reception timestamp TS_receive. After correcting the clock offset between the sending and receiving sides, the actual transmission delay of the i-th data packet is calculated according to Di = TS_receive - TS_send.
[0070] Within a statistical window consisting of the most recent N data packets, the receiving side calculates the absolute deviation of each actual transmission delay D_i relative to the median transmission delay D_med within the statistical window, and takes the 95th percentile value J_95 of the absolute deviation as the link delay fluctuation value.
[0071] The jitter margin is calculated according to Jitter_calc=J_95+E_clock+T_schedule, where E_clock is the maximum clock error that may exist after synchronizing or correcting the clock on the transmitting side and the clock on the receiving side, and T_schedule is the task scheduling cycle on the receiving side or the maximum scheduling waiting time for reordering tasks.
[0072] In one embodiment, the statistical window includes the most recent 100 data packets; the jitter margin is updated once after the receiving side receives a preset number of new data packets. When the statistical sample is insufficient, the current jitter margin Jitter_margin adopts the pre-stored initial jitter margin Jitter_init. To avoid frequent changes in the rearrangement time window due to instantaneous fluctuations, a smooth update can be performed according to Jitter_new = α × Jitter_calc + (1-α) × Jitter_old, where Jitter_old is the jitter margin used before the update, Jitter_new is the jitter margin after the update, and after the update, Jitter_margin is set to Jitter_new, and α is a smoothing coefficient greater than 0 and less than or equal to 1.
[0073] The statistical difference in transmission delay between fast and slow channels, ΔT_fast_slow, is the difference between the 95th percentile transmission delay of the slow channel and the 95th percentile transmission delay of the fast channel within the same statistical window; when the difference is less than 0, ΔT_fast_slow is 0.
[0074] The classification and priority module reads the event identifier, event source module, event status, data length, and event type, and queries the event attribute configuration table to determine the event priority and the maximum allowable inter-domain communication latency. When the event also carries candidate maximum allowable inter-domain communication latency, the smaller value between the candidate maximum allowable inter-domain communication latency and the configured value is selected. When the same event matches multiple entries, the highest priority and the minimum maximum allowable inter-domain communication latency are selected. Events with priorities of P1 or P2 and a maximum allowable inter-domain communication latency less than or equal to a first preset threshold are assigned to the fast channel, while other events are assigned to the slow channel.
[0075] For events allocated to the slow channel, the sending side divides them into slow channel event fragments according to the preset fragment length, maximum transmission unit, protocol frame boundary, or fragmentable transmission unit boundary, and sends them according to the fragment index.
[0076] The preemption scheduler performs transmission arbitration based on the constraint decision function. When a high-priority event is detected, and the event's priority P belongs to P1 or P2, the maximum allowable inter-domain communication delay T_req is less than or equal to a first preset threshold, and the sum of T_wait, T_block, and T_hi is greater than T_req, the preset preemption trigger condition is determined to be met. For subsequent interruptible data units that have not yet been written to the physical link, transmission is paused at the level of the transmission buffer, the waiting queue, or the fragmentable transmission unit, and the Seq and the next waiting position are recorded. For physical frames that have been written to the physical link and are uninterruptible, subsequent slow-channel event data is paused after the physical frame is transmitted, and the next waiting position after the physical frame is transmitted is recorded. Subsequently, high-priority events are transmitted preferentially through the fast channel. After the high-priority events are transmitted, the transmission of the remaining slow-channel event data is resumed from the next waiting position.
[0077] In this specification, the completion of high-priority event transmission is determined by whether a transmission acknowledgment mechanism is enabled: when the transmission acknowledgment mechanism is not enabled, the completion of transmission is considered as the completion of the transmission of the last uninterruptible physical frame corresponding to the high-priority event; when the transmission acknowledgment mechanism is enabled, the completion of transmission is considered as the receipt of acknowledgment feedback indicating that the high-priority event has been transmitted.
[0078] The sending side writes a timestamp TS, sequence number Seq, fragment index Idx, and total number of fragments N_frag or end identifier End to each event data. It can also write a priority, which is used by the receiving side to perform time synchronization, fragment loss detection, and reordering recovery. When no priority is written, the event data carries an event identifier. The receiving side determines the priority by querying an event attribute configuration table consistent with the sending side based on the event identifier. When using a Seq query, the sending side provides a mapping relationship between Seq and event identifiers during the first fragment of the event or the connection initialization phase. The receiving side saves this mapping relationship and then determines the priority of the corresponding event.
[0079] The receiving side performs unified time synchronization, deduplication, out-of-order recovery, missing fragment judgment, missing fragment filling or missing fragment marking on the data from the fast channel and slow channel based on the rearranged time window W, forming a unified output sequence with consistent timing; among them, missing fragment filling is completed by using the corresponding missing fragments from the slow channel resumed or retransmitted, or by using the duplicate fragments from the redundant transmission.
[0080] When the available bandwidth is detected to be lower than the preset minimum available bandwidth, or when the packet loss rate, high-priority event queuing delay statistics, or queue backlog exceeds the corresponding preset threshold, redundancy protection is triggered; when a backup communication link is configured and the backup communication link is available, the high-priority event is switched from the main communication link to the backup communication link for transmission; when no backup communication link is configured, the backup communication link is unavailable, or at least one of the aforementioned situations is still detected after transmission through the backup communication link, the high-priority event is repeatedly transmitted on the currently available communication link.
[0081] In this embodiment, the transmission arbitration, preemption triggering, and redundancy triggering are implemented using a scheduling rule table pre-stored in the controller's memory. In each scheduling cycle, the preemption scheduler reads the event priority P, the maximum allowable inter-domain communication delay T_req, the current waiting time T_wait, the estimated blocking time T_block, the estimated transmission time of high-priority events T_hi, the current available bandwidth B, the packet loss rate R_loss, the queuing delay statistics for high-priority events T_cur, and the queue backlog Q, and then matches and executes the rules according to the rule table in descending order of priority.
[0082] Rule 1: If no high-priority event is detected, continue sending the current slow channel event fragment through the slow channel.
[0083] Rule 2: When a high-priority event is detected, and T_wait+T_block+T_hi≤T_req and B≥B_min, the current slow channel event data is allowed to continue to be sent to the next interruptible boundary, and then the high-priority event is sent.
[0084] Rule 3: When it is detected that a high-priority event arrives, P belongs to P1 or P2, T_req is less than or equal to the first preset threshold, and T_wait+T_block+T_hi>T_req, set Preempt to 1. For subsequent interruptible data units that have not been written to the physical link, suspend transmission at the level of the transmission buffer, the queue to be transmitted or the fragmentable transmission unit, and record the Seq and the next position to be transmitted; for physical frames that have been written to the physical link and cannot be interrupted, suspend subsequent slow-channel event data after the transmission of the physical frame is completed, and record the next position to be transmitted after the transmission of the physical frame is completed; then the high-priority event is transmitted through the fast channel.
[0085] Rule 4: When B<B_min and the standby communication link is available, switch the high-priority event to the standby communication link for transmission.
[0086] Rule 5: When B<B_min and no standby communication link is configured or the standby communication link is unavailable, perform repeated transmission of the high-priority event on the main communication link.
[0087] Rule 6: When at least one of the following conditions is satisfied: B<B_min, R_loss>R_th, T_cur>T_th or Q>Q_th, set Redundant to 1, and preferentially perform standby communication link switching; when the standby communication link is unavailable or at least one of the above conditions is still satisfied after switching, perform repeated transmission on the currently available communication link.
[0088] Rule 7: When multiple rules are satisfied at the same time, first complete the transmission of the non-interruptible physical frame that has been written to the physical link, and then execute in the order of standby communication link switching, fast channel transmission of high-priority events, repeated transmission when necessary, and resumed transmission of the slow channel.
[0089] The above rules can be implemented by a conditional judgment program. The preemption judgment function corresponding to the rules is Preempt=f(P,T_req,T_wait,T_block,T_hi,B), and the redundancy judgment function corresponding to the rules is Redundant=h(B,R_loss,T_cur,Q). When the function outputs 0, the corresponding action is not triggered, and when the function outputs 1, the corresponding action is triggered; wherein Preempt is 1 only when P belongs to P1 or P2, T_req is less than or equal to the first preset threshold, and T_wait+T_block+T_hi>T_req.
[0090] Event priorities are divided into P1 to P4, with P1 having a higher priority than P2, P2 having a higher priority than P3, and P3 having a higher priority than P4. The event attribute configuration table should include at least the event identifier, event source module, event type, basic priority, maximum allowable latency for inter-domain communication, and default sending channel.
[0091] The event attribute configuration table is generated during the system design or vehicle controller calibration phase. For each event, the basic priority is first determined based on the potential safety consequences of delayed delivery. Then, based on the corresponding safety control function, control cycle, status refresh cycle, or the maximum allowable response time of the upper-layer service, the maximum allowable latency for inter-domain communication is determined by deducting the event generation and identification time, data encapsulation time, receiver processing time, and safety margin. Finally, the default transmission channel is determined based on the maximum allowable latency for inter-domain communication and the worst-case transmission latency of the vehicle's dual-domain communication link. The generated event attribute configuration table is stored in the controller's non-volatile memory and is loaded by the classification and prioritization module upon system startup.
[0092] The first preset threshold of 20 ms is determined based on the inter-domain communication latency budget for high-priority events. The end-to-end latency budget for an event includes the event generation and identification time, the waiting time after the event enters the transmission queue, the data encapsulation time, the communication link transmission time, the receiver-side reordering processing time, and the reserved safety margin.
[0093] For an event to be sent, its end-to-end delay satisfies T_total = T_detect + T_wait + T_pack + T_link + T_receive + T_margin, where T_detect is the event generation and identification time, T_wait is the transmission queuing time, T_pack is the data encapsulation time, T_link is the inter-domain communication link transmission time, T_receive is the receiving side processing time, and T_margin is the safety margin.
[0094] In the event attribute model, the maximum permissible inter-domain communication delay T_req is determined by subtracting the event generation and identification time T_detect, data encapsulation time T_pack, receiver processing time T_receive, and safety margin T_margin from the maximum permissible end-to-end delay T_total_req of the event. That is, T_req = T_total_req - T_detect - T_pack - T_receive - T_margin, while ensuring that T_wait + T_link is not greater than T_req. In one embodiment, based on the response time requirements of the vehicle control function and the delay test results obtained under the target controller, target communication bus, and worst-case bandwidth conditions, the delay budget allocated to the inter-domain queuing and transmission process is determined to be 20 ms. Therefore, the first preset threshold is set to 20 ms. When using different control cycles, different communication buses, or different processor platforms, each delay component can be remeasured, and the maximum permissible inter-domain communication delay and the first preset threshold can be re-determined according to the above delay budget method.
[0095] When the same event matches multiple entries in the event attribute configuration table, the classification and priority module selects the highest priority as the final priority and the smallest maximum permissible inter-domain communication latency as the final maximum permissible inter-domain communication latency. When both P1 and P2 are satisfied, the final priority is determined as P1.
[0096] When multiple events are assigned to the fast channel, they are first scheduled in the order that P1 is higher than P2; if the priorities are the same, they are scheduled in the order that the remaining allowed delay is smaller in ascending order; if the remaining allowed delay is the same, they are scheduled in the order in which the events entered the sending queue.
[0097] When an event belongs to P1 or P2 but its maximum allowable inter-domain communication delay is greater than 20 ms, the event does not meet the full allocation conditions of the fast channel and is allocated to the slow channel according to the default rules of this embodiment; when an event belongs to P1 or P2 and its maximum allowable inter-domain communication delay is less than or equal to 20 ms, it is allocated to the fast channel.
[0098] Preferably, the constraint determination function includes: when T_wait + T_block + T_hi ≤ T_req and B ≥ B_min, the current slow channel event data is allowed to continue to be sent to the next interruptible boundary, where T_req is the maximum allowable inter-domain communication delay of the current pending high-priority event, T_wait is the actual waiting time of the high-priority event from entering the transmission queue to the current scheduling time, T_block represents the expected blocking time from the current scheduling time to the next interruptible boundary when continuing the current slow channel transmission, T_hi represents the expected transmission time required by the high-priority event itself, and B_min is the minimum available bandwidth required to satisfy the transmission of the high-priority event; when the high-priority event arrives and Preempt = f(P, T_req, T_wait, T_block, T_hi, B) meets the triggering condition, preemption is performed. Specifically, Preempt is set to 1 only when P belongs to P1 or P2, T_req is less than or equal to the first preset threshold and T_wait + T_block + T_hi > T_req, otherwise Preempt is set to 0.
[0099] The preset minimum available bandwidth B_min can be determined based on the payload length of the high-priority event, the protocol overhead length, the acknowledgment feedback or link control overhead length of the first transmission, the expected retransmission overhead length, and the remaining available delay after deducting the actual waiting time and the expected blocking time. Preferably, B_min = (L_hi + L_head + L_ack + L_retry) / (T_req - T_wait - T_block), where when T_req - T_wait - T_block is less than or equal to 0, it is determined that the current link cannot meet the delay constraint of the high-priority event, and a preemption, backup communication link switching, or retransmission strategy is triggered.
[0100] When B < B_min, the preset bandwidth degradation strategy preferentially determines whether the standby communication link is available; an available standby communication link means that the handshake of the standby communication link succeeds, the confirmation feedback is normal, and the packet loss rate is less than or equal to the preset packet loss threshold of the standby link. If the standby communication link is available, the high-priority event is switched from the main communication link to the standby communication link for transmission; if no standby communication link is configured or the standby communication link is unavailable, the same high-priority event is repeatedly transmitted on the main communication link according to the preset redundant transmission number N_r; if the event has been switched to the standby communication link but the link state still does not meet the requirements, repeated transmission is performed on the standby communication link. N_r ≥ 1, and N_r represents the number of repeated transmissions excluding the first transmission; wherein, the data of the high-priority event carries a timestamp and a sequence number before transmission, the repeatedly transmitted data retains the same timestamp and sequence number as the original high-priority event, and retains the fragment index when the fragment index exists; if there is still a risk of timeout or missing fragments after repeated transmission, a retransmission request identifier or a link abnormality identifier is generated for the receiving side to perform missing marking, retransmission processing or recovery using redundant copies.
[0101] For subsequent interruptible data units that have not been written to the physical link, the interrupt position includes the sequence number Seq of the interrupted slow channel event and the next position to be transmitted; the next position to be transmitted includes the fragment index Idx and the in-fragment byte offset Offset when the position is within the current fragment, and Offset represents the length of data that has been transmitted before the suspension in the corresponding fragment. When resuming transmission, the remaining data in the transmission buffer is located according to Seq, Idx and the necessary Offset. For physical frames that have been written to the physical link and cannot be interrupted, the next position to be transmitted is recorded after the transmission of the physical frame is completed; when the position is at the start of the next fragment, the fragment index of the next fragment is recorded and Offset is omitted or set to 0, when the position is still within the current fragment, the fragment index of the current fragment and Offset are recorded at the same time.
[0102] Redundant trigger functions include: when B<B_min、R_loss> When at least one of the following conditions is met: R_th, T_cur > T_th, or Q > Q_th, Redundant = h(B, R_loss, T_cur, Q) is set to 1, triggering a switchover to the backup communication link or retransmission. Here, B_min is the preset minimum available bandwidth, R_th is the preset packet loss threshold, T_th is the preset latency threshold, and Q_th is the preset backlog threshold. Backup communication link switching refers to switching high-priority events from the primary communication link to an available backup communication link for transmission. When the system does not have a backup communication link configured, the backup communication link is unavailable, or at least one of the above conditions is still met after transmission through the backup communication link, the same high-priority event is retransmitted on the currently available communication link. Specifically, if a successful switchover has occurred, retransmission is performed on the backup link; otherwise, retransmission is performed on the primary communication link.
[0103] The transmitting side updates the available bandwidth B, packet loss rate R_loss, high-priority event queuing delay statistics T_cur, and queue backlog Q according to a preset monitoring period. In one embodiment, the preset monitoring period is 100 ms, or the most recent 100 transmitted frames are used as a monitoring window.
[0104] Available bandwidth B is the ratio of the amount of data successfully transmitted within a preset sampling period to the preset sampling period; packet loss rate R_loss is the ratio of the number of transmitted frames that did not receive acknowledgment feedback or were reported as transmission failures by the underlying communication interface within the monitoring window to the total number of transmitted frames; high-priority event queuing delay statistics T_cur is the maximum value or the 95th percentile value of the high-priority event queuing time within the monitoring window; queue backlog Q is the total number of bytes of untransmitted payload and corresponding protocol overhead in the current transmission queue. When calculating T_block, T_hi, B_min, and Q_th, B is uniformly converted to bytes / millisecond, and all delay parameters are uniformly expressed in milliseconds.
[0105] The preset latency threshold T_th is determined based on the remaining inter-domain communication latency budget of the current high-priority event: T_th = max(0, T_req - T_hi - T_switch - T_guard), where T_req is the maximum allowable inter-domain communication latency of the current high-priority event, T_hi is the estimated transmission time of the high-priority event, T_switch is the estimated time required to switch to the backup communication link, and T_guard is the preset security protection time. When the queuing latency statistic T_cur of the high-priority event exceeds T_th, it indicates that continuing to wait may cause the high-priority event to exceed its maximum allowable inter-domain communication latency, thus triggering redundancy protection.
[0106] The preset backlog threshold Q_th is determined according to the current available bandwidth and the remaining available delay: Q_th=B×max(0,T_req-T_hi-T_guard). During calculation, B is converted into bytes per millisecond, and T_req, T_hi and T_guard all adopt millisecond as the unit, so the unit of Q_th is bytes. When the number of backlogged bytes Q in the current sending queue is greater than Q_th, it indicates that the existing backlogged data cannot be sent within the remaining allowable delay of the high-priority event, thus triggering redundancy guarantee.
[0107] The preset packet loss threshold R_th is preset according to the test results of the vehicle communication link under the worst working condition and the allowable maximum packet loss rate of high-priority events when redundant transmission is not enabled. When R_loss>R_th and repeated transmission is triggered, the allowable number of repeated transmissions N_r is determined according to the target arrival probability P_target required by the high-priority event, where 0<P_target<1. Under the condition that 0<R_loss<1 and assuming that transmission losses of each transmission are independent of each other, the probability that both the original transmission and N_r times of repeated transmissions are all lost is R_loss^(N_r+1), therefore, the smallest positive integer satisfying R_loss^(N_r+1)≤1-P_target is selected as N_r; when R_loss=1, the preset maximum number of repeated transmissions N_r_max is adopted and link abnormality processing is triggered; when the link loss does not satisfy the mutual independence assumption, N_r is increased or R_th is decreased according to the test results of the vehicle communication link under the worst working condition, so as to adopt a more conservative redundancy strategy.
[0108] In one embodiment, to avoid frequent switching of standby communication links caused by instantaneous fluctuations in a single monitoring window, standby communication link switching or repeated transmission is only performed when consecutive K monitoring windows satisfy at least one of the following conditions: B<B_min, R_loss>R_th, T_cur>T_th or Q>Q_th; when this anti-jitter strategy is not enabled, redundancy guarantee is executed when any single monitoring window satisfies any condition. Redundancy guarantee state is exited when consecutive M monitoring windows all satisfy B≥B_min, R_loss≤βR_th, T_cur≤βT_th and Q≤βQ_th, where K and M are positive integers, and β is a recovery coefficient greater than 0 and less than 1. In one embodiment, K is 2 or 3, M is 3 or 5, and β is 0.8.
[0109] The unified recovery function on the receiving side is Reorder=g(TS,Seq,Idx,C,W), where the completion flag parameter C is either the total number of fragments N_frag or the end flag End. In N_frag mode, the receiving side determines the completeness of event data based on whether the Idx values under the same Seq continuously cover 0 to N_frag-1. In End mode, the sending side only sets End to 1 in the last fragment, and the receiving side uses the Idx of the End=1 fragment as the last fragment index, and determines whether there are missing fragments based on whether the Idx values under the same Seq continuously cover 0 to the last fragment index. If the End=1 fragment is not received by the end of the reordering time window W, the receiving side sends a request including at least the Seq and the end fragment retransmission flag. After obtaining the End=1 fragment and determining the last fragment index, it continues to check for the remaining missing fragments. The receiving side uses the above flags to complete time synchronization, deduplication, out-of-order recovery, missing fragment detection, and unified output within the reordering time window W.
[0110] If a duplicate segment from redundant transmission or a remaining segment from slow channel continuation is received within the reordering time window W, the missing segment is used to complete the replacement. If the missing segment is not obtained by the end of the reordering time window W, a missing flag is output when the missing segment belongs to a slow channel event that allows degraded output; the event is discarded when the missing segment belongs to a slow channel event configured as a non-essential event; a retransmission request is triggered when the missing segment belongs to a high-priority event and no available redundant copy has been received; and the redundant copy is used to recover the missing segment when the missing segment belongs to a high-priority event and an available redundant copy has been received. For a missing segment with a known segment index, the retransmission request includes at least Seq and Idx, and may also include TS or event identifier to uniquely locate the corresponding segment in the transmission buffer; the transmitting side locates the corresponding segment in the transmission buffer according to the retransmission request and retransmits it.
[0111] Figure 1 The specific structural composition of the low-latency communication device of the dual-domain controller of the present invention is shown. The low-latency communication device in this embodiment is jointly composed of a classification and prioritization module 512 in the transmission domain 510 and a communication device 530. The communication device 530 is the transmission processing part of the low-latency communication device, including a fast channel 531, a slow channel 532, a preemption scheduler 533, a congestion detection module 534, a redundant link 535, and corresponding communication interfaces. The fast channel 531 and the slow channel 532 constitute the main communication link; the communication interface includes interfaces respectively associated with the fast channel 531, the slow channel 532, and the redundant link 535.
[0112] The sending domain 510 is also configured with an event queue 511 and an encapsulation and timestamp unit 513 responsible for data identification. Events to be sent are queued in the event queue 511. The classification and priority module 512 reads the event identifier, event source module, event status, data length, and event type, and determines the event priority and the maximum allowable delay for inter-domain communication according to the event attribute configuration table. The encapsulation and timestamp unit 513 writes a timestamp, sequence number, fragment index, and total number of fragments or end identifier to the event data corresponding to the event to be sent.
[0113] Fast channel 531 is used to carry events with priority P1 or P2 and a maximum allowable inter-domain communication delay of less than or equal to 20 ms; slow channel 532 is used to carry other events that do not meet the above fast channel allocation conditions. The preemption scheduler 533 performs transmission arbitration, preemption judgment, and breakpoint recovery based on the classification results output by the classification and priority module 512. For subsequent interruptible data units that have not yet been written to the physical link, the preemption scheduler 533 pauses transmission and records the sequence number of the corresponding slow channel event and the next pending transmission position; for physical frames that have been written to the physical link and are uninterruptible, the preemption scheduler 533 pauses the transmission of subsequent slow channel event data after the physical frame is transmitted and records the next pending transmission position after the physical frame is transmitted.
[0114] The congestion detection module 534 acquires the link status of the main communication link and redundant link 535 according to a preset monitoring period. The link status includes at least available bandwidth, packet loss rate, high-priority event queuing delay statistics, queue backlog, and acknowledgment feedback status. The congestion detection module 534 compares the link status parameters with corresponding preset thresholds. When at least one of the following conditions is met: available bandwidth is less than the preset minimum available bandwidth, packet loss rate is greater than the preset packet loss threshold, high-priority event queuing delay statistics are greater than the preset delay threshold, or queue backlog is greater than the preset backlog threshold, the congestion detection module 534 outputs a redundancy guarantee trigger signal to the preemption scheduler 533.
[0115] The preemption scheduler 533 determines whether the redundant link 535 is available based on the redundancy protection trigger signal. The availability of the redundant link 535 means that it has completed the link handshake, can normally receive acknowledgment feedback, and its packet loss rate is less than or equal to the preset backup link packet loss threshold. When the redundant link 535 is available, the preemption scheduler 533 controls the communication interface to switch high-priority events from the primary communication link to the redundant link 535 for transmission; when the redundant link 535 is not configured or is unavailable, the preemption scheduler 533 controls the communication interface to repeatedly transmit high-priority events on the primary communication link; when link status deterioration is still detected after switching to the redundant link 535, the preemption scheduler 533 controls the communication interface to repeatedly transmit high-priority events on the redundant link 535.
[0116] Each repeatedly transmitted event copy carries the same timestamp, sequence number, and fragment index. Data transmitted via fast channel 531, slow channel 532, or redundant link 535 all enter the receive buffer 521 in the receive domain 520. The event restorer 522 performs time synchronization, deduplication, out-of-order recovery, fragment missing detection, and fragment missing completion based on the timestamp, sequence number, and fragment index, ultimately forming a unified output sequence with consistent timing. The following describes the rearrangement and recovery processing of the receive domain after acquiring the dual-channel data from the underlying link.
[0117] After capturing incoming packets from the fast and slow channels, the receiving end first delivers them to the fast channel buffer and slow channel buffer in the input buffer, respectively. During this stage, the system synchronously extracts and parses the timestamp (TS), sequence number (Seq), fragment index (Idx), and total number of fragments or end identifier (N_frag / End) of the underlying packet encapsulation. If the packet carries a priority field, this field is also parsed; otherwise, the priority is determined by querying the event attribute configuration table consistent with the sending side, based on the event identifier carried in the packet, or based on the Seq-event identifier mapping established during the event header or connection initialization phase. This metadata forms the data foundation for subsequent out-of-order reordering and concatenation mechanisms.
[0118] After entering the core processing flow, the time synchronization unit intervenes first. Based on the extracted timestamps, it establishes a unified clock reference for heterogeneous data arriving across channels and performs underlying latency compensation to eliminate the interference of inherent time differences in multi-channel transmission on timing judgment. Next, the system introduces a rearrangement time window W as the aggregation scale. Within the set time window, the system centrally aggregates all arriving candidate segments and hands them over to the recovery and completion unit for processing. This unit reorders packets out of order caused by segment preemption or link jitter on the sending side; identifies and removes duplicate packets generated by congestion redundancy mechanisms; and performs completion of missing segments within the time window's allowable range. If the missing segment is not obtained by the end of the time window, a missing flag is output when the missing segment belongs to a slow channel event that allows degraded output; the event is discarded when the missing segment belongs to a slow channel event configured as a non-essential event; a retransmission request is triggered when the missing segment belongs to a high-priority event and no available redundant copy has been received; and the redundant copy is used for recovery when the missing segment belongs to a high-priority event and an available redundant copy has been received.
[0119] After the aforementioned time synchronization, aggregation, and recovery processes, the previously fragmented, out-of-order, and potentially overlapping input segments at the transmission layer are reassembled and reconstructed. The system ultimately generates a unified output sequence based on the output scheduling principle of "prioritizing the output of high-priority events while meeting the maximum allowable latency for communication between high-priority event domains, supplementing or marking slow-channel events, and invalidating those exceeding the window according to service configuration." In this sequence, P1-level risk alarms (such as Seq101) are placed in the priority reading position, while slow-channel service messages such as attitude speed, navigation refresh, and media logs (Seq102 to Seq104) are arranged sequentially in the correct time order or accompanied by missing markers, thereby delivering a logically complete and time-accurate data stream to the upper-layer safety control domain and intelligent cockpit domain.
[0120] like Figure 2 As shown, this embodiment provides a low-latency communication method applied to the transmitting side of a dual-domain controller for two-wheeled vehicles. First, in step S110, the transmitting side reads the event identifier, event source module, event status, data length, and event type carried by the event to be transmitted, and queries the event attribute configuration table to obtain an event attribute model that includes at least the event priority and the maximum allowable inter-domain communication latency. Then, in step S120, the transmitting side classifies the events to be transmitted according to the event attribute model, assigning events with a priority of P1 or P2 and a maximum allowable inter-domain communication latency less than or equal to a first preset threshold to the fast channel, and assigning other events to the slow channel.
[0121] In step S130, for events allocated to the slow channel, the sending side divides them into slow channel event fragments according to the preset fragment length, maximum transmission unit, protocol frame boundary, or fragmentable transmission unit boundary, and transmits them through the slow channel. During the transmission of slow channel event fragments, if a high-priority event is detected in step S141 and meets the preset preemption trigger condition, preemption processing is initiated; if no high-priority event is detected, or the high-priority event does not meet the preset preemption trigger condition, step S130 continues. After entering preemption processing, in step S142, it is determined whether the current data unit has been written to the physical link and is uninterruptible; if it has not been written to the physical link or belongs to an interruptible data unit, in step S143a, transmission is paused at the level of the transmission buffer, the waiting queue, or the fragmentable transmission unit, and the Seq and the next waiting position are recorded; if the current physical frame has been written to the physical link and is uninterruptible, in step S143b, after the physical frame is transmitted, the transmission of subsequent slow channel event data is paused, and the next waiting position after the physical frame is transmitted is recorded.
[0122] Subsequently, in step S150, the sending side prioritizes the transmission of the high-priority event through the fast channel. In step S160, after the high-priority event transmission is completed, the sending side resumes the transmission of the remaining data of the slow channel event based on the Seq and the next transmission position. Through the above process, transmission resources can be promptly relinquished during slow channel service transmission, allowing high-priority events that meet low-latency requirements to be transmitted first, while avoiding the complete discarding of slow channel events, thus balancing low-latency transmission of critical events with continuous transmission of general services.
[0123] In one implementation, the event to be sent is generated and encapsulated by the event source module that generated the event. The event source module refers to a software task, application process, functional unit, or hardware interface unit in the security control domain or intelligent cockpit domain used to generate the corresponding business event, including but not limited to collision detection modules, vehicle attitude detection modules, speed acquisition modules, braking status monitoring modules, navigation modules, media modules, and log management modules. During system initialization, a source module identifier (SourceID) is assigned to each event source module. This Source ID can be implemented using a pre-assigned numerical code, task number, process number, communication node number, or interface number, and is stored in the module registry. When generating an event, the event source module writes its own Source ID into the event header. The classification and priority module reads the Source ID from the event header to determine the source of the event.
[0124] In one implementation, the Event ID is used to distinguish between different event categories and different event instances within the same category. The Event ID can be formed by combining the Source Module ID, the Event Type Code, and the Event Sequence Number Seq. The Source Module ID indicates the functional module that generated the event; the Event Type Code indicates event categories such as collision alarms, fall risk alarms, attitude synchronization, navigation refresh, media data, or log data; and the Event Sequence Number is generated by the event source module in ascending order of event generation to distinguish multiple consecutively generated event instances. For example, the Event ID can be represented by a fixed-length field, where the high-order field stores the Source Module ID, the middle field stores the Event Type Code, and the low-order field stores the Event Sequence Number; alternatively, the Source Module ID, Event Type Code, and Event Sequence Number can be written as independent fields in the event header. The classification and priority module obtains the event category, generation source, and instance order of the event to be sent by reading the Event ID, Source ID, Type Code, Seq, data length, and timestamp from the event header.
[0125] In one implementation, after generating an event to be sent, the event source module writes the event and its header into shared memory, an inter-process communication cache, a message queue, or the transmission cache of a communication device, and submits the corresponding queue descriptor to the event queue. The queue descriptor includes at least the event data storage address, event identifier, source module identifier, event type, data length, and event generation time. When the classification and priority module detects a new queue descriptor entering the event queue, it reads the queue descriptor or the event header it points to, thereby obtaining the event identifier, event source module, event status, data length, and event type. The event status may include newly generated status, pending transmission status, transmitting status, paused status, retransmission status, and transmission completed status, and is updated by the event source module, preemption scheduler, or transmission recovery module according to the event processing progress.
[0126] In one implementation, a pre-stored event attribute configuration table is a mapping table between event categories and communication attributes. It is stored in the non-volatile memory, configuration file area, or parameter storage area of the sending domain controller and loaded into the runtime memory when the communication device starts. Each configuration record in the event attribute configuration table includes at least the source module identifier, event type code, basic priority, maximum allowable delay, default sending channel, and whether fragmentation is allowed. It may also include fields such as maximum data length, preset fragment length, whether acknowledgment feedback is required, whether redundant sending is enabled, allowed retransmission count, and reordering time window. The classification and priority module uses at least one of the source module identifier and event type code as a query key to find the corresponding configuration record in the event attribute configuration table and constructs the event attribute model based on the found basic priority and maximum allowable delay.
[0127] For example, the event attribute configuration table can be configured as follows: collision alarms, fall risk alarms, roll risk alarms, or braking anomaly alarms correspond to P1 level, with a maximum allowable latency of less than or equal to 20ms, and are assigned to the fast channel by default with redundancy protection enabled; attitude or speed synchronization events correspond to P2 level, with a maximum allowable latency of less than or equal to 20ms, and are assigned to the fast channel by default; navigation refresh events correspond to P3 level, are assigned to the slow channel by default and fragmentation is allowed; media data or log data correspond to P4 level, are assigned to the slow channel by default and fragmentation is allowed. These parameters can be configured according to vehicle model, communication bus bandwidth, and service real-time requirements. For events that do not have a matching record in the event attribute configuration table, the classification and priority module sets them to the preset default priority, preferably P4 level, and assigns them to the slow channel. Simultaneously, a configuration missing identifier or anomaly log is generated to prevent unidentified events from occupying fast channel resources.
[0128] The event attribute configuration table can be fixed during vehicle controller software compilation or updated during system initialization, software upgrades, or parameter calibration. When updating the event attribute configuration table, version number verification, integrity verification, or a checksum verification are performed on the updated data. After successful verification, the updated configuration table is written to non-volatile memory and takes effect in the next communication cycle or the next system startup. Through this method, the event identifier, event source module, and event attribute configuration table all have clearly defined data structures, generation methods, storage locations, and query processes. The classification and priority module can then determine the basic priority of the event to be sent and the maximum allowable inter-domain communication delay based on this information.
[0129] In one implementation, the switching of the backup communication link is jointly performed by the link management unit and the communication interface module. When the link management unit detects that the packet loss rate, queuing delay, available bandwidth, or queue backlog of the primary communication link meet preset link switching conditions, it sends a backup link switching command to the communication interface module. Upon receiving the backup link switching command, the communication interface module sequentially executes the following steps: pausing the writing of new high-priority events to the primary communication link, enabling the backup communication interface, detecting the status of the backup communication link, completing necessary handshakes or synchronizations, mapping the transmission buffer of high-priority events to be sent to the backup communication interface, and confirming that the backup communication interface has entered a transmittable state. When the backup communication interface returns a transmit-ready flag, the link management unit controls the high-priority events to be sent through the backup communication link.
[0130] The term T_switch represents the estimated duration from the moment the link management unit issues the backup link switching command to the moment the backup communication interface enters the transmit-ready state. Specifically, the link management unit records a first time t0 when issuing the backup link switching command and a second time t1 when receiving the transmit-ready flag returned by the backup communication interface. The actual switching duration for a single transaction is t1 - t0. T_switch can be determined by the sum of the backup interface activation duration, link status detection duration, handshake or synchronization duration, transmit path redirection duration, and backup transmit queue waiting duration, i.e.:
[0131] T_switch=T_enable+T_detect+T_handshake+T_route+T_queue;
[0132] Where T_enable is the time required for the backup communication interface to enter the working state from the off or standby state, T_detect is the time required to detect whether the backup communication link is available, T_handshake is the time required for the backup communication link to complete the handshake, synchronization, or connection confirmation, T_route is the time required to switch the transmission path of the event to be sent from the primary communication link to the backup communication link, and T_queue is the estimated waiting time generated by the backup communication link's transmission queue. For logical backup channels that do not require enabling, handshaking, or synchronization, the corresponding duration is zero.
[0133] T_switch can be determined using a pre-calibrated value or a runtime measurement value. When using the pre-calibration method, multiple primary / backup link switchover tests are performed during the vehicle controller commissioning phase, and the maximum switchover duration obtained from the tests or the upper limit corresponding to the preset signal level is stored as T_switch. When using the runtime measurement method, the link management unit saves the most recent M actual switchover durations and uses the sum or weighted average of the maximum value, average value, and preset margin of the most recent M actual switchover durations as the T_switch used for the next switchover. When the backup communication link is not used for a long time, it is preferable to use the pre-calibrated upper limit of the switchover duration to prevent underestimating the actual switchover time of the backup communication link.
[0134] The T_guard is a preset safety protection duration used to absorb clock synchronization errors, task scheduling jitter, communication bus arbitration fluctuations, and data processing errors. T_guard can be determined based on the maximum clock deviation ΔT_clk between the transmitting and receiving domains, the maximum scheduling jitter ΔT_sched of the communication task, the maximum arbitration wait fluctuation ΔT_bus of the communication bus, and the maximum time error ΔT_proc of event encapsulation and interface processing.
[0135] T_guard=ΔT_clk+ΔT_sched+ΔT_bus+ΔT_proc.
[0136] Specifically, ΔT_clk can be measured through periodic synchronization messages or a unified system clock between the sending and receiving domains; ΔT_sched can be determined based on the scheduling cycle, task priority, and operating system scheduling records of the communication task; ΔT_bus can be determined based on the bus arbitration waiting time statistics within a preset sampling period; and ΔT_proc can be determined based on the processing time of event encapsulation, buffer copying, interface calls, and status feedback. These parameters can be measured during system calibration and their corresponding upper limits stored in the parameter storage area, or they can be periodically updated during system operation. Preferably, T_guard is the sum of the maximum errors of each parameter, or the sum of the statistical upper limits of each parameter, to avoid high-priority events exceeding the maximum allowable delay due to timing errors or scheduling fluctuations.
[0137] For example, in an implementation with a communication task scheduling period of 1ms, when the maximum clock deviation between the sending and receiving domains is 0.1ms, the maximum communication task scheduling jitter is 0.5ms, the bus arbitration wait fluctuation is 0.3ms, and the event encapsulation and interface processing error is 0.1ms, T_guard can be set to 1ms. This value is only an example; the actual value is determined based on the controller, operating system, communication protocol, and bus load used.
[0138] When performing the backup communication link switching determination, the preemption scheduler or link management unit performs the determination based on the maximum allowable delay T_req of the current high-priority event, the current waiting time T_wait, the estimated transmission time T_hi of the high-priority event, the estimated switching time T_switch of the backup communication link, and the security protection time T_guard. When the following formula is satisfied, it is determined that transmission can be completed within the maximum allowable delay through the backup communication link:
[0139] T_wait+T_switch+T_hi+T_guard≤T_req.
[0140] T_hi is determined based on the data length of the high-priority event, the protocol overhead length, the expected retransmission overhead length, and the available bandwidth of the backup communication link. When the above conditions are met and the backup communication link is available, the high-priority event is switched to the backup communication link for transmission. When the above conditions are not met, the backup communication link is not configured, or the backup communication link is unavailable, the preemptive scheduler immediately suspends slow channel transmission and prioritizes releasing the main communication link resources, or performs repeated transmission or parallel redundant transmission for the high-priority event to select the available transmission path with the earlier expected completion time. By incorporating T_switch and T_guard into the delay constraint determination, actual transmission timeouts can be avoided by switching links solely based on the event's own transmission duration.
[0141] Those skilled in the art should understand that the above-described specific embodiments are only used to illustrate the technical solutions of the present invention in detail, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should recognize that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. These modifications or substitutions do not cause the essence of the corresponding technical solutions to depart from the spirit and scope of the technical solutions of the embodiments of the present invention.
Claims
1. A low-latency communication method, characterized in that, The method includes: Obtain the event attribute model of the event to be sent, wherein the event attribute model includes at least the event priority and the maximum allowable inter-domain communication delay; The events to be sent are classified according to the event attribute model. Events with priority P1 or P2 and maximum allowable inter-domain communication latency less than or equal to a first preset threshold are assigned to the fast channel, while other events are assigned to the slow channel. Here, P1 and P2 are high priority levels in the preset priority levels. The fast channel has higher scheduling priority, shorter transmission waiting time, or higher preemption authority than the slow channel. The high priority events are those with priority P1 or P2 and maximum allowable inter-domain communication latency less than or equal to the first preset threshold. The slow channel events are those that have not been assigned to the fast channel. The slow channel event is divided into slow channel event segments according to a preset segment length, maximum transmission unit, protocol frame boundary, or fragmentable transmission unit boundary, and the slow channel event segments are transmitted through the slow channel. During the transmission of the slow channel event fragment, if a high-priority event is detected, and continuing to transmit the current slow channel event fragment until the next interruptible boundary would cause the sum of the current waiting time of the high-priority event, the expected blocking time from the current scheduling time to the next interruptible boundary, and the expected transmission time of the high-priority event to be greater than the maximum allowable inter-domain communication delay of the high-priority event, then the preset preemption trigger condition is determined to be met. For subsequent interruptible data units that have not yet been written to the physical link, transmission is paused at the level of the transmission buffer, the queue to be transmitted, or the fragmentable transmission unit, and the sequence number of the slow channel event and the next position to be transmitted are recorded. The next position to be transmitted includes the fragment index and the byte offset within the fragment when the next position to be transmitted is within the current slow channel event fragment. For physical frames that have been written to the physical link and are uninterruptible, the transmission of subsequent slow channel event data is paused after the physical frame is transmitted, and the next position to be transmitted is recorded. The high-priority events are sent preferentially through the fast channel; After the high-priority event is sent, the transmission of the remaining data of the slow channel event is resumed based on the sequence number and the next to be sent position. Wherein, when the transmission confirmation mechanism is not enabled, the completion of the transmission of the last uninterruptible physical frame corresponding to the high-priority event is used as the condition for determining the completion of the high-priority event transmission. When the transmission confirmation mechanism is enabled, the receipt of confirmation feedback indicating that the high-priority event transmission is completed is used as the condition for determining the completion of the high-priority event transmission.
2. The low-latency communication method according to claim 1, characterized in that, The method further includes: Before actually sending the event data corresponding to the event to be sent, the high-priority event, or the slow channel event segment, write the timestamp, sequence number, segment index, and total number of segments or end identifier into the event data; The timestamp, sequence number, fragment index, and total number of fragments or end identifier are used by the receiving side to perform deduplication, out-of-order recovery, missing fragment judgment, and missing fragment filling on the data from the fast channel and the slow channel based on a preset rearrangement time window; the missing fragment filling is completed by using the corresponding missing fragments from the slow channel resumed or retransmitted, or by using the duplicate fragments from the redundant transmission.
3. The low-latency communication method according to claim 1, characterized in that, The method also includes link status monitoring and redundancy assurance steps: Configure a link state model, which includes at least the queuing delay statistics for high-priority events, available bandwidth, packet loss rate, and queue backlog. Redundancy protection is triggered when at least one of the following conditions is detected: the available bandwidth is less than the preset minimum available bandwidth, the packet loss rate is greater than the preset packet loss threshold, the high-priority event queuing delay statistics are greater than the preset delay threshold, or the queue backlog is greater than the preset backlog threshold. When a backup communication link is configured and the backup communication link is available, the high-priority event is switched from the primary communication link to the backup communication link for transmission; when no backup communication link is configured, the backup communication link is unavailable, or at least one of the aforementioned situations is detected after transmission through the backup communication link, the high-priority event is retransmitted on the currently available communication link, wherein the currently available communication link is the backup communication link when the switch to the backup communication link has been successful, otherwise it is the primary communication link.
4. The low-latency communication method according to claim 1, characterized in that, The event attribute model also includes data length and event type; The event priority is divided into four levels, P1 to P4. P1 is used for collision alarms, fall risk alarms, roll risk alarms or braking abnormality alarms, P2 is used for attitude or speed synchronization, P3 is used for navigation refresh, and P4 is used for media data or log data. The first preset threshold is 20 ms.
5. A low-latency communication device, characterized in that, The device, applied to the transmitting side of a dual-domain controller for two-wheeled vehicles, includes: The classification and priority module is used to obtain the event attribute model of the events to be sent, and classify the events to be sent according to the event attribute model. Events with event priorities of P1 or P2 and maximum allowable inter-domain communication latency less than or equal to a first preset threshold are assigned to the fast channel, and other events are assigned to the slow channel. The event attribute model includes at least event priority and maximum allowable inter-domain communication latency. P1 and P2 are high priority levels in the preset priority hierarchy. The fast channel has higher scheduling priority, shorter transmission waiting time, or higher preemption authority than the slow channel. The high priority events are those with event priorities of P1 or P2 and maximum allowable inter-domain communication latency less than or equal to the first preset threshold. The slow channel events are those not assigned to the fast channel. The classification and priority module is also used to divide the slow channel events into slow channel event fragments according to a preset fragment length, maximum transmission unit, protocol frame boundary, or fragmentable transmission unit boundary. A preemptive scheduler is configured to determine if, during the transmission of the slow-channel event segment, a high-priority event is detected, and if continuing to transmit the current slow-channel event segment until the next interruptible boundary would result in the sum of the current waiting time of the high-priority event, the expected blocking time from the current scheduling time to the next interruptible boundary, and the expected transmission time of the high-priority event being greater than the maximum allowable inter-domain communication delay of the high-priority event, then a preset preemptive trigger condition is met. For subsequent interruptible data units that have not yet been written to the physical link, transmission is paused at the level of the transmission buffer, the waiting queue, or the fragmentable transmission unit, and the sequence number and the next waiting position of the slow-channel event are recorded. The next waiting position includes the segment index and the position at which the next waiting position is located within the current slow-channel event segment. The byte offset within the segment; for physical frames that have been written to the physical link and are uninterruptible, the transmission of subsequent slow channel event data is paused after the physical frame is transmitted, and the next transmission position is recorded; the preemption scheduler is also used to control the communication interface module to transmit the high-priority event first through the fast channel, and after the high-priority event is transmitted, the transmission of the remaining data of the slow channel event is resumed based on the sequence number and the next transmission position; wherein, when the transmission confirmation mechanism is not enabled, the completion of the transmission of the last uninterruptible physical frame corresponding to the high-priority event is used as the condition for the completion of the transmission of the high-priority event; when the transmission confirmation mechanism is enabled, the receipt of confirmation feedback indicating that the high-priority event has been transmitted is used as the condition for the completion of the transmission of the high-priority event. The communication interface module is used to send the high-priority event through the fast channel and to send the slow channel event fragment through the slow channel.