CAN bus-based data frame transmission control method and apparatus

Abstract

This application provides a data frame transmission control method and apparatus based on a CAN bus. The method includes: maintaining a transmission window, a reception window, and a congestion window at the transmitting end; determining the current transmission window size based on the frame value with the smallest window size among the three windows; and asynchronously transmitting data in the transmission buffer queue to the receiving end in groups according to the current transmission window size. After receiving the data, the receiving end stores the data in a circular reception buffer queue, updates the receiving end window size, constructs an acknowledgment frame based on the updated receiving end window size and bitmap identifier, and sends the acknowledgment frame to the transmitting end. After receiving the acknowledgment frame, the transmitting end recalculates the current transmission window size and transmits the next group of data according to the recalculated current transmission window size. This application can improve data transmission efficiency and real-time performance.

Description

Technical Field

[0001] This application relates to the field of data processing, specifically to a data frame transmission control method and apparatus based on a CAN bus. Background Technology

[0002] In the field of industrial control and intelligent device communication, the CAN (Controller Area Network) bus, as a highly efficient and reliable fieldbus, is widely used in various distributed control systems, including water control terminal systems. Water control terminals are typically deployed in scenarios such as school bathhouses and hot water dispensers, responsible for accurately measuring and controlling water resource usage. These systems rely on the CAN bus for master-slave communication to achieve data exchange and control command transmission between devices.

[0003] Traditional CAN bus communication mechanisms exhibit significant communication bottlenecks and congestion issues in scenarios with multiple nodes online simultaneously or high-frequency interactions. Particularly when large amounts of data need to be transmitted (such as online upgrades of water control equipment) or when multiple terminals simultaneously request or execute consumption operations, the traditional frame-response mechanism (i.e., one frame, one response) cannot meet the demands for efficient and reliable data transmission. This leads to frequent network congestion, duplicate transmissions, and data delays, severely impacting overall system performance and user experience.

[0004] In view of the characteristics of CAN bus frame communication and the limited resources of water control equipment, this solution proposes a data frame transmission control method based on CAN bus, which can make full use of the advantages of CAN bus, overcome bottleneck problems, and improve data transmission efficiency and real-time performance. Summary of the Invention

[0005] To address the problems in the prior art, this application provides a data frame transmission control method and apparatus based on CAN bus, which can improve data transmission efficiency and real-time performance.

[0006] To solve at least one of the above problems, this application provides the following technical solution:

[0007] In a first aspect, this application provides a data frame transmission control method based on a CAN bus, including a transmitting end and a receiving end, the method comprising:

[0008] After receiving the upper-layer service data, the sending end encapsulates the upper-layer service data into the sending buffer queue and records the current offset position. The offset position is used to move the offset position for positioning after each group of data is successfully sent.

[0009] The sending end maintains a sending window, a receiving window, and a congestion window. The current sending window size is determined based on the minimum value of the sending window, the receiving window, and the congestion window. Data in the sending buffer queue is asynchronously sent to the receiving end in groups according to the current sending window size. The sending window is the maximum frame value of the sending buffer queue, the receiving window is the frame value returned by the receiving end, and the congestion window is the frame value output by the network congestion controller.

[0010] The receiving end receives the data sent by the sending end, performs sequence number verification on the data, stores the data in a circular receiving buffer queue, updates the receiving end window size, constructs an acknowledgment frame based on the updated receiving end window size and a preset bitmap identifier, and sends the acknowledgment frame to the sending end.

[0011] After receiving the acknowledgment frame, the sending end obtains the data reception status of the receiving end according to the bitmap identifier. If all frames in the group are acknowledged by the receiving end, the offset position is moved to trigger the next group of transmission. After updating the window size value of the original receiving window according to the updated receiving end window size, the current transmission window size is recalculated, and the next group of data is transmitted according to the recalculated current transmission window size.

[0012] Furthermore, maintaining the transmission window at the transmitting end includes:

[0013] During initialization, the sending window size is set to the maximum frame capacity of the sending buffer queue;

[0014] After each successful transmission, the sequence number of the acknowledged frame is updated according to the bitmap identifier in the acknowledgment frame returned by the sender, the transmission window space is released, and the transmission window size is redefined.

[0015] Furthermore, maintaining the receiving window at the sending end includes:

[0016] During initialization, the receive window size is set to the maximum frame capacity of the receive buffer queue;

[0017] After each successful transmission, the receiving window size is redefined based on the current receiving window size returned by the receiving end. The current receiving window size is dynamically calculated by the receiving end based on the remaining capacity of the circular receiving buffer queue.

[0018] Furthermore, maintaining the congestion window at the sending end includes:

[0019] During initialization, set the initial congestion window size and congestion window threshold;

[0020] A congestion control state machine module is constructed. The congestion control state machine module uses a state machine mechanism to dynamically adjust the initial congestion window size. The state machine mechanism includes slow start, congestion avoidance, and fast recovery. During the slow start phase, the window is expanded exponentially, and during the congestion avoidance phase, the window is expanded linearly.

[0021] Further, determining the corresponding current sending window size based on the minimum value of the sending window, the receiving window, and the congestion window includes:

[0022] The current sending window size is determined based on the window frame values ​​of the sending window, the receiving window, and the congestion window, and the current sending window size is determined based on the smallest window frame value. The current sending window size is used to determine the number of frames sent by the sending end in each group.

[0023] When the current sending window size is 0, the sending end pauses sending and triggers a probe frame to request the receiving end's window state. When the receiving end's receiving capability changes, the receiving end returns the corresponding receiving window size to the sending end, so that the sending end can determine the current sending window size based on the receiving window size.

[0024] Furthermore, after the sending end receives the acknowledgment frame and obtains the data reception status of the receiving end based on the bitmap identifier, the process further includes:

[0025] If three duplicate acknowledgment frames are detected, the fast recovery state machine mechanism is triggered to adjust the congestion window size.

[0026] If a retransmission timeout is detected, the slow start state machine mechanism is triggered to reset the congestion window size.

[0027] Further, the receiving end receives data sent by the sending end, performs sequence number verification on the data, stores the data in a circular receive buffer queue, updates the receiving end window size, constructs an acknowledgment frame based on the updated receiving end window size and a preset bitmap identifier, and sends the acknowledgment frame to the sending end, including:

[0028] The receiving end receives the data sent by the sending end, calculates the logical frame sequence number based on the group number and frame number in the received data, and if the logical frame sequence number is valid and has not been received repeatedly, the data frame is stored in the circular receiving buffer queue and the receiving end window size is updated at the same time.

[0029] Based on the frame numbers already received in the current group, a 1-byte bitmap identifier is generated, where each bit corresponds to the reception status of a logical frame sequence number in the group. The bitmap identifier and the updated receiver window size are encapsulated into the data field of the acknowledgment frame. A control frame identifier and group number are set in the frame header of the acknowledgment frame to indicate the associated data group of the acknowledgment frame. The acknowledgment frame is then sent to the sender.

[0030] Secondly, this application provides a data frame transmission control device based on a CAN bus, comprising:

[0031] The data preparation module is used to encapsulate the upper-layer service data into a sending buffer queue after the sending end receives the upper-layer service data, and record the current offset position. The offset position is used to move the offset position for positioning after each group of data is successfully sent.

[0032] The sending window determination module is used to maintain a sending window, a receiving window, and a congestion window at the sending end, determine the corresponding current sending window size based on the minimum value of the sending window, the receiving window, and the congestion window, and asynchronously send the data in the sending buffer queue to the receiving end in groups according to the current sending window size. Here, the sending window is the maximum frame value of the sending buffer queue, the receiving window is the frame value returned by the receiving end, and the congestion window is the frame value output by the network congestion controller.

[0033] The acknowledgment frame construction module is used for the receiving end to receive data sent by the sending end, to perform sequence number verification on the data and store the data in a circular receiving buffer queue, to update the receiving end window size, to construct an acknowledgment frame based on the updated receiving end window size and a preset bitmap identifier, and to send the acknowledgment frame to the sending end.

[0034] The sending result confirmation module is used to obtain the data receiving status of the receiving end according to the bitmap identifier after the sending end receives the confirmation frame. If all frames in the group are confirmed to be received by the receiving end, the offset position is moved to trigger the next group of transmission. After updating the window size value of the original receiving window according to the updated receiving end window size, the current sending window size is recalculated, and the next group of data is sent according to the recalculated current sending window size.

[0035] Thirdly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the CAN bus-based data frame transmission control method.

[0036] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the CAN bus-based data frame transmission control method.

[0037] Fifthly, this application provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the CAN bus-based data frame transmission control method.

[0038] As can be seen from the above technical solution, this application provides a data frame transmission control method and apparatus based on CAN bus. By maintaining a transmission window, a reception window, and a congestion window at the transmitting end, the current transmission window size is determined according to the frame value with the smallest window size among the three windows, and the data in the transmission buffer queue is asynchronously transmitted to the receiving end in groups according to the current transmission window size. After receiving the data, the receiving end stores the data in a circular reception buffer queue, updates the receiving end window size, constructs an acknowledgment frame based on the updated receiving end window size and bitmap identifier, and sends the acknowledgment frame to the transmitting end. After receiving the acknowledgment frame, the transmitting end recalculates the current transmission window size and transmits the next group of data according to the recalculated current transmission window size, thereby improving data transmission efficiency and real-time performance. Attached Figure Description

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

[0040] Figure 1 This is one of the flowcharts illustrating the CAN bus-based data frame transmission control method in the embodiments of this application;

[0041] Figure 2 This is a structural diagram of the CAN bus-based data frame transmission control device in the embodiments of this application;

[0042] Figure 3 This is a diagram illustrating the effect of the service data receiving buffer queue in the CAN bus-based data frame transmission control method of this application embodiment;

[0043] Figure 4 This is a schematic diagram of the structure of the electronic device in the embodiments of this application.

[0044] Figure label:

[0045] Electronic device 9600, central processing unit 9100, memory 9140, communication module 9110, input unit 9120, audio processor 9130, display 9160, power supply 9170, buffer memory 9141, application / function storage unit 9142, data storage unit 9143, driver storage unit 9144, antenna 9111, speaker 9131, microphone 9132. Detailed Implementation

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

[0047] The acquisition, storage, use, and processing of data in this application all comply with the relevant provisions of national laws and regulations.

[0048] Considering the traditional CAN bus communication mechanism, significant communication bottlenecks and congestion are exposed in scenarios with multiple nodes online simultaneously or high-frequency interaction, severely impacting the overall system performance and user experience. This application provides a data frame transmission control method and apparatus based on the CAN bus. By maintaining a transmission window, a reception window, and a congestion window at the transmitting end, the current transmission window size is determined based on the frame value with the smallest window size among the three windows. Data in the transmission buffer queue is asynchronously transmitted to the receiving end in groups according to the current transmission window size. After receiving the data, the receiving end stores the data in a circular reception buffer queue, updates its receiving end window size, constructs an acknowledgment frame based on the updated receiving end window size and bitmap identifier, and sends the acknowledgment frame to the transmitting end. After receiving the acknowledgment frame, the transmitting end recalculates the current transmission window size and transmits the next group of data based on the recalculated current transmission window size, thereby improving data transmission efficiency and real-time performance.

[0049] Background technology used in this application:

[0050] Currently, water control terminals are widely deployed in campuses, such as shower rooms and hot water dispensers, to meter and control water resource usage. Conventional water control systems rely on the CAN bus for master-slave communication, offering advantages such as strong anti-interference capabilities and good real-time performance. However, in scenarios with multiple nodes online simultaneously or high-frequency interactions, the traditional frame-response mechanism (i.e., one frame, one response) suffers from communication bottlenecks and congestion issues. Especially when large amounts of data are transmitted (e.g., online upgrades of water control equipment) or multiple terminals simultaneously request or execute consumption operations, network congestion, duplicate transmissions, and data delays can severely impact system performance.

[0051] Traditional sliding window mechanisms are commonly used in stream-based protocol stacks such as TCP. This solution proposes an application-layer sliding window control mechanism tailored to the frame-based communication characteristics of the CAN bus, supporting:

[0052] 1. Low resource consumption (compatible with STM32L431 64KB RAM):

[0053] The data buffer and window cache adopt a fixed-length, statically allocated structure;

[0054] The control logic does not depend on the TCP / IP stack.

[0055] 2. Window state compression and transmission:

[0056] The ACK response frame uses bitmap compression to represent the status of the acknowledged data frames in the window;

[0057] The sending end dynamically slides the window and releases the buffer based on the ACK bitmap to improve bandwidth utilization.

[0058] 3. CAN Feature Adaptation:

[0059] Based on the 8-byte payload limit of standard or extended frames, the packet splitting mechanism and window management are finely integrated;

[0060] The retransmission mechanism is based on frame loss / acknowledgment delay rather than packet loss detection, adapting to the CAN hardware transmission failure logic.

[0061] The sliding window mechanism ensures reliable interaction of multiple frames of business data between water control terminals on the CAN bus, enabling complete transmission and reception of core data such as consumption transaction requests, reservation status confirmation, and billing feedback. This improves system real-time performance and communication reliability, and is particularly suitable for distributed deployment scenarios of water control terminals at low resource edges.

[0062] To improve data transmission efficiency and real-time performance, this application provides an embodiment of a data frame transmission control method based on a CAN bus, see [link to embodiment]. Figure 1 The data frame transmission control method based on the CAN bus specifically includes the following:

[0063] Step S101: After receiving the upper-layer service data, the sending end encapsulates the upper-layer service data into the sending buffer queue and records the current offset position. The offset position is used to move the offset position for positioning after each group of data is successfully sent.

[0064] Optionally, in this embodiment, the application involves a transmitter and a receiver, which are connected via a CAN bus. The transmitter is located at the water control equipment terminal, and the receiver is located at the system terminal.

[0065] Since each CAN bus frame contains 8 bytes of data and the water control equipment has limited resources, our business data is encapsulated into a transmission buffer queue in 8-byte frames at the sending end. The transmission buffer maintains an offset position, and after each successful transmission, the offset position is moved until the offset position reaches the end of the data.

[0066] Specifically, the sending end first receives service data packets from upper-layer applications (such as the water control terminal business logic). These data packets contain information such as consumption transaction requests, device status updates, and firmware upgrade instructions. Their length is variable, but due to the 8-byte payload limit per frame on the CAN bus, they need to be segmented.

[0067] The transmitting end splits the service data into multiple CAN data frames in an 8-byte frame format and stores them sequentially into the transmit buffer queue. The transmit buffer queue adopts a static allocation method, and its size is aligned upward to a multiple of 8 based on the maximum length of the service data (e.g., if the maximum service data is 62 bytes, then the buffer queue is allocated 64 bytes, i.e., 8 frames).

[0068] Data frames are stored in the buffer queue as consecutive 8-byte units, for example:

[0069] [Frame 1 (8B)][Frame 2 (8B)][Frame 3 (8B)]...[Frame N (8B)]

[0070] We maintain an offset variable at the sending end, with an initial value of 0, which represents the starting position of the current data to be sent (in frames, i.e., multiples of 8 bytes).

[0071] For example, if offset=2, it means that the first two frames (16 bytes) have been successfully sent, and the next set of data should be sent starting from the third frame (the 24th byte in the buffer queue).

[0072] The offset position serves as a pointer to the transmission progress, ensuring that the sender can accurately track sent and pending data frames, avoiding duplicate transmissions or omissions. After each successful transmission of a set of data, the offset position is incremented by the actual number of frames transmitted. For example, after transmitting 4 frames, offset += 4, directly positioning the sender at the start of the next set.

[0073] It records the offset position in units of frames, reducing storage overhead (only 1 byte is needed to record the offset of 0~255 frames), and adapts to resource-constrained embedded devices (such as STM32L431).

[0074] Step S102: The sending end maintains a sending window, a receiving window, and a congestion window. The current sending window size is determined according to the minimum value of the sending window, the receiving window, and the congestion window. The data in the sending buffer queue is asynchronously sent to the receiving end in groups according to the current sending window size. Here, the sending window is the maximum frame value of the sending buffer queue, the receiving window is the frame value returned by the receiving end, and the congestion window is the frame value output by the network congestion controller.

[0075] Optionally, in this embodiment, the data in the transmit buffer queue is stored in 8-byte frames, and the data is transmitted asynchronously in groups, with each group containing at least one frame. The specific number of frames is determined by the minimum frame value among the three frame values ​​of the local transmit window, receive window, and congestion window at that time.

[0076] Optionally, in this embodiment, at the sending end, the system maintains three key windows: the sending window (swnd), the receiving window (rwnd), and the congestion window (cwnd). These three windows jointly determine the amount of data that can be sent at present, ensuring the efficiency and reliability of data transmission. Specifically:

[0077] Send window (swnd): Represents the maximum number of frames that can be sent in the send buffer queue. Its initial value is the total number of frames in the send buffer queue (i.e., the number of frames after the service data packet is split into 8 bytes). The purpose of this window is to prevent the sender from sending too much data at once, which could lead to buffer overflow or resource exhaustion.

[0078] Receive window (rwnd): Dynamically fed back by the receiver, this represents the maximum number of frames the receiver can currently receive. The receiver adjusts this value based on its remaining buffer space and notifies the sender via ACK frames or window update frames. The purpose of this window is to prevent data loss due to insufficient processing power or a full buffer at the receiver.

[0079] Congestion window (cwnd): Dynamically adjusted by the sender's congestion control mechanism, reflecting the current network congestion level. The initial value is a small number of frames (e.g., 4 frames), and it dynamically increases or decreases depending on network conditions. The purpose of this window is to prevent network overload and ensure stable data transmission.

[0080] Before sending data each time, the sending end needs to calculate the current sending window size (curwndwinsize), which is the minimum value of the three windows:

[0081] Curwndwinsize=min(swnd, rwnd, cwnd)

[0082] This calculation ensures that the transmission rate does not exceed the sender's buffer capacity (swnd), the receiver's processing capacity (rwnd), or the network's carrying capacity (cwnd).

[0083] If curwndwinsize > 4, then a maximum of 4 frames will be sent per group (to optimize transmission efficiency and avoid increasing latency due to sending too much data at once).

[0084] If curwndwinsize ≤ 4, then the number of frames sent in each group is equal to curwndwinsize (adapting to situations of network congestion or reduced processing capacity at the receiving end).

[0085] If curlwndwinsize = 0, it means that data cannot be sent at the moment. The sender will send a probe frame to inquire about the window status of the receiver to avoid long-term blocking.

[0086] Optionally, in this embodiment, the sending end asynchronously sends data in groups. Because it's asynchronous, there are concerns about out-of-order delivery and whether each group is received in a timely manner. In addition to the packet sequence number, each transmitted data frame also stores the total number of frames in the current group. This allows the receiving end to know promptly when reception is complete.

[0087] The numbering rules for frames within a group are as follows:

[0088] Group ID: Globally incrementing, used to identify different data groups.

[0089] Frame ID: The frame number (0~3) within each group, used to identify the order within the group.

[0090] Logical frame sequence number = group number × 4 + frame number, used to uniquely identify each frame.

[0091] This step avoids overload on the sending or receiving end by dynamically adjusting the sending window; it prevents data loss or increased latency due to network congestion by using a congestion window mechanism; and it reduces waiting time and improves the utilization of the CAN bus by sending asynchronously in groups, adapting to different load scenarios.

[0092] Step S103: The receiving end receives the data sent by the sending end, performs sequence number verification on the data, stores the data in a circular receiving buffer queue, updates the receiving end window size, constructs an acknowledgment frame based on the updated receiving end window size and a preset bitmap identifier, and sends the acknowledgment frame to the sending end.

[0093] Optionally, in this embodiment, after the sending end sends data frames in groups, the receiving end obtains the data frames through the CAN bus interface.

[0094] First, the receiving end parses the group number and frame number of the data frame and calculates its logical sequence number (group number × 4 + frame number). Then, the receiving end checks whether this sequence number has already been registered.

[0095] If the sequence number has already been registered, it means that the frame is a duplicate frame, and the receiving end will discard it directly to avoid data redundancy.

[0096] If the sequence number is not registered: the receiving end records the sequence number of the frame in the local management table for subsequent verification.

[0097] We maintain a circular receive buffer queue at the receiving end, the size of which is aligned to an integer multiple of 8 bytes based on the maximum length of the service data (e.g., if the maximum packet is 62 bytes, the buffer queue is 64 bytes). The receiving end stores data according to the following steps:

[0098] Calculate the storage location and determine its storage offset in the circular queue based on the frame's sequence number.

[0099] Write data by writing the payload (≤8 bytes) of the data frame to the corresponding location.

[0100] Update the queue status and record the current write position to ensure that subsequent data can be correctly overwritten or appended.

[0101] Next, the capacity of the receiving window is updated based on the received data.

[0102] The receiver's receive window (rwnd) represents the number of new data frames that can be received at present, and its initial value is equal to the total frame capacity of the circular queue. The receive window is decremented by 1 for each successfully received data frame; when a complete set of data is received and submitted to the upper layer, the receive window is increased by the corresponding number of frames. The specific logic is as follows:

[0103] Single frame reception: For each frame stored, rwnd = rwnd -1.

[0104] Whole group submission: When it is detected that a group of data has been completely received (by judging by frame number and group length), the data is submitted to the upper-layer business module in sequence, and rwnd = rwnd + number of submitted frames is updated.

[0105] The window feedback mechanism allows the sending end to perceive the receiving end's processing capabilities in real time.

[0106] Then, the receiving end generates an ACK confirmation frame using bitmap compression technology, the structure of which includes:

[0107] Receive window size (1 byte): Feedback on the number of remaining frames that can be received (obtained from the previous step).

[0108] Acknowledgment packet identifier (1 byte): Uses 8 bits to indicate the reception status of frames within the group (e.g., Bit0=1 indicates that the frame with the current frame sequence number -1 has been received).

[0109] For example, the ACK confirmation frame format is as follows:

[0110]

[0111] Because the sequence numbers of the four frames are incremented by 1, for a single ACK acknowledgment packet, the sequence numbers of all four packets must be within the range of [-4 + current packet sequence number, 4 + current packet sequence number].

[0112] Packet sequence number = group number × 4 + frame number

[0113] The current packet sequence number range [-4, 4] can be represented by 8 bits in 1 byte.

[0114] That is, each ACK acknowledgment packet carries a 1-byte acknowledgment packet identifier. Each bit in the acknowledgment packet identifier represents the deviation value between the sequence number of other packets that have been received and the sequence number of the current packet.

[0115] The structure of the planned confirmation packet identifier is as follows: (bit represents a byte)

[0116]

[0117] Bit0--- A sequence number that is 1 less than the current packet sequence number. A value of 1 indicates that the packet has been received, and a value of 0 indicates that the packet has not been received.

[0118] Bit1--- A sequence number that is 2 less than the current packet sequence number. A value of 1 indicates that the packet has been received, and a value of 0 indicates that the packet has not been received.

[0119] Bit2--- A sequence number 3 less than the current packet sequence number. A value of 1 indicates that the packet has been received, and a value of 0 indicates that the packet has not been received.

[0120] Bit3--- A sequence number 4 less than the current packet sequence number. A value of 1 indicates that the packet has been received, and a value of 0 indicates that the packet has not been received.

[0121] Bit4--- A sequence number that is 1 greater than the current packet sequence number. A value of 1 indicates that the packet has been received, and a value of 0 indicates that the packet has not been received.

[0122] Bit5 --- A sequence number that is 2 greater than the current packet sequence number. A value of 1 indicates that the packet has been received, and a value of 0 indicates that the packet has not been received.

[0123] Bit6 --- A sequence number 3 greater than the current packet sequence number. A value of 1 indicates that the packet has been received, and a value of 0 indicates that the packet has not been received.

[0124] Bit7 --- A sequence number 4 greater than the current packet sequence number. A value of 1 indicates that the packet has been received, and a value of 0 indicates that the packet has not been received.

[0125] For example, the packet numbers of the sent data frames are 123, 124, 125, and 126.

[0126] Upon receiving an ACK packet with 124, the binary representation of the acknowledgment packet is: 10001100.

[0127] The ACK packet with sequence number 124 confirms that the receiving end has received packets 123, 124, 125, and 126.

[0128] The receiving end sends the constructed ACK frame to the sending end via the CAN bus, and the frame type is marked as a control frame.

[0129] Optionally, the frame design is as follows:

[0130] Frame structure:

[0131]

[0132] can_id 4-byte planning

[0133] 0-20 bits: Represents the device ID address

[0134] Bits 21-26: Represent the group number in 6-digit increments.

[0135] Bits 27-28: Indicate the frame number range 0-3

[0136] can_dlc bytes

[0137] -3 bits: Indicates the actual length of the data.

[0138] 7 bits: where 0 indicates a data frame and 1 indicates a control frame.

[0139] When the 7th bit is 0

[0140] -6 bits: Indicates the total number of actual frames in the group, with a maximum of 4 frames and a minimum of 1 data frame.

[0141] When the 7th bit is 1

[0142] Bits 4-6: Indicate the type of control frame.

[0143] 000 -- ACK confirmation frame

[0144] 001 -- Frame returned by the receiver updating the receive window size

[0145] 002 -- Probe frame requesting the size of the receive window from the sending end

[0146] 8 bytes of data

[0147] When the frame is a data frame, it represents the data of the service packet; when the frame is a control frame, it represents the content of the control frame.

[0148] Optional frame types include the following:

[0149] 1. Data frames sent by the sending end:

[0150] Frame header: includes data frame identifier, group number and frame number in can_id.

[0151] Data content:

[0152]

[0153] 2. The frame returned by the receiving end updating the receive window size:

[0154] Frame header: includes control frame identifier, corresponding control frame 001, and group number in can_id.

[0155] Data content:

[0156]

[0157] 3. ACK confirmation frame:

[0158] Frame header: includes control frame identifier, corresponding control frame 000, and group number and frame number in can_id.

[0159] Data content:

[0160]

[0161] 4. The sending end requests a probe frame of the size of the receiving window:

[0162] Frame header: includes control frame identifier, corresponding control frame 002, and group number in can_id.

[0163] Data content: None.

[0164] This step ensures that data is not lost or duplicated through sequence number verification, ACK confirmation, and bitmap mechanisms; circular queues and bitmap compression reduce memory and bandwidth overhead; the receive window is adjusted in real time to match the processing capabilities of the sender and receiver, and the optimized design based on 8-byte frames and group numbers adapts to CAN bus limitations.

[0165] Step S104: After receiving the acknowledgment frame, the sending end obtains the data reception status of the receiving end according to the bitmap identifier. If all frames in the group are acknowledged by the receiving end, the offset position is moved to trigger the next group of transmission. After updating the window size value of the original receiving window according to the updated receiving end window size, the current transmission window size is recalculated, and the next group of data is transmitted according to the recalculated current transmission window size.

[0166] Optionally, after receiving the acknowledgment frame, the sending end first parses the bitmap identifier, i.e. the acknowledgment packet identifier, which is used to indicate the receiving end's reception status of each data frame in the current group.

[0167] Each bit in the bitmap corresponds to the reception status of a frame within the group (e.g., 1 indicates received, 0 indicates not received). Using the bitmap, the sender can accurately determine which frames have been successfully received and which frames may have been lost or need to be retransmitted.

[0168] The sending end checks the reception status of all frames in the current group based on the bitmap identifier. If all frames are acknowledged (i.e., the corresponding bits in the bitmap are all 1), it means that the group of data has been completely delivered to the receiving end, and the sending end can safely move the offset position to prepare to send the next group of data. If there are unacknowledged frames, they need to be handled accordingly according to the protocol rules (such as timeout retransmission or fast retransmission mechanism).

[0169] If all frames in the current group are acknowledged, the sender will move the offset position of the transmit buffer queue forward by a step equal to the number of frames in the current group. For example, if a group contains 4 frames, the offset position will increase by 4, pointing to the starting position of the next group of data.

[0170] Optionally, after receiving the acknowledgment frame, the sending end also needs to receive the receiver's current receive window size (rwnd) carried in the acknowledgment frame. This value represents the number of data frames that the receiver can still buffer. The sending end updates its local receive window size based on this value to ensure that the amount of data subsequently sent does not exceed the receiver's processing capacity.

[0171] Optionally, when sending the next set of data, the sender will determine the size based on the minimum of the sending window size (swnd), the receiving window size (rwnd) fed back by the receiver, and the congestion window size (cwnd). The sending and receiving windows, as described above, are adjusted based on feedback from the receiver, while the congestion window is adjusted by the congestion control unit.

[0172] Specifically, the congestion window employs a congestion control machine mechanism to maintain a lightweight congestion control state machine.

[0173] The initial threshold is set to 16 frames, tentatively denoted as ssthresh.

[0174] The states are as follows:

[0175] Slow start phase;

[0176] Congestion avoidance phase;

[0177] Fast recovery phase;

[0178] The initial size of the congestion window cwnd is 4, and the maximum value cannot exceed the maximum number of frames N in the send buffer queue.

[0179] Each state and its state transition are as follows:

[0180] Slow start phase:

[0181] When cwnd < ssthresh, for each newly received acknowledgment packet, cwnd increases exponentially, that is, cwnd = cwnd × 2. When cwnd >= ssthresh, it enters the congestion avoidance phase.

[0182] Congestion avoidance phase:

[0183] For each round-trip data packet, cwnd increases linearly, with a maximum not exceeding the maximum number of frames N in the send buffer queue.

[0184] Fast recovery phase:

[0185] The condition for entering this phase is receiving 3 duplicate acknowledgment packets.

[0186] Adjust parameters:

[0187] ssthresh = cwnd / 2;

[0188] cwnd = ssthresh + 1;

[0189] In this phase:

[0190] When receiving a duplicate acknowledgment packet cmd, it increases linearly by 1;

[0191] When receiving a new acknowledgment packet, adjust the parameters;

[0192] cwnd = ssthresh and enter the congestion avoidance phase.

[0193] Timeout retransmission:

[0194] When the sender detects a timeout retransmission based on the acknowledgment packet, adjust the following parameters

[0195] ssthresh = cwnd / 2;

[0196] cwnd = 2;

[0197] Entering the slow start phase.

[0198] This step ensures that all data frames are correctly received through mechanisms such as frame parsing confirmation, dynamic window adjustment, and offset position sliding. Lost or erroneous frames can be quickly detected and retransmitted. Combining network conditions and receiver status, the optimal sending window size is calculated in real time to improve transmission efficiency, enabling the CAN bus-based water control terminal to achieve efficient, stable, and low-latency data communication in resource-constrained environments.

[0199] This example demonstrates that this embodiment uses a lightweight sliding window and congestion control mechanism similar to TCP to ensure reliable interaction of multi-frame service data on the CAN bus by the water control terminal; it identifies the state of the receiving window through bitmap compression, realizes the control of sending window adjustment and data frame retransmission, and has the ability to coordinate frame-level ACK and window state.

[0200] As described above, the CAN bus-based data frame transmission control method provided in this application can improve data transmission efficiency and real-time performance by maintaining a transmission window, a reception window, and a congestion window at the transmitting end, determining the current transmission window size based on the frame value with the smallest window size among the three windows, and asynchronously transmitting data in the transmission buffer queue to the receiving end in groups according to the current transmission window size. After receiving the data, the receiving end stores the data in a circular reception buffer queue, updates the receiving end window size, constructs an acknowledgment frame based on the updated receiving end window size and bitmap identifier, and sends the acknowledgment frame to the transmitting end. After receiving the acknowledgment frame, the transmitting end recalculates the current transmission window size and transmits the next group of data according to the recalculated current transmission window size.

[0201] In one embodiment of the CAN bus-based data frame transmission control method of this application, the method may further include the following:

[0202] Step S201: During initialization, the sending window size is set to the maximum frame capacity of the sending buffer queue;

[0203] Step S202: After each successful transmission, update the sequence number of the received frame according to the bitmap identifier in the acknowledgment frame returned by the sender, release the transmission window space, and redetermine the transmission window size.

[0204] Optionally, in this embodiment, at the start of communication, the sending end needs to initialize the sending window (swnd), whose size is set to the maximum frame capacity of the sending buffer queue. This value is determined by the length of the service data packet, for example:

[0205] If the maximum length of the service data packet is 64 bytes (8 bytes / frame), then the initial value of the sending window is 8 frames.

[0206] If the business data packets change dynamically, the window size is calculated based on the number of frames after the current data packet is split.

[0207] This step ensures that the sender does not send more data than the buffer capacity at once, avoiding memory overflow and providing a baseline value for subsequent dynamic window adjustment, so that the sending rate matches the buffer capacity.

[0208] Optionally, in this embodiment, after each data transmission, the sending end needs to update the sending window based on the ACK confirmation frame returned by the receiving end. The specific process is as follows:

[0209] Parsing the ACK bitmap identifier: The ACK frame contains a 1-byte bitmap, where each bit represents the reception status of a certain frame (e.g., Bit 0 indicates whether the previous frame was received). The sending end uses the bitmap to calculate which frames have been successfully received and marks them as "acknowledged".

[0210] Release transmission window space: If all frames in a group are acknowledged (e.g., the ACK bitmaps of all 4 frames in the group are all 1), then move the offset position of the transmission buffer queue to release the window space occupied by the successfully transmitted frames.

[0211] The updated send window size (swnd) is:

[0212] Swnd = Maximum frame size - Number of frames sent but not acknowledged

[0213] Through step S202, this embodiment successfully maintains a sending window, adjusts the window in real time according to the ACK feedback, and ensures that new data can enter the sending queue in a timely manner by releasing the space of the confirmed frames.

[0214] In one embodiment of the CAN bus-based data frame transmission control method of this application, the method may further include the following:

[0215] Step S301: During initialization, the receive window size is set to the maximum frame capacity of the receive buffer queue;

[0216] Step S302: After each successful transmission, the receiving window size is re-determined based on the current receiving window size returned by the receiving end. The current receiving window size is dynamically calculated by the receiving end based on the remaining capacity of the circular receiving buffer queue.

[0217] Optionally, in this embodiment, during the system initialization phase, the size of the receive window (rwnd) is set to the maximum frame capacity of the receive buffer queue. This value is determined by the maximum length of the service data packet and is calculated with 8-byte alignment. For example, if the maximum service data packet is 64 bytes, the initial value of the receive window is 8 frames (64 ÷ 8).

[0218] This step ensures that the receiving end has sufficient buffer space to avoid data not being received properly due to an initial window that is too small, and provides an initial flow control baseline to prevent the sending end from sending too much data in the early stages of communication, exceeding the receiving end's processing capacity.

[0219] Optionally, in this embodiment, during data transmission, the size of the receiving window is dynamically updated according to the real-time buffer status of the receiving end. The specific process is as follows:

[0220] The receiving end maintains a circular receive buffer queue to store received data frames. After each successful reception and processing of data, the remaining space in the queue changes. The receiving end calculates the maximum number of frames that can be received at the moment, i.e., the current receive window size (rwnd), based on the remaining space.

[0221] When the receiving end sends an ACK confirmation frame, it carries information about the current receiving window size. If the receiving window changes significantly (such as due to changes in data processing speed), the receiving end can proactively send a window update control frame to notify the sending end.

[0222] The sending end updates the locally recorded receive window size based on the rwnd value fed back by the receiving end. Combining the sending window (swnd) and the congestion window (cwnd), it recalculates the number of frames that can be sent at present, ensuring that the sending rate matches the processing capacity of the receiving end.

[0223] Through step S302, this embodiment successfully maintains a receiving window, preventing packet loss due to full buffer at the receiving end, improving the reliability of data transmission, optimizing the sending rate according to the real-time load of the receiving end, ensuring efficient utilization of the receiving end's buffer, and reducing data backlog and delay.

[0224] In one embodiment of the CAN bus-based data frame transmission control method of this application, the method may further include the following:

[0225] Step S401: During initialization, set the initial congestion window size and congestion window threshold;

[0226] Step S402: Construct a congestion control state machine module. The congestion control state machine module uses a state machine mechanism to dynamically adjust the initial congestion window size. The state machine mechanism includes slow start, congestion avoidance, and fast recovery. During the slow start phase, the window is expanded exponentially, and during the congestion avoidance phase, the window is expanded linearly.

[0227] Optionally, in this embodiment, the sending end needs to initialize the key parameters of congestion control before data transmission begins:

[0228] Initial congestion window size (cwnd): This is usually set to a small value (e.g., 4 frames) to avoid sending too much data in the initial stage and causing network congestion.

[0229] Congestion window threshold (ssthresh): The initial value is usually set to a high value (such as 16 frames) to distinguish between the slow start and congestion avoidance phases.

[0230] By setting reasonable initial values, we can ensure that network capacity can be quickly detected in the early stages of data transmission, without causing congestion due to aggressive transmission.

[0231] Optionally, in this embodiment, the congestion control state machine adapts to network conditions by dynamically adjusting the window size, and includes three stages:

[0232] Slow Start Phase

[0233] Triggering condition: during the initial phase or after a timeout retransmission, cwnd <ssthresh。

[0234] Window adjustment: cwnd grows exponentially with each ACK confirmation received (e.g., cwnd × = 2), quickly probing available network bandwidth.

[0235] Exit condition: When cwnd ≥ ssthresh, enter the congestion avoidance phase.

[0236] Congestion Avoidance Phase

[0237] Triggering condition: cwnd ≥ ssthresh.

[0238] Window adjustment: cwnd increases linearly with each ACK confirmation received (e.g., cwnd += 1) to avoid excessive bandwidth consumption.

[0239] Exit condition: When packet loss is detected (timeout or duplicate ACK), the fast recovery phase is entered.

[0240] Fast Recovery Phase

[0241] Triggering condition: Receiving 3 duplicate ACKs indicates that some data is lost but the network can still transmit.

[0242] Window adjustments:

[0243] Immediately reduce ssthresh to half of the current cwnd (ssthresh = cwnd / 2).

[0244] Reset cwnd to ssthresh + 1 to prevent the window from becoming too small.

[0245] Exit condition: After receiving the new data ACK, return to the congestion avoidance phase.

[0246] In this step, slow start quickly probes bandwidth, congestion avoidance phases suppress aggressive growth to reduce the risk of packet loss; fast recovery quickly adjusts when packet loss is encountered to avoid prolonged performance degradation, and the overall congestion mechanism avoids buffer overflow or network overload due to excessively large windows, thus improving overall reliability.

[0247] Through step S402, this embodiment successfully maintains a congestion window and dynamically adjusts the window through a state machine to balance transmission efficiency and network stability.

[0248] In one embodiment of the CAN bus-based data frame transmission control method of this application, the method may further include the following:

[0249] Step S501: Based on the window frame values ​​of the sending window, the receiving window, and the congestion window, determine the current sending window size according to the smallest window frame value. The current sending window size is used to determine the number of frames sent by the sending end in each group.

[0250] Step S502: When the current sending window size is 0, the sending end pauses sending and triggers a probe frame to request the receiving end window state. When the receiving end's receiving capability changes, the receiving end returns the corresponding receiving window size to the sending end so that the sending end can determine the current sending window size based on the receiving window size.

[0251] Optionally, in this embodiment, through steps S201-S402, this scheme maintains three windows. Before each data transmission, the sending end needs to dynamically calculate the current sending window size (curwndwinsize), which is the minimum value of the sending window (swnd), the receiving window (rwnd), and the congestion window (cwnd).

[0252] curwndwinsize=min(swnd, rwnd, cwnd)

[0253] This calculation ensures that the transmission rate will not exceed the following limits:

[0254] Send window (swnd): Prevents send buffer overflow.

[0255] Receive window (rwnd): Prevents packet loss at the receiving end due to insufficient buffer.

[0256] Congestion window (cwnd): Prevents network overload.

[0257] Optionally, in this embodiment, when curlwndwinsize = 0, it indicates that the receiving end has no buffer space or the network is severely congested. In this case, the sending end performs the following operations:

[0258] Pause data transmission: to avoid wasting resources due to invalid transmissions.

[0259] Send probe frame: Request the current window state from the receiver (control frame type 002).

[0260] Receiver response: If the receiver's processing capability is restored (e.g., buffer is released), the updated rwnd (control frame type 001) is returned.

[0261] Resumption of transmission: The sending end recalculates curwndwinsize based on the new rwnd and continues data transmission.

[0262] In this step, this embodiment breaks the deadlock of the sending end waiting and the receiving end not responding through a detection mechanism, thus avoiding program deadlock; it can also sense changes in the receiving end's capabilities in real time, adjust the sending strategy, and send probe frames only when necessary, reducing control overhead.

[0263] Through step S502, this embodiment ensures that data transmission can still be carried out efficiently and reliably under limited conditions by dynamically calculating the minimum window value and introducing a detection mechanism, while avoiding network congestion and receiver overload problems.

[0264] In one embodiment of the CAN bus-based data frame transmission control method of this application, the method may further include the following:

[0265] Step S601: If three duplicate acknowledgment frames are detected, the fast recovery state machine mechanism is triggered to adjust the congestion window size;

[0266] Step S602: If a retransmission timeout is detected, the slow start state machine mechanism is triggered to reset the congestion window size.

[0267] Optionally, in this embodiment, when the sending end receives three consecutive duplicate ACK frames, it indicates that a data frame may have been lost, but some data was still correctly received by the receiving end. At this time, the system enters a fast recovery state and performs the following operations:

[0268] Set the congestion window threshold (ssthresh) to half of the current congestion window, i.e., ssthresh = cwnd / 2;

[0269] Adjust the congestion window size to cwnd = ssthresh + 1 to avoid an immediate and significant reduction in the transmission rate.

[0270] Triggering fast retransmission immediately retransmits the lost data frame instead of waiting for a timeout, reducing recovery time. If a new ACK confirmation frame is subsequently received, the fast recovery state exits and enters the congestion avoidance phase, adjusting the window size linearly. If duplicate ACKs are still received, the fast recovery state continues, and the window size is gradually adjusted.

[0271] The above operations can avoid long waiting times due to single frame loss, improve transmission efficiency, and at the same time, prevent further network congestion by dynamically adjusting the window while maintaining high throughput.

[0272] Optionally, in this embodiment, when the sending end detects a retransmission timeout (RTO), it indicates that the network may be experiencing severe congestion or a link failure. At this time, the system enters a slow start state and performs the following operations:

[0273] Set the congestion window threshold (ssthresh) to half the current window size, i.e., ssthresh = cwnd / 2;

[0274] Resetting the congestion window size to the minimum value (e.g., cwnd = 2) significantly reduces the transmission rate.

[0275] Upon receiving an ACK confirmation frame, the congestion window grows exponentially (e.g., cwnd = cwnd × 2) until it reaches the threshold ssthresh. Once the threshold is exceeded, the congestion avoidance phase begins, and the window grows linearly. Unacknowledged data frames that have timed out are retransmitted to ensure reliable data transmission.

[0276] The above operations can alleviate network congestion by significantly reducing the sending rate. At the same time, the slow start mechanism ensures that the sending end can safely readjust to the network state and prevent congestion from recurring in a short period of time.

[0277] Through step S602, this embodiment successfully designed an adaptive congestion control strategy that can balance reliability and throughput under different network conditions and is suitable for resource-constrained communication environments such as CAN bus.

[0278] In one embodiment of the CAN bus-based data frame transmission control method of this application, the method may further include the following:

[0279] Step S701: The receiving end receives the data sent by the sending end, calculates the logical frame sequence number based on the group number and frame number in the received data, and if the logical frame sequence number is valid and has not been received repeatedly, the data frame is stored in the circular receiving buffer queue, and the receiving end window size is updated at the same time.

[0280] Step S702: Generate a 1-byte bitmap identifier based on the received frame number in the current group, where each bit corresponds to the reception status of a logical frame sequence number in the group. Encapsulate the bitmap identifier and the updated receiving end window size into the data field of the acknowledgment frame. Set the control frame identifier and group number in the frame header of the acknowledgment frame to indicate the associated data group of the acknowledgment frame. Send the acknowledgment frame to the sending end.

[0281] Optionally, in this embodiment, after the receiving end acquires a data frame from the CAN bus, it first extracts the group number and frame number fields carried in the frame header. A unique logical sequence number for the frame is calculated using a preset algorithm (logical frame sequence number = group number × 4 + frame number). The system maintains a registration table of received sequence numbers and checks this table to determine if the logical sequence number has been successfully received. If the sequence number is valid (within the expected range) and has not been registered, it is determined to be a valid new frame. Subsequently, the specific storage location of the frame data in the circular receive buffer queue is calculated based on the sequence number, and the payload of the data frame is written to that location to complete the storage. Simultaneously, the current value of the receive window size (rwnd) is decremented by 1, reflecting the reduction in buffer space.

[0282] A logical sequence number mechanism accurately identifies and discards duplicate frames, avoiding data redundancy and wasted processing resources. A circular queue structure ensures efficient memory utilization and avoids memory fragmentation. Real-time updates to the receive window provide the sender with accurate flow control, preventing buffer overflows at the receiver.

[0283] Optionally, in this embodiment, after successfully receiving and storing data, the receiving end checks the group to which the current data frame belongs. The system maintains a reception status table for this group and generates a 1-byte (8-bit) bitmap identifier based on the reception status (received / not received) of each frame number within the group. Each bit of the bitmap corresponds to a specific logical frame sequence number offset within the group (for example, Bit0 represents a frame with a sequence number one smaller than the current frame). A bit value of '1' indicates that the corresponding frame has been successfully received, while '0' indicates that it has not been received or has been lost. Subsequently, this bitmap identifier, along with the updated receiving end window size value, is filled into the specified position in the 8-byte data field of the acknowledgment frame (ACK). Simultaneously, in the frame header of the ACK, the frame type is set to a control frame, and the same group number as the acknowledged data frame is entered to clearly indicate the association relationship of this ACK. Finally, this ACK is sent to the sending end via the CAN bus interface.

[0284] By utilizing bitmap compression technology, a single acknowledgment frame can provide feedback on the reception status of multiple data frames within a group, significantly reducing the number of control frames required for individual acknowledgments for each reception and transmission, and substantially saving valuable CAN bus bandwidth. Feeding back the window size along with precise frame reception status allows the transmitter to perform flow control and selective retransmission simultaneously, thereby greatly improving data transmission efficiency and reliability.

[0285] Through step S702, this embodiment successfully utilizes bitmap compression technology to save CAN bus bandwidth and improve the efficiency and reliability of data transmission.

[0286] To improve data transmission efficiency and real-time performance, this application provides an embodiment of a CAN bus-based data frame transmission control device for implementing all or part of the aforementioned CAN bus-based data frame transmission control method. See [link to embodiment]. Figure 2 The data frame transmission control device based on the CAN bus specifically includes the following components:

[0287] The data preparation module 10 is used to encapsulate the upper-layer service data into a sending buffer queue after the sending end receives the upper-layer service data, and record the current offset position. The offset position is used to move the offset position for positioning after each group of data is successfully sent.

[0288] The sending window determination module 20 is used to maintain a sending window, a receiving window, and a congestion window at the sending end, determine the corresponding current sending window size based on the minimum window size of the sending window, the receiving window, and the congestion window, and asynchronously send the data in the sending buffer queue to the receiving end in groups according to the current sending window size. Here, the sending window is the maximum frame value of the sending buffer queue, the receiving window is the frame value returned by the receiving end, and the congestion window is the frame value output by the network congestion controller.

[0289] The acknowledgment frame construction module 30 is used for the receiving end to receive data sent by the sending end, to perform sequence number verification on the data and store the data in a circular receiving buffer queue, to update the receiving end window size, to construct an acknowledgment frame based on the updated receiving end window size and a preset bitmap identifier, and to send the acknowledgment frame to the sending end.

[0290] The sending result confirmation module 40 is used to obtain the data receiving status of the receiving end according to the bitmap identifier after the sending end receives the confirmation frame. If all frames in the group are confirmed to be received by the receiving end, the offset position is moved to trigger the next group of transmission. After updating the window size value of the original receiving window according to the updated receiving end window size, the current sending window size is recalculated, and the next group of data is sent according to the recalculated current sending window size.

[0291] As described above, the CAN bus-based data frame transmission control device provided in this application embodiment can maintain a transmission window, a reception window, and a congestion window at the transmitting end. It determines the current transmission window size based on the frame value with the smallest window size among the three windows and asynchronously transmits data in the transmission buffer queue to the receiving end in groups according to the current transmission window size. After receiving the data, the receiving end stores the data in a circular reception buffer queue, updates the receiving end window size, constructs an acknowledgment frame based on the updated receiving end window size and bitmap identifier, and sends the acknowledgment frame to the transmitting end. After receiving the acknowledgment frame, the transmitting end recalculates the current transmission window size and transmits the next group of data according to the recalculated current transmission window size. This improves data transmission efficiency and real-time performance.

[0292] To further illustrate this solution, this application also provides a specific application example of implementing a CAN bus-based data frame transmission control method using the aforementioned CAN bus-based data frame transmission control device, which specifically includes the following:

[0293] A. Overall Process Description:

[0294] 1. Business data is first encapsulated into a sending buffer queue in 8-byte frames. The sending buffer maintains an offset position. After each successful transmission, the offset position is moved until the offset position reaches the end of the data.

[0295] 2. Transmission is asynchronous, in groups. Each group contains a maximum of 4 frames and a minimum of 1 frame, determined by the minimum of the local transmit window, receive window, and congestion window. Let the local transmit window size be swndwinsize, the receive window size be rwndwinsize, and the congestion window size be cwndwinsize. Then the current transmit window size curwndwinsize is:

[0296] curwndwinsize=min(swndwinsize, rwndwinsize, cwndwinsize)

[0297] If congestion occurs or the receiving end's processing capacity decreases, the curwndwinsize will decrease.

[0298] When curwndwinsize < 4, the number of frames sent in each group is adjusted to curwndwinsize.

[0299] Note: The window size is maintained in frames, with each frame corresponding to a raw CAN frame.

[0300] 3. When the sending window size is 0, the sending end will send a probe frame within the timeout period to inquire about the client's receiving capability. When the receiving capability changes, the client will assemble the current receiving window into a control frame and send it to the client.

[0301] 4. Due to asynchronous transmission, out-of-order delivery and timely reception of each group are involved. In addition to the packet sequence number, each transmitted data frame also stores the total number of frames in the current group. This allows the receiving end to know promptly when reception is complete. For the sending end, the ACK acknowledgment frame also maintains an acknowledgment packet identifier, indicating which frames in the current group the client has received. This allows the sending end to know which frames have not yet been received and whether the client has completed receiving all frames in the current group.

[0302] 5. The sending window will only move and send the next set of frames after all frames in each group have been successfully sent. A sending wait time is maintained for each group and for each frame. After a data frame is sent, its sending time is recorded. Once each group of frames has been sent, it enters a waiting period (polling mechanism). If the frame's waiting time is exceeded, a timeout retransmission is triggered. When the sending end receives three duplicate acknowledgment frames, fast retransmission / fast recovery is triggered. If the sending timeout exceeds the waiting time for each group, the transmission fails. An error frame is sent to the receiving end, and the global buffer is reset.

[0303] 6. After receiving a data frame, the receiving end compares its packet sequence number and frame length with those already registered. If none are found, it registers the relevant group and packet sequence number, and simultaneously writes the data to the receiving circular buffer queue. After saving the data, it sends the corresponding ACK confirmation frame. If it determines that all frames in the current group have been received, it reassembles the data according to the frame number in order and submits it to the upper layer. Then, it updates the receive window size and sends a control frame to update the receive window size.

[0304] 7. Priority Mechanism. After the service packet is sent, the sliding window layer interface will return the current congestion status.

[0305] The upper layer will adjust based on congestion levels. If congestion is severe, it will send primary data. When congestion eases, it will adjust back to send less critical and less urgent business data.

[0306] B. Business data sending buffer queue:

[0307] The size is aligned upwards to a multiple of 8 based on the length of the largest packet of business data. For example, if the maximum packet length of business data is 62 bytes, then the buffer size is 64 bytes. The buffer is divided into 8-byte units based on the CAN raw frame.

[0308] Record an offset position, indicating the location that has been sent, in units of frames (8 bytes). This allows the offset position to be stored with fewer resources, saving device resources. The send buffer queue storage structure is as follows:

[0309]

[0310] The initial offset position is 0, and the offset position is moved after each successful transmission of one or more frames.

[0311] C. Business data receiving buffer queue, such as Figure 3 As shown:

[0312] The receiving end maintains a receive buffer queue, using a circular buffer queue pattern. The size of the buffer queue is a multiple of 8, which is the length of the largest packet of business data aligned upwards.

[0313] D. Implementation of this application in water control equipment:

[0314] 1. Receiving operation:

[0315] CAN data reception uses an interrupt-driven approach. Within the interrupt callback function, the CAN frame data is copied to a buffer queue. The main program is responsible for retrieving data from the buffer queue frame by frame and performing the appropriate processing.

[0316] 2. Sending operation:

[0317] Each piece of business data is first copied to the sending buffer queue, and then subsequent operations are completed in the form of a task.

[0318] The task maintains several states, as follows:

[0319] Initialization state;

[0320] State before sending data frames;

[0321] Status after data frame is sent;

[0322] 3. Task initialization:

[0323] Set the sending window size as (the maximum data packet size rounded up to a multiple of 8) / 8;

[0324] Set the receive window size as (the maximum data packet size rounded up to a multiple of 8) / 8;

[0325] Set the congestion window threshold to 16 frames.

[0326] Set the initial size of the congestion window to 4 (frames).

[0327] Set the group number to 0.

[0328] Set the send buffer queue offset to 0.

[0329] Adjust the task status to 1.

[0330] 4. Send task:

[0331] Get the current sending window size = min(local sending window size, receiving window size, congestion window size)

[0332] If the current transmission window size is greater than 4 frames, adjust it to 4 frames. Data is transmitted only when the current transmission window size is greater than 0. Before transmission, the data needs to be assembled into CAN frames and transmitted in multiple frames.

[0333] Each frame of a data frame includes:

[0334] Group number, frame number, device ID, data frame identifier, data length, data content, and total number of frames in the group. After transmission is complete, adjust the status to 2.

[0335] 5. Detection timeout:

[0336] If the current sending window size is 0, check if the timeout has occurred before sending a probe frame (obtain the receiving window size);

[0337] If the current sending window size is greater than 0, check whether a timeout retransmission is needed.

[0338] 6. Receive task:

[0339] Upon receiving an ACK confirmation frame, check if it matches the current group number. If not, discard the frame; if they match, compare the confirmation flag in the confirmation frame with the sent frames. If multiple frames in the confirmation flag have already been received, adjust the local sending window size to the original sending window size minus the number of frames sent. Adjust the sending buffer offset to offset = offset + number of frames sent. Set the task status to 1.

[0340] When a frame requesting the client to resize the receiving window is received, the current receiving window size is adjusted.

[0341] When a probe frame is received from the sender, a control frame for adjusting the size of the receive window will be sent to the sender.

[0342] When a data frame is received, it is checked whether it has already been received. If it has, it is discarded. If no data has been received, the data is copied to the receive buffer queue, and the local receive window size is decremented by 1. If it is determined from the data frame that all frames in the group have been received, an ACK confirmation frame is sent, and the data in the receive buffer queue for that group is reordered according to packet sequence number and submitted to the upper layer. At the same time, the local window size is adjusted to: local receive window size = local receive window size + number of data frames received in the current group. The adjusted local receive window size is then sent to the sending end.

[0343] When a received ACK confirmation frame is duplicated, the number of duplicates is accumulated. When the number of duplicates is greater than or equal to 3, fast retransmission / fast recovery is triggered.

[0344] From a hardware perspective, in order to improve data transmission efficiency and real-time performance, this application provides an embodiment of an electronic device for implementing all or part of the aforementioned CAN bus-based data frame transmission control method. The electronic device specifically includes the following components:

[0345] The system comprises a processor, memory, a communications interface, and a bus; wherein the processor, memory, and communications interface communicate with each other via the bus; the communications interface is used to implement information transmission between the CAN bus-based data frame transmission control method and core business systems, user terminals, and related databases and other related devices; the logic controller can be a desktop computer, tablet computer, or mobile terminal, etc., and this embodiment is not limited to these. In this embodiment, the logic controller can be implemented with reference to the embodiments of the CAN bus-based data frame transmission control method in the present embodiment, and the contents of these embodiments are incorporated herein, with repeated details not repeated.

[0346] It is understood that the user terminal may include smartphones, tablet computers, network set-top boxes, portable computers, desktop computers, personal digital assistants (PDAs), in-vehicle devices, smart wearable devices, etc. Among these, the smart wearable devices may include smart glasses, smartwatches, smart bracelets, etc.

[0347] In practical applications, the data frame transmission control method based on the CAN bus can be partially executed on the electronic device side as described above, or all operations can be completed in the client device. The choice can be made based on the processing power of the client device and the limitations of the user's usage scenario. This application does not impose any limitations on this. If all operations are completed in the client device, the client device may further include a processor.

[0348] The aforementioned client device may have a communication module (i.e., a communication unit) that can communicate with a remote server to achieve data transmission with the server. The server may include a server on the task scheduling center side; in other implementation scenarios, it may also include a server on an intermediate platform, such as a server on a third-party server platform that has a communication link with the task scheduling center server. The server may include a single computer device, a server cluster consisting of multiple servers, or a distributed server structure.

[0349] Figure 4 This is a schematic block diagram illustrating the system configuration of the electronic device 9600 according to an embodiment of this application. Figure 4 As shown, the electronic device 9600 may include a central processing unit 9100 and a memory 9140; the memory 9140 is coupled to the central processing unit 9100. It is worth noting that... Figure 4 This is an example; other types of structures can also be used to supplement or replace this structure to achieve telecommunications functions or other functions.

[0350] In one embodiment, the data frame transmission control method based on the CAN bus can be integrated into the central processing unit 9100. The central processing unit 9100 can be configured to perform the following control:

[0351] Step S101: After receiving the upper-layer service data, the sending end encapsulates the upper-layer service data into the sending buffer queue and records the current offset position. The offset position is used to move the offset position for positioning after each group of data is successfully sent.

[0352] Step S102: The sending end maintains a sending window, a receiving window, and a congestion window. The current sending window size is determined according to the minimum value of the sending window, the receiving window, and the congestion window. The data in the sending buffer queue is asynchronously sent to the receiving end in groups according to the current sending window size. Here, the sending window is the maximum frame value of the sending buffer queue, the receiving window is the frame value returned by the receiving end, and the congestion window is the frame value output by the network congestion controller.

[0353] Step S103: The receiving end receives the data sent by the sending end, performs sequence number verification on the data, stores the data in a circular receiving buffer queue, updates the receiving end window size, constructs an acknowledgment frame based on the updated receiving end window size and a preset bitmap identifier, and sends the acknowledgment frame to the sending end.

[0354] Step S104: After receiving the acknowledgment frame, the sending end obtains the data reception status of the receiving end according to the bitmap identifier. If all frames in the group are acknowledged by the receiving end, the offset position is moved to trigger the next group of transmission. After updating the window size value of the original receiving window according to the updated receiving end window size, the current transmission window size is recalculated, and the next group of data is transmitted according to the recalculated current transmission window size.

[0355] As described above, the electronic device provided in this application embodiment maintains a sending window, a receiving window, and a congestion window at the sending end. It determines the current sending window size based on the frame value with the smallest window size among the three windows and asynchronously sends data from the sending buffer queue to the receiving end in groups according to the current sending window size. After receiving the data, the receiving end stores the data in a circular receiving buffer queue, updates its receiving window size, constructs an acknowledgment frame based on the updated receiving window size and bitmap identifier, and sends the acknowledgment frame to the sending end. After receiving the acknowledgment frame, the sending end recalculates the current sending window size and sends the next group of data based on the recalculated current sending window size. This improves data transmission efficiency and real-time performance.

[0356] In another embodiment, the CAN bus-based data frame transmission control method can be configured separately from the central processing unit 9100. For example, the CAN bus-based data frame transmission control method can be configured as a chip connected to the central processing unit 9100, and the function of the CAN bus-based data frame transmission control method can be implemented through the control of the central processing unit.

[0357] like Figure 4 As shown, the electronic device 9600 may further include: a communication module 9110, an input unit 9120, an audio processor 9130, a display 9160, and a power supply 9170. It is worth noting that the electronic device 9600 does not necessarily need to include these components. Figure 4 All components shown; in addition, the electronic device 9600 may also include Figure 4 For components not shown, please refer to existing technologies.

[0358] like Figure 4 As shown, the central processing unit 9100, sometimes also referred to as a controller or operating control, may include a microprocessor or other processor device and / or logic device, which receives inputs and controls the operation of various components of the electronic device 9600.

[0359] The memory 9140 may be, for example, one or more of a cache, flash memory, hard drive, removable media, volatile memory, non-volatile memory, or other suitable devices. It may store the aforementioned failure-related information, and also store a program for executing that information. The central processing unit 9100 may execute the program stored in the memory 9140 to perform information storage or processing, etc.

[0360] Input unit 9120 provides input to central processing unit 9100. Input unit 9120 may be, for example, a keypad or touch input device. Power supply 9170 provides power to electronic device 9600. Display 9160 displays images and text. Display may be, for example, an LCD display, but is not limited thereto.

[0361] The memory 9140 can be a solid-state memory, such as a read-only memory (ROM), random access memory (RAM), a SIM card, etc. It can also be a memory that retains information even when power is off, can be selectively erased, and contains more data; examples of this type of memory are sometimes referred to as EPROMs. The memory 9140 can also be some other type of device. The memory 9140 includes a buffer memory 9141 (sometimes referred to as a buffer). The memory 9140 may include an application / function storage unit 9142 for storing application programs and function programs or processes for executing the operation of the electronic device 9600 via the central processing unit 9100.

[0362] The memory 9140 may also include a data storage unit 9143 for storing data, such as contacts, digital data, pictures, sounds, and / or any other data used by the electronic device. The driver storage unit 9144 of the memory 9140 may include various drivers for the electronic device for communication functions and / or for performing other functions of the electronic device (such as messaging applications, address book applications, etc.).

[0363] The communication module 9110 is a transmitter / receiver that sends and receives signals via the antenna 9111. The communication module 9110 is coupled to the central processing unit 9100 to provide input signals and receive output signals, which is the same as in a conventional mobile communication terminal.

[0364] Based on different communication technologies, multiple communication modules 9110 can be configured in the same electronic device, such as cellular network modules, Bluetooth modules, and / or wireless LAN modules. The communication module 9110 is also coupled to a speaker 9131 and a microphone 9132 via an audio processor 9130 to provide audio output via the speaker 9131 and receive audio input from the microphone 9132, thereby realizing typical telecommunications functions. The audio processor 9130 may include any suitable buffer, decoder, amplifier, etc. Furthermore, the audio processor 9130 is also coupled to a central processing unit 9100, enabling on-device recording via the microphone 9132 and on-device playback of stored sound via the speaker 9131.

[0365] Embodiments of this application also provide a computer-readable storage medium capable of implementing all steps of the CAN bus-based data frame transmission control method with a server or client as the execution subject in the above embodiments. The computer-readable storage medium stores a computer program that, when executed by a processor, implements all steps of the CAN bus-based data frame transmission control method with a server or client as the execution subject in the above embodiments. For example, when the processor executes the computer program, it implements the following steps:

[0366] Step S101: After receiving the upper-layer service data, the sending end encapsulates the upper-layer service data into the sending buffer queue and records the current offset position. The offset position is used to move the offset position for positioning after each group of data is successfully sent.

[0367] Step S102: The sending end maintains a sending window, a receiving window, and a congestion window. The current sending window size is determined according to the minimum value of the sending window, the receiving window, and the congestion window. The data in the sending buffer queue is asynchronously sent to the receiving end in groups according to the current sending window size. Here, the sending window is the maximum frame value of the sending buffer queue, the receiving window is the frame value returned by the receiving end, and the congestion window is the frame value output by the network congestion controller.

[0368] Step S103: The receiving end receives the data sent by the sending end, performs sequence number verification on the data, stores the data in a circular receiving buffer queue, updates the receiving end window size, constructs an acknowledgment frame based on the updated receiving end window size and a preset bitmap identifier, and sends the acknowledgment frame to the sending end.

[0369] Step S104: After receiving the acknowledgment frame, the sending end obtains the data reception status of the receiving end according to the bitmap identifier. If all frames in the group are acknowledged by the receiving end, the offset position is moved to trigger the next group of transmission. After updating the window size value of the original receiving window according to the updated receiving end window size, the current transmission window size is recalculated, and the next group of data is transmitted according to the recalculated current transmission window size.

[0370] As described above, the computer-readable storage medium provided in this application embodiment improves data transmission efficiency and real-time performance by maintaining a sending window, a receiving window, and a congestion window at the sending end, determining the current sending window size based on the frame value with the smallest window size among the three windows, and asynchronously sending data in the sending buffer queue to the receiving end in groups according to the current sending window size. After receiving the data, the receiving end stores the data in a circular receiving buffer queue, updates the receiving end window size, constructs an acknowledgment frame based on the updated receiving end window size and bitmap identifier, and sends the acknowledgment frame to the sending end. After receiving the acknowledgment frame, the sending end recalculates the current sending window size and sends the next group of data according to the recalculated current sending window size.

[0371] Embodiments of this application also provide a computer program product capable of implementing all steps of the CAN bus-based data frame transmission control method in the above embodiments, where the execution subject is a server or client. When executed by a processor, this computer program / instruction implements the steps of the CAN bus-based data frame transmission control method. For example, the computer program / instruction implements the following steps:

[0372] Step S101: After receiving the upper-layer service data, the sending end encapsulates the upper-layer service data into the sending buffer queue and records the current offset position. The offset position is used to move the offset position for positioning after each group of data is successfully sent.

[0373] Step S102: The sending end maintains a sending window, a receiving window, and a congestion window. The current sending window size is determined according to the minimum value of the sending window, the receiving window, and the congestion window. The data in the sending buffer queue is asynchronously sent to the receiving end in groups according to the current sending window size. Here, the sending window is the maximum frame value of the sending buffer queue, the receiving window is the frame value returned by the receiving end, and the congestion window is the frame value output by the network congestion controller.

[0374] Step S103: The receiving end receives the data sent by the sending end, performs sequence number verification on the data, stores the data in a circular receiving buffer queue, updates the receiving end window size, constructs an acknowledgment frame based on the updated receiving end window size and a preset bitmap identifier, and sends the acknowledgment frame to the sending end.

[0375] Step S104: After receiving the acknowledgment frame, the sending end obtains the data reception status of the receiving end according to the bitmap identifier. If all frames in the group are acknowledged by the receiving end, the offset position is moved to trigger the next group of transmission. After updating the window size value of the original receiving window according to the updated receiving end window size, the current transmission window size is recalculated, and the next group of data is transmitted according to the recalculated current transmission window size.

[0376] As described above, the computer program product provided in this application maintains a sending window, a receiving window, and a congestion window at the sending end. It determines the current sending window size based on the frame value with the smallest window size among the three windows and asynchronously sends data from the sending buffer queue to the receiving end in groups according to the current sending window size. After receiving the data, the receiving end stores the data in a circular receiving buffer queue, updates its receiving window size, constructs an acknowledgment frame based on the updated receiving window size and bitmap identifier, and sends the acknowledgment frame to the sending end. After receiving the acknowledgment frame, the sending end recalculates the current sending window size and sends the next group of data based on the recalculated current sending window size. This improves data transmission efficiency and real-time performance.

[0377] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0378] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (devices), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0379] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0380] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0381] Specific embodiments have been used to illustrate the principles and implementation methods of this invention. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

Claims

1. A method of controlling transmission of a data frame based on a CAN bus, characterized by, The method comprises a sending end and a receiving end, and the method comprises: After the sending end receives upper-layer service data, the sending end encapsulates the upper-layer service data into a sending cache queue and records a current offset position, wherein the offset position is used to move the offset position for positioning after each group of data is successfully sent; The sending end maintains a sending window, a receiving window and a congestion window, including: when initialized, the size of the sending window is set to the maximum frame capacity of the sending cache queue; after each sending success, the frame sequence number of the confirmed reception is updated according to the bitmap identification in the return confirmation frame of the sending end, the sending window space is released, and the size of the sending window is re-determined; when initialized, the size of the receiving window is set to the maximum frame capacity of the receiving cache queue; after each sending success, the size of the receiving window is re-determined according to the current receiving window size returned by the receiving end, wherein the current receiving window size is dynamically calculated by the receiving end according to the remaining capacity of the ring receiving cache queue; when initialized, the initial congestion window size and the congestion window threshold are set, and a congestion control state machine module is constructed, wherein the congestion control state machine module dynamically adjusts the initial congestion window size by using a state machine mechanism, and the state machine mechanism includes slow start, congestion avoidance and fast recovery; in the slow start stage, the window is exponentially expanded; in the congestion avoidance stage, the window is linearly expanded; the current sending window size corresponding to the minimum value of the sending window, the receiving window and the congestion window is determined, and the data in the sending cache queue is sent to the receiving end in groups according to the current sending window size, wherein the sending window is the maximum frame value of the sending cache queue, the receiving window is the frame value returned by the receiving end, and the congestion window is the frame value output by the network congestion control machine; The receiving end receives the data sent by the sending end, stores the data in a ring receiving cache queue after sequence number checking of the data, updates the receiving end window size, constructs a confirmation frame according to the updated receiving end window size and a preset bitmap identification, and sends the confirmation frame to the sending end; After the sending end receives the confirmation frame, the data reception state of the receiving end is obtained according to the bitmap identification, if all the frames in the group are confirmed to be received by the receiving end, the offset position is moved to trigger the next group sending, the window size value of the original receiving window is updated according to the updated receiving end window size, the current sending window size is re-calculated, and the next group data sending is performed according to the re-calculated current sending window size.

2. The CAN bus-based data frame transmission control method according to claim 1, characterized in that, The current sending window size corresponding to the minimum value of the sending window, the receiving window and the congestion window is determined, including: The window frame values of the sending window, the receiving window and the congestion window are judged, and the current sending window size corresponding to the minimum window frame value is determined, wherein the current sending window size is used to determine the frame number size of each group sent by the sending end. When the current sending window size is 0, the sending end suspends sending and triggers a probe frame to request the receiving end window state; when the receiving end receiving capacity changes, the receiving end returns the corresponding receiving window size to the sending end, so that the sending end determines the current sending window size according to the receiving window size.

3. The CAN bus-based data frame transmission control method according to claim 1, characterized in that, After the sending end receives the acknowledgement frame, the data receiving state of the receiving end is obtained according to the bitmap identifier, and the method further comprises: If three repeated acknowledgement frames are detected, a fast recovery state machine mechanism is triggered to adjust the congestion window size; If a retransmission timeout is detected, a slow start state machine mechanism is triggered to reset the congestion window size.

4. The CAN bus-based data frame transmission control method according to claim 1, characterized by, The receiving end receives the data sent by the sending end, stores the data in a ring-shaped receiving buffer queue after performing sequence number checking on the data, and updates the receiving end window size; an acknowledgement frame is constructed according to the updated receiving end window size and a preset bitmap identifier, and the acknowledgement frame is sent to the sending end, comprising: The receiving end receives the data sent by the sending end, calculates a logical frame sequence number according to the group number and the frame number in the received data, and stores the data frame in the ring-shaped receiving buffer queue if the logical frame sequence number is valid and has not been repeatedly received, while updating the receiving end window size; A 1-byte bitmap identifier is generated according to the frame number of the received frames in the current group, wherein each bit corresponds to the receiving state of a logical frame sequence number in the group; the bitmap identifier and the updated receiving end window size are encapsulated into the data field of the acknowledgement frame, and the control frame identifier and the group number are set in the frame header of the acknowledgement frame to indicate the associated data group of the acknowledgement frame; and the acknowledgement frame is sent to the sending end.

5. A CAN bus-based data frame transmission control device, characterized by comprising: The device implements the steps of the CAN bus-based data frame sending control method according to any one of claims 1 to 4, comprising: A sending data preparation module, configured to, after the sending end receives upper-layer service data, encapsulate the upper-layer service data into a sending buffer queue and record a current offset position, wherein the offset position is used to move the offset position for positioning after each group of data is successfully sent; A sending data preparation module, configured to, after the sending end receives upper-layer service data, encapsulate the upper-layer service data into a sending buffer queue and record a current offset position, wherein the offset position is used to move the offset position for positioning after each group of data is successfully sent; The sending window determining module is used for maintaining a sending window, a receiving window and a congestion window at the sending end, including: setting the size of the sending window as the maximum frame capacity of the sending buffer queue at initialization, updating the frame sequence number that has been confirmed to be received according to the bitmap identification in the return acknowledgement frame of the sending end after each successful sending, releasing the sending window space, and re-determining the size of the sending window; setting the size of the receiving window as the maximum frame capacity of the receiving buffer queue at initialization, re-determining the size of the receiving window according to the current receiving window size returned by the receiving end after each successful sending, wherein the current receiving window size is dynamically calculated by the receiving end according to the remaining capacity of the ring receiving buffer queue; setting the initial congestion window size and the congestion window threshold at initialization, and constructing a congestion control state machine module that dynamically adjusts the initial congestion window size by using a state machine mechanism, wherein the state machine mechanism includes slow start, congestion avoidance and fast recovery, the window is exponentially enlarged at the slow start stage, and the window is linearly enlarged at the congestion avoidance stage; determining the corresponding current sending window size according to the minimum value of the sending window, the receiving window and the congestion window, and sending the data in the sending buffer queue to the receiving end in groups according to the current sending window size, wherein the sending window is the maximum frame value of the sending buffer queue, the receiving window is the frame value returned by the receiving end, and the congestion window is the frame value output by the network congestion control machine; The acknowledgement frame constructing module is used for the receiving end to receive the data sent by the sending end, storing the data in the ring receiving buffer queue after sequence number checking, updating the receiving end window size, constructing an acknowledgement frame according to the updated receiving end window size and the preset bitmap identification, and sending the acknowledgement frame to the sending end; The sending result confirming module is used for the sending end to receive the acknowledgement frame, obtaining the data receiving state of the receiving end according to the bitmap identification, moving the offset position to trigger the sending of the next group if all the frames in the group are confirmed to be received by the receiving end, updating the window size value of the original receiving window according to the updated receiving end window size, re-calculating the current sending window size, and sending the next group of data according to the re-calculated current sending window size.

6. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the program to implement the steps of the CAN bus-based data frame sending control method in any one of claims 1 to 4.

7. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the CAN bus-based data frame sending control method in any one of claims 1 to 4.

Images