Data transmission method and related equipment

Abstract

The invention provides a data transmission method and related equipment. The data transmission method comprises the following steps: acquiring multiple business data of a vehicle; a logic flow type corresponding to each piece of service data is determined, each logic flow type corresponds to a sending queue, and each sending queue is provided with a corresponding transmission control strategy which comprises a priority and a data sending rule; constructing a data packet for each piece of service data and adding a logic flow type; adding the data packets into corresponding sending queues according to the logic flow types, and adding serial numbers and state flags in the queues; when the sending thread is awakened, determining a target data packet in each sending queue according to the state flag; and for each sending queue, sending the target data packet to the server according to the corresponding data sending rule. In the scheme, a plurality of logic flows with independent logic are established, and the service data are classified and mapped to different logic flows according to the service characteristics of the service data, so that a transmission control strategy is independently configured for each logic flow, and the problem of head-of-queue blocking of an application layer is radically solved.

Description

A data transmission method and related equipment Technical Field

[0001] This invention relates to the field of data transmission technology, specifically to a data transmission method and related equipment. Background Technology

[0002] In the field of automotive remote diagnostics, latency is extremely sensitive. Therefore, to achieve lower latency, UDP point-to-point communication is typically preferred for communication between B-end and C-end devices. In automotive remote diagnostic scenarios, the data transmitted between B-end and C-end devices includes control commands and bus data. Bus data further includes diagnostic data and broadcast data. Control commands: small in volume, but require extremely low end-to-end latency and absolute reliability, primarily used for tasks such as switching diagnostic modes. Diagnostic data: medium in volume, requiring reliable and ordered transmission, used for vehicle diagnostics, ECU remapping, code reading, code clearing, etc., with real-time requirements less stringent than control commands. Broadcast data: massive in volume, mostly periodic status information; occasional packet loss or out-of-order delivery has minimal impact on operations.

[0003] Existing technical solutions typically transmit all data in a single logical stream and apply a uniform reliability mechanism (i.e., to ensure the order and reliability of data, if a previous frame is not received, subsequent data cannot be processed until that frame is received). This leads to the classic application layer head-of-line blocking problem, where the loss of an insignificant broadcast data packet can block the processing of all subsequent control commands and diagnostic data, resulting in insufficient real-time data transmission.

[0004] In summary, how to avoid application-layer head-of-line blocking is a problem that urgently needs to be solved. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a data transmission method and related equipment to achieve the purpose of solving the application layer head-of-line blocking problem.

[0006] To achieve the above objectives, the embodiments of the present invention provide the following technical solutions:

[0007] The first aspect of this invention discloses a data transmission method applied to a client in a vehicle remote diagnostic system. The client is communicatively connected to both a vehicle and a server, and the server is communicatively connected to a diagnostic device. The method includes:

[0008] Real-time acquisition of multiple business data of the vehicle;

[0009] From multiple preset logical flow types, the logical flow type corresponding to each business data is determined; each logical flow type corresponds to a pre-built sending queue; each sending queue is configured with a corresponding transmission control policy; the transmission control policy includes at least: the priority and data sending rules corresponding to the sending queue;

[0010] For each of the aforementioned business data, a corresponding data packet is constructed, and the corresponding logical flow type is added to the data packet;

[0011] According to the logical flow type in each of the data packets, each data packet is added to the corresponding sending queue, and an internal sequence number and status flag are added to the data packet; the internal sequence number indicates the order of the data packet in the corresponding sending queue.

[0012] When the business data sending thread is awakened, it polls the status flags corresponding to each data packet in each sending queue in descending order of priority to determine the target data packet in each sending queue.

[0013] For each of the sending queues, the target data packets corresponding to the sending queue are sent to the server according to the corresponding data sending rules.

[0014] Optionally, determining the logical flow type corresponding to each piece of business data from a plurality of preset logical flow types includes:

[0015] Obtain the data source information corresponding to each of the aforementioned business data; the data source information includes: CAN ID or API call information;

[0016] Based on the data source information corresponding to each business data, the logical flow type corresponding to each business data is determined from multiple preset logical flow types.

[0017] Optionally, the logical flow type includes one or more of the following: control flow, diagnostic flow, and broadcast flow;

[0018] Accordingly, when the service data sending thread is awakened, it sequentially polls the status flags corresponding to each data packet in each sending queue in descending order of priority to determine the target data packet in each sending queue, including:

[0019] When the business data sending thread is awakened, it sequentially polls the status flags corresponding to each data packet in each sending queue in descending order of priority. For the sending queue corresponding to the broadcast stream, the data packets with the status flag set to "to be sent" are identified as target data packets. For the sending queue corresponding to the control flow or the diagnostic flow, the data packets to be retransmitted and the data packets with the status flag set to "to be sent" are identified as target data packets. The data packets to be retransmitted include: data packets with the status flag set to "packet loss" or data packets that have previously timed out.

[0020] Optionally, for each of the sending queues, sending each target data packet corresponding to the sending queue to the server according to the corresponding data sending rule includes:

[0021] For the sending queue corresponding to the broadcast stream, each of the target data packets is sent to the server, and each of the target data packets is deleted from the sending queue corresponding to the broadcast stream.

[0022] For the sending queue corresponding to the control flow and the sending queue corresponding to the diagnostic flow, each of the corresponding target data packets is sent to the server. For each sent target data packet, if an ACK frame sent by the server is received, the corresponding status flag is changed to the sending completion flag. If a NACK frame sent by the server is received, the target data packet that has been lost is determined based on the NACK frame, and the status flag corresponding to the target data packet that has been lost is changed to the packet loss flag.

[0023] Optionally, the method further includes:

[0024] Using a heartbeat packet sending thread that is in a real-time wake-up state, a heartbeat packet is sent to the server at preset intervals, and a heartbeat response packet is received from the server.

[0025] A second aspect of this invention discloses a data transmission method applied to a server in a vehicle remote diagnostic system; the server is communicatively connected to a diagnostic device and a client, and the client is communicatively connected to a vehicle; the method includes:

[0026] Receive each target data packet sent by the client;

[0027] Parse each target data packet to obtain the business data, logical flow type, and queue internal sequence number in each target data packet;

[0028] Based on the logical flow type and the internal sequence number of each target data packet, differentiated business processing is performed on each target data packet.

[0029] Optionally, the logical flow type includes one or more of the following: control flow, diagnostic flow, and broadcast flow;

[0030] Accordingly, based on the logical flow type and the internal sequence number of each target data packet, differentiated service processing is performed on each target data packet, including:

[0031] For each target data packet containing the logical stream type of the broadcast stream, the target data packet is sent to the broadcast processing thread for processing;

[0032] For each target data packet containing the control flow of the logical flow type, based on the internal sequence number of the queue in the target data packet, it is determined whether the target data packet arrived in order; if it arrived in order, it is sent to the control processing thread for processing, and an ACK frame corresponding to the target data packet is sent to the client; if it did not arrive in order, a NACK frame is sent to the client; the NACK frame includes the internal sequence number of the queue in the target data packet that was lost.

[0033] For each target data packet containing the logical flow type of the diagnostic flow, based on the internal sequence number of the queue in the target data packet, it is determined whether the target data packet arrived in order; if it arrived in order, the target data packet is cached. When the cumulative number of cached target data packets reaches a preset number, or when the time elapsed since the last ACK frame sent to the server exceeds a preset time, an ACK frame corresponding to each of the currently cached target data packets is sent to the server, and each of the currently cached target data packets is sent to the diagnostic processing thread for processing, and the current cache is cleared; if it did not arrive in order, a NACK frame is sent to the client; the NACK frame includes the internal sequence number of the queue in the target data packet that was lost.

[0034] Optionally, the method further includes:

[0035] When a heartbeat packet is received from the client, a heartbeat response packet is sent to the client.

[0036] A third aspect of this invention discloses a data transmission device applied to a client in a vehicle remote diagnostic system. The client is communicatively connected to both a vehicle and a server, and the server is communicatively connected to a diagnostic device. The device includes:

[0037] The acquisition unit is used to acquire multiple business data of the vehicle in real time;

[0038] The determining unit is used to determine the logical flow type corresponding to each of the service data from a plurality of preset logical flow types; each logical flow type corresponds to a pre-built sending queue; each sending queue is configured with a corresponding transmission control policy; the transmission control policy includes at least: the priority and data sending rules corresponding to the sending queue;

[0039] The construction unit is used to construct a corresponding data packet for each of the aforementioned business data, and to add the corresponding logical flow type to the data packet;

[0040] The adding unit is configured to add each data packet to the corresponding sending queue according to the logical flow type in each data packet, and add an internal sequence number and a status flag to the data packet; the internal sequence number represents the order of the data packet in the corresponding sending queue.

[0041] The polling unit is used to poll the status flags corresponding to each data packet in each of the sending queues in descending order of priority when the business data sending thread is awakened, so as to determine the target data packet in each of the sending queues.

[0042] The sending unit is used to send each target data packet corresponding to each sending queue to the server according to the corresponding data sending rule.

[0043] A fourth aspect of this invention discloses a data transmission device applied to a server in a vehicle remote diagnostic system; the server is communicatively connected to a diagnostic device and a client, and the client is communicatively connected to a vehicle; the device includes:

[0044] The receiving unit is used to receive each target data packet sent by the client;

[0045] The parsing unit is used to parse each target data packet to obtain the business data, logical flow type and queue internal sequence number in each target data packet.

[0046] The processing unit is used to perform differentiated business processing on each of the target data packets based on the logical flow type and the internal sequence number of the queue in each of the target data packets.

[0047] Based on the data transmission method and related equipment provided in the above embodiments of the present invention, multiple service data of a vehicle are acquired in real time; from multiple preset logical flow types, the logical flow type corresponding to each service data is determined; each logical flow type corresponds to a pre-built sending queue; each sending queue is configured with a corresponding transmission control strategy; the transmission control strategy includes at least: the priority and data sending rules corresponding to the sending queue; a corresponding data packet is constructed for each service data, and the corresponding logical flow type is added to the data packet; according to the logical flow type in each data packet, each data packet is added to the corresponding sending queue, and an internal sequence number and status flag are added to the data packet; the internal sequence number of the queue represents the order of the data packet in the corresponding sending queue; when the service data sending thread is awakened, the status flags corresponding to each data packet in each sending queue are polled in descending order of priority to determine the target data packet in each sending queue; for each sending queue, each target data packet corresponding to the sending queue is sent to the server according to the corresponding data sending rules. In this solution, multiple logically independent logical flows are established, and the business data is classified and mapped to different logical flows according to its business characteristics. Then, the transmission control strategy is configured independently for each logical flow. Therefore, when the broadcast flow experiences packet loss, the data of the diagnostic flow and control flow can still be processed independently and in sequence by the server, thereby eliminating the application layer head-of-line blocking problem. Attached Figure Description

[0048] To more clearly illustrate the technical solutions in the embodiments of the present invention 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 only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0049] Figure 1 is a schematic diagram of the architecture of a vehicle remote diagnostic system disclosed in an embodiment of the present invention;

[0050] Figure 2 is a flowchart of a data transmission method disclosed in an embodiment of the present invention;

[0051] Figure 3 is a flowchart of another data transmission method disclosed in an embodiment of the present invention;

[0052] Figure 4 is a structural diagram of a data transmission device disclosed in an embodiment of the present invention;

[0053] Figure 5 is a structural diagram of another data transmission device disclosed in an embodiment of the present invention;

[0054] Figure 6 is a structural diagram of an electronic device disclosed in an embodiment of the present invention. Detailed Implementation

[0055] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0056] In this application, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0057] As the background technology shows, existing technical solutions typically transmit all data in a single logical stream and apply a uniform reliability mechanism (i.e., to ensure data order and reliability, if a previous frame is not received, subsequent data cannot be processed until that frame is received). This leads to the classic application-layer head-of-line blocking problem, where the loss of even a minor broadcast packet can block the processing of all subsequent control commands and diagnostic data, resulting in insufficient real-time data transmission. Therefore, avoiding application-layer head-of-line blocking is a pressing issue that needs to be addressed.

[0058] Therefore, this invention discloses a data transmission method and related equipment. In this solution, multiple logically independent logical flows are established, and the business data is classified and mapped to different logical flows according to the business characteristics of the business data. Then, the transmission control strategy is configured independently for each logical flow. Therefore, when the broadcast flow loses packets, the data of the diagnostic flow and the control flow can still be processed independently and in sequence by the server, thereby eliminating the application layer head-of-line blocking problem.

[0059] Figure 1 shows a schematic diagram of the architecture of a vehicle remote diagnostic system disclosed in an embodiment of the present invention.

[0060] The following system architecture is often used in remote vehicle diagnostics. This architecture typically includes a cloud platform 100, a C-end connector 101, a vehicle 102, a B-end connector 103, and a diagnostic device 104. The vehicle 102 is connected to the C-end connector, the diagnostic device 104 is connected to the B-end connector 103, and the cloud platform 100 is connected to both the C-end connector 101 and the B-end connector 103 via the internet.

[0061] In this embodiment of the invention, the C-end connector 101 is the client of the remote diagnostic system. The B-end connector 103 is the server of the remote diagnostic system. The client publishes a remote diagnostic request, and the server provides the service.

[0062] An exemplary remote diagnostic process is as follows: B-end connector 103 receives a diagnostic request from diagnostic device 104 via the OBD port (a diagnostic request sent based on the client's request for remote diagnostics). This diagnostic request is then forwarded to C-end connector 101 via cloud platform 100. Upon receiving the diagnostic request from cloud platform 100, C-end connector 101 sends the data from the diagnostic request to the ECU of vehicle 102 via the OBD port, where the ECU responds. C-end connector 101 receives the diagnostic response (i.e., business data) from the ECU of vehicle 102 via the OBD port, and then sends the diagnostic response to B-end connector 103 via cloud platform 100. B-end connector 103 receives the diagnostic response from cloud platform 100 and sends it to diagnostic device 104 via the CAN bus. Diagnostic device 104 then sends the next diagnostic request, and the process is repeated continuously.

[0063] The cloud platform 100 can be understood as a communication network. It can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud platform providing basic cloud computing services such as cloud databases, cloud services, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. In this embodiment, the cloud platform 100 primarily serves as a channel for data interaction between the B-end connector 103 and the C-end connector 101. For ease of understanding, the function of the cloud platform 100 will not be elaborated further.

[0064] In this embodiment, the C-end connector 101 is mainly a data transmission device connecting the C-end and the vehicle 102. This embodiment does not limit the specific device of the C-end connector 101, and will not be described in detail thereafter. The B-end connector 103 is mainly a data transmission device connecting the B-end and the diagnostic device 104. This embodiment does not limit the specific device of the B-end connector 103, and will not be described in detail thereafter.

[0065] Vehicle 102 mainly includes a vehicle ECU or a gateway. It is easy to understand that vehicle 102 may also include other devices. This embodiment does not limit the specific devices included in vehicle 102, and will not elaborate further thereafter. For ease of description, the following description of vehicle 102 will only use the vehicle ECU as an example, and will not be elaborated further thereafter.

[0066] Diagnostic equipment 104 is a non-destructive testing and inspection machine capable of quickly and accurately assessing the technical condition of a vehicle, its assemblies, and mechanisms, and drawing reliable conclusions. It mainly includes wheel balancers, headlight testers, reaction brake test benches, chassis dynamometers, sideslip test benches, front wheel alignment machines, engine test benches, exhaust gas analyzers, exhaust smoke meters, and noise meters, etc. In this embodiment, diagnostic equipment 104 primarily processes vehicle data obtained from the ECU on vehicle 102. For ease of understanding, the functions of diagnostic equipment 104 will be further described below.

[0067] In remote diagnostics, to reduce network latency, UDP communication is often used between the C-end connector 101 and the B-end connector 103. That is, point-to-point communication with direct UDP connection is carried out between the B and C end devices to obtain the minimum network latency.

[0068] Because automotive diagnostics has very high latency requirements, the timeout period is usually not dynamically adjusted based on network conditions, but rather set to a small fixed value (usually 20 milliseconds). If this timeout is exceeded, retransmission occurs. For example, if an ACK frame from connector 103 at end B is received 90 milliseconds after sending a frame of diagnostic data, connector 101 at end C will retransmit four times during that period, at 20, 40, 60, and 80 milliseconds. This example illustrates that in the field of automotive diagnostics, to achieve the lowest possible network latency, a large number of retransmissions may occur even without packet loss. Furthermore, the service data generated during automotive diagnostics must be ordered and reliable. To ensure the validity and reliability of the service data, a frame sequence number is maintained. If a frame of service data is not received, even if subsequent frames are received, they must be buffered first, and only after receiving the original frame can they be processed frame by frame sequentially.

[0069] Based on the architecture of the vehicle remote diagnostic system disclosed in the above embodiments of the present invention, as shown in Figure 2, a flowchart of a data transmission method disclosed in the embodiments of the present invention is presented. This method is applied to the client of the above-mentioned vehicle remote diagnostic system and mainly includes the following steps:

[0070] Step S201: Acquire multiple business data of the vehicle in real time.

[0071] In step S201, the client, based on the diagnostic requirements agreed upon in advance with the diagnostic device, collects and generates multiple business data (including diagnostic data, broadcast data, and control commands, etc.) from its own bus, sensors, and controllers in real time after receiving the remote diagnostic request issued by the diagnostic device, thereby preparing the raw data to be sent for subsequent classification and transmission.

[0072] Step S202: Determine the logical flow type corresponding to each business data from multiple preset logical flow types.

[0073] Each logical stream type corresponds to a pre-built sending queue; each sending queue is configured with a corresponding transmission control policy; the transmission control policy includes at least the priority of the sending queue and the data sending rules. The priority of the sending queue reflects the processing priority of the data in the queue.

[0074] In this embodiment of the invention, multiple logically independent logical streams are established on a single UDP connection, and the business data is classified and mapped to different logical streams according to the business characteristics (real-time and reliability requirements) of the business data. Each stream is independently configured with its transmission control strategy (including reliability, ordering, acknowledgment mechanism and sending priority), thereby realizing business-aware and differentiated data transmission.

[0075] At the protocol level, at least four logical flows are defined, each corresponding to a sending queue. Each logical flow maintains its own frame sequence number (i.e., the internal sequence number stream_seq, which represents the order of data packets in the corresponding sending queue) and data sending rules. Whether other logical flows lose packets or not does not affect the processing of this logical flow. The logical flow type stream_type includes, but is not limited to:

[0076] Control flow: Used for sending control commands. Ensures reliability and order, and has high processing priority.

[0077] Diagnostic stream: Used to transmit diagnostic data. Reliability and ordering are guaranteed; processing priority is second highest.

[0078] Broadcast stream: Used to transmit periodic vehicle broadcast data. Packet loss and out-of-order delivery are allowed; lost packets are not retransmitted; and they have a low processing priority.

[0079] It is understandable that broadcast streams allow for packet loss and out-of-order delivery, and lost packets are not retransmitted. Therefore, for broadcast streams and their corresponding sending queues, it is not necessary to maintain internal sequence numbers within the queues.

[0080] In the specific implementation of step S202, the data source information corresponding to each business data is obtained; the data source information includes: CAN ID or API call information; based on the data source information corresponding to each business data, the logical flow type corresponding to each business data is determined from multiple preset logical flow types.

[0081] It should be noted that when the vehicle's application layer generates business data, it immediately obtains its metadata, i.e., data source information. Specifically, this is the unique identifier CAN ID of the business data on the vehicle bus, or the API call information of the source at the software level. Subsequently, according to the preset mapping rules, a corresponding stream_type (i.e., logical stream type) is assigned to it based on this source information, thereby completing the accurate mapping from the original business data to its corresponding transmission logical stream, preparing it for subsequent entry into different priority queues.

[0082] Step S203: Construct a corresponding data packet for each business data and add the corresponding logical flow type to the data packet.

[0083] In step S203, the business data is packaged into data packets (UDP data packets) that conform to the network transmission format. During this process, the logical flow type (such as control flow, diagnostic flow, or broadcast flow) determined in the previous step is written as a key tag into the header information of the data packet, thereby ensuring that the data packet can be correctly routed to its corresponding sending queue in subsequent processing.

[0084] Step S204: Based on the logical flow type in each data packet, add each data packet to the corresponding sending queue, and add the queue internal sequence number and status flag to the data packet.

[0085] The internal sequence number of the queue represents the order of the data packets in the corresponding sending queue.

[0086] Understandably, in order to sort the packets, each packet is added to the tail of its corresponding sending queue.

[0087] In step S204, the logical flow type label added to the header of each data packet is read and placed into the corresponding sending queue; then, each data packet is assigned an internal sequence number to record its order in the current queue, and an initial status flag (such as UNSENT to be sent) is set.

[0088] Step S205: When the business data sending thread is awakened, it polls the status flags corresponding to each data packet in each sending queue in descending order of priority to determine the target data packet in each sending queue.

[0089] In step S205, the sending thread mainly enters the working state from the dormant state through two mechanisms: event wake-up and timeout wake-up. Event wake-up means that when a new data packet arrives in the high-priority queue, the thread is immediately interrupted to wake it up, so as to ensure low latency of critical data. Timeout wake-up is a backup mechanism, in which the thread is forcibly woken up by a timer after a fixed time interval.

[0090] Taking one or more of the following logical flow types as examples: control flow, diagnostic flow, and broadcast flow, the specific implementation process of step S205 is as follows:

[0091] When the business data sending thread is awakened, it polls the status flags of each data packet in each sending queue in descending order of priority. For the sending queue corresponding to the broadcast stream, the data packets with the status flag "to be sent" are identified as target data packets. For the sending queue corresponding to the control flow or diagnostic flow, the data packets to be retransmitted and the data packets with the status flag "to be sent" are identified as target data packets. The data packets to be retransmitted include: data packets with the status flag "packet lost" or data packets that have timed out in the past.

[0092] In other words, after the sending thread is awakened, it polls the sending queue corresponding to each logical flow in the order of priority: control flow, diagnostic flow, and broadcast flow. The processing flow for the sending queue corresponding to each logical flow is as follows:

[0093] Check the sending queue for packets with status flags of LOST (packet loss flag, indicating that the corresponding data packet has been lost and triggers packet retransmission), UNSENT (pending to be sent flag), and SEND (sent flag) but which have timed out. If any are found, use them as the target data packets for this transmission.

[0094] It should be noted that because automotive diagnostics are very sensitive to latency, in existing technologies, the timeout retransmission time often does not depend on network latency, but rather a very short time is set for retransmission. Massive broadcast data inevitably results in a large amount of retransmission data, causing unnecessary waste of network bandwidth and computing resources, which places a heavy burden on resource-constrained in-vehicle embedded devices.

[0095] Therefore, in this embodiment of the invention, a no-retransmission strategy is adopted for broadcast streams. For the sending queue corresponding to the broadcast stream, the data packets with the status flag of pending transmission are determined as target data packets. Regardless of whether the target data packets are successfully sent, no retransmission is performed, which directly eliminates the retransmission traffic and ACK overhead caused by broadcast data, thereby significantly reducing network bandwidth usage and the computational load of the sending end CPU.

[0096] Step S206: For each sending queue, send each target data packet corresponding to the sending queue to the server according to the corresponding data sending rules.

[0097] In step S206, if a sending queue contains one or more target data packets, then these target data packets are sent and the status flag of these packets is changed to SEND (sent flag).

[0098] Optionally, for each target data packet, the sending time (send_time) is recorded. When the sending thread is woken up again, it is determined whether the target data packet with the status flag SEND has timed out (e.g., a threshold greater than 20 milliseconds) based on the sending time and the current time. If so, the timed-out target data packet is used as the target data packet for this sending thread wake-up (i.e., timeout retransmission). After retransmission, the sending time (send_time) is updated. If the number of retransmissions exceeds the threshold, the data packet is deleted.

[0099] In the specific implementation of step S206, for the sending queue corresponding to the broadcast stream, each target data packet is sent to the server, and each target data packet is deleted from the sending queue corresponding to the broadcast stream.

[0100] For the sending queues corresponding to the control flow and the sending queues corresponding to the diagnostic flow, each target data packet is sent to the server. For each sent target data packet, if an ACK frame is received from the server, the corresponding status flag is changed to the sending completion flag. If a NACK frame is received from the server, the target data packet that has been lost is determined based on the NACK frame, and the status flag corresponding to the target data packet that has been lost is changed to the packet loss flag.

[0101] It should be noted that broadcast streams employ a no-retransmission strategy. For target data packets in the corresponding send queue of a broadcast stream, the target data packets can be deleted directly after transmission. The NACK frame contains the internal sequence number of the lost target data packet. Based on this, the target data packet that was lost is identified, and the status flag of the lost target data packet is changed to the packet loss flag.

[0102] Optionally, after receiving the ACK frame corresponding to the target data packet, the data packets in the sending queue where the target data packet is located, whose internal sequence number is less than or equal to the received sequence number in the ACK frame (that is, the internal sequence number of the target data packet corresponding to the ACK frame) are deleted from the sending queue.

[0103] In one embodiment, the logical flow type further includes a heartbeat flow that sends heartbeat packets at preset intervals. Since the sending logic and function of the heartbeat flow are significantly different from other logical flow types, it is treated as a special logical flow type, as follows:

[0104] Using a heartbeat packet sending thread that is in a real-time wake-up state, the client sends a heartbeat packet to the server at preset intervals and receives a heartbeat response packet from the server.

[0105] It should be noted that the heartbeat stream is sent periodically by a separate high-priority thread, for example, once per second. This mechanism is handled by a separate and persistent high-priority thread, which does not depend on the sending cycle of the main business data. Instead, it is automatically woken up by a timer strictly according to the preset time interval (e.g., once per second), and then sends a lightweight heartbeat packet to the server, while simultaneously waiting for and receiving the server's reply heartbeat response packet, thereby continuously monitoring the connectivity and activity of the network link.

[0106] Based on the data transmission method disclosed in the above embodiments of the present invention, this solution configures a no-retransmission and no-acknowledgment strategy for broadcast streams, thus directly eliminating the retransmission traffic and ACK overhead caused by broadcast data, thereby significantly reducing network bandwidth usage and the computational load on the sending end CPU. Furthermore, each logical stream maintains an independent sequence number and sending queue (for broadcast streams, packet loss and out-of-order delivery are allowed, and packet loss is not retransmitted; therefore, internal sequence numbers within the queues are not required for broadcast streams and their corresponding sending queues). Thus, when packet loss occurs in a broadcast stream, the data in the diagnostic and control streams can still be processed independently and sequentially by the server, thereby eradicating the application layer head-of-queue blocking problem and greatly improving the real-time performance of critical data.

[0107] Based on the architecture of a vehicle remote diagnostic system disclosed in the above embodiments of the present invention, Figure 3 shows a flowchart of another data transmission method disclosed in the embodiments of the present invention. This method is applied to the server side of the above-mentioned vehicle remote diagnostic system and mainly includes the following steps:

[0108] Step S301: Receive each target data packet sent by the client.

[0109] In step S301, the server continuously listens to the network port and receives all target data packets sent by the client, preparing for subsequent parsing, processing and response by the server.

[0110] Step S302: Parse each target data packet to obtain the business data, logical flow type and queue internal sequence number in each target data packet.

[0111] It should be noted that the embodiment corresponding to Figure 2 has already illustrated the encapsulation process of the target data packet. Here, the conventional parsing method of UDP data packets can be used to obtain the business data, logical flow type and queue internal sequence number in each target data packet.

[0112] Step S303: Based on the logical flow type and internal sequence number of each target data packet, perform differentiated business processing on each target data packet.

[0113] In the specific implementation of step S303, examples of one or more of the following logical flow types are included: control flow, diagnostic flow, and broadcast flow:

[0114] Case 1: For each target data packet containing a logical stream of type broadcast stream, send the target data packet to the broadcast processing thread for processing.

[0115] It's important to note that the server directly transfers each target data packet from the parsed broadcast stream to a dedicated, independent broadcast processing thread for asynchronous processing. This design is because broadcast data (such as periodic vehicle status reports) is typically characterized by massive volume, non-critical nature, and the ability to tolerate delays or loss. Separating it from high-priority control and diagnostic flow processing prevents this massive data from blocking or consuming processing resources for critical data. Furthermore, since broadcast data employs a no-retransmission, no-acknowledgment strategy, there's no need to send ASK or NAK frames to the client after receiving each target data packet from the broadcast stream.

[0116] Case 2: For each target data packet containing a logical flow type of control flow, determine whether the target data packet arrived in order based on the internal sequence number of the queue in the target data packet; if it arrived in order, send it to the control processing thread for processing and send the corresponding ACK frame to the client; if it did not arrive in order, send a NACK frame to the client; the NACK frame includes the internal sequence number of the queue in the target data packet where packet loss occurred.

[0117] In the actual implementation, it checks whether stream_seq is equal to the expected sequence number of the control flow.

[0118] If equal to (guaranteed arrival in order):

[0119] The packet is submitted to the high-priority control processing thread. At the same time, the receive buffer is checked to see if there are any subsequent packets that can be processed sequentially. If so, these are also submitted to the high-priority business processing thread, the expected sequence number of the control flow is updated, the already submitted consecutive packets are deleted, an ACK frame is generated, and it is sent.

[0120] If greater than (indicating out-of-order arrival):

[0121] Insert the target data packet into the receive buffer (sorted by the internal sequence number of the queue) and generate a NACK frame containing the internal sequence number of the data packet that was lost (there can be multiple sequences).

[0122] If the number is less than (duplicate packets): discard directly.

[0123] It should be noted that the server maintains an expected sequence number for the control flow. When a target data packet is received, it compares the internal sequence number of the queue with the expected sequence number. If the sequence numbers are equal, it indicates that the packet has arrived in order and will be immediately submitted to the business thread for processing. The server will then process the subsequent buffered packets in the receive buffer in sequence, update the expected sequence number, delete the processed packets, and send an ACK frame to the client. If the sequence number is greater than the expected sequence number, it indicates that out-of-order delivery or packet loss has occurred. The server will temporarily store the current packet in the receive buffer and immediately send a NACK frame containing the missing internal sequence number of the queue to trigger the client to retransmit quickly. If the sequence number is less than the expected sequence number, it is considered a duplicate packet and is discarded to avoid duplicate processing.

[0124] Scenario 3: For each target data packet containing a logical flow type of diagnostic flow, determine whether the target data packet arrived in order based on the internal sequence number of the queue in the target data packet. If it arrived in order, the target data packet is buffered. When the cumulative number of buffered target data packets reaches a preset number, or when the time elapsed since the last ACK frame sent to the server exceeds a preset time, send the ACK frames corresponding to each currently buffered target data packet to the server, and send each currently buffered target data packet to the diagnostic processing thread for processing, and clear the current buffer. If it did not arrive in order, send a NACK frame to the client. The NACK frame includes the internal sequence number of the queue in the target data packet where packet loss occurred.

[0125] In the specific implementation, the processing logic is similar to that in case 2, the difference being that the priority of the diagnostic processing thread is lower than that of the control processing thread (it is the second highest priority), and the ACK strategy is different, as follows:

[0126] Instead of immediately sending an ACK frame, if a preset number of target data packets (e.g., 10) are received, or if a preset time (e.g., 10ms) has elapsed since the last ACK frame was sent, and either of the above conditions is met, then an ACK frame corresponding to each of the currently cached target data packets (i.e., the currently accumulated target data packets) is generated and sent.

[0127] It should be noted that the server's handling of the diagnostic flow is similar to that of the control flow in terms of logic such as ordering judgment (based on sequence number comparison) and sending NACK requests for retransmission when out of order. However, the core difference lies in the adoption of a batch acknowledgment and processing strategy to improve efficiency: when data packets arrive in order, the server will first buffer them until either the cumulative number reaches a preset value (e.g., 10) or a preset time (e.g., 10ms) has elapsed since the last acknowledgment is sent. Only then will the current batch of data packets be submitted to the next highest priority diagnostic processing thread for processing, and a unified ACK frame be sent to acknowledge the entire batch of data before clearing the buffer.

[0128] In one embodiment, the logical flow type further includes a heartbeat flow that sends heartbeat packets at preset intervals. As a special logical flow type, its receiving and processing process is as follows:

[0129] Scenario 4: When a heartbeat packet is received from the client, a heartbeat response packet is sent to the client.

[0130] It should be noted that this mechanism is the keep-alive step for the server to maintain the communication link. When the server receives a lightweight heartbeat packet periodically sent by the client, it will immediately reply with a corresponding heartbeat response packet to clearly indicate to the client that it is online and working normally, thereby jointly maintaining the reliability of this communication channel and preventing the connection from being mistakenly judged as broken due to network silence.

[0131] Based on the data transmission method disclosed in the above embodiments of the present invention, this solution configures a no-retransmission, no-acknowledgment strategy for broadcast streams, thus directly eliminating retransmission traffic and ACK overhead caused by broadcast data, thereby significantly reducing network bandwidth usage and the computational load on the sending end's CPU. Furthermore, by maintaining an independent sequence number and sending queue for each logical stream, when packet loss occurs in the broadcast stream, the data in the diagnostic and control streams can still be processed independently and sequentially by the server, thereby eradicating the application layer head-of-line blocking problem and greatly improving the real-time performance of critical data.

[0132] Based on the data transmission method disclosed in the above embodiments of the present invention, as shown in FIG4, which is a structural diagram of a data transmission device disclosed in the embodiments of the present invention, the device is applied to the client of the above-mentioned vehicle remote diagnostic system and includes: an acquisition unit 401, a determination unit 402, a construction unit 403, an addition unit 404, a polling unit 405, and a sending unit 406.

[0133] Acquisition unit 401 is used to acquire multiple business data of the vehicle in real time;

[0134] The determining unit 402 is used to determine the logical flow type corresponding to each service data from multiple preset logical flow types; each logical flow type corresponds to a pre-built sending queue; each sending queue is configured with a corresponding transmission control policy; the transmission control policy includes at least: the priority of the sending queue and the data sending rules;

[0135] The construction unit 403 is used to construct a corresponding data packet for each business data and add the corresponding logical flow type to the data packet;

[0136] Adding unit 404 is used to add each data packet to the corresponding sending queue according to the logical flow type in each data packet, and add an internal sequence number and status flag to the data packet; the internal sequence number of the queue represents the order of the data packet in the corresponding sending queue;

[0137] The polling unit 405 is used to poll the status flags of each data packet in each sending queue in descending order of priority when the business data sending thread is awakened, so as to determine the target data packet in each sending queue.

[0138] The sending unit 406 is used to send each target data packet corresponding to each sending queue to the server according to the corresponding data sending rules.

[0139] In one embodiment, the determining unit 402 is specifically used for:

[0140] Obtain the data source information corresponding to each business data; the data source information includes: CAN ID or API call information;

[0141] Based on the data source information corresponding to each business data, the logical flow type corresponding to each business data is determined from multiple preset logical flow types.

[0142] In one embodiment, the logical flow type includes one or more of the following: control flow, diagnostic flow, and broadcast flow;

[0143] Correspondingly, polling unit 405 is specifically used for:

[0144] When the business data sending thread is awakened, it polls the status flags of each data packet in each sending queue in descending order of priority. For the sending queue corresponding to the broadcast stream, the data packets with the status flag "to be sent" are identified as target data packets. For the sending queue corresponding to the control flow or diagnostic flow, the data packets to be retransmitted and the data packets with the status flag "to be sent" are identified as target data packets. The data packets to be retransmitted include: data packets with the status flag "packet lost" or data packets that have timed out in the past.

[0145] Accordingly, the transmitting unit 406 is specifically used for:

[0146] For the sending queue corresponding to the broadcast stream, send each target data packet to the server and delete each target data packet from the sending queue corresponding to the broadcast stream.

[0147] For the sending queues corresponding to the control flow and the sending queues corresponding to the diagnostic flow, each target data packet is sent to the server. For each sent target data packet, if an ACK frame is received from the server, the corresponding status flag is changed to the sending completion flag. If a NACK frame is received from the server, the target data packet that has been lost is determined based on the NACK frame, and the status flag corresponding to the target data packet that has been lost is changed to the packet loss flag.

[0148] In one embodiment, the apparatus further includes:

[0149] The heartbeat packet sending unit is used to send heartbeat packets to the server at preset intervals using a heartbeat packet sending thread that is in a real-time wake-up state, and to receive heartbeat response packets sent by the server.

[0150] Based on the data transmission apparatus disclosed in the above embodiments of the present invention, this solution configures a no-retransmission, no-acknowledgment strategy for broadcast streams, thus directly eliminating retransmission traffic and ACK overhead caused by broadcast data, thereby significantly reducing network bandwidth usage and the computational load on the sending end CPU. Furthermore, by maintaining an independent sequence number and transmission queue for each logical stream, when packet loss occurs in the broadcast stream, the data in the diagnostic and control streams can still be processed independently and sequentially by the server, thereby eradicating the application layer head-of-line blocking problem and greatly improving the real-time performance of critical data.

[0151] Based on the data transmission method disclosed in the above embodiments of the present invention, as shown in FIG5, another data transmission device disclosed in the embodiments of the present invention is structurally illustrated. This device is applied to the server side of the above-mentioned vehicle remote diagnostic system and includes: a receiving unit 501, a parsing unit 502, and a processing unit 503.

[0152] The receiving unit 501 is used to receive each target data packet sent by the client;

[0153] The parsing unit 502 is used to parse each target data packet to obtain the business data, logical flow type and queue internal sequence number in each target data packet.

[0154] Processing unit 503 is used to perform differentiated business processing on each target data packet based on the logical flow type and internal sequence number of each target data packet.

[0155] In one embodiment, the logical flow type includes one or more of the following: control flow, diagnostic flow, and broadcast flow;

[0156] Accordingly, the processing unit 503 is specifically used for:

[0157] For each target data packet containing a logical stream of type broadcast stream, the target data packet is sent to the broadcast processing thread for processing;

[0158] For each target data packet containing a logical flow type of control flow, determine whether the target data packet arrived in order based on the internal sequence number of the queue in the target data packet; if it arrived in order, send it to the control processing thread for processing and send the corresponding ACK frame to the client; if it did not arrive in order, send a NACK frame to the client; the NACK frame includes the internal sequence number of the queue in the target data packet where packet loss occurred.

[0159] For each target data packet containing a logical flow type of diagnostic flow, determine whether the target data packet arrived in order based on the internal sequence number of the queue in the target data packet. If it arrived in order, the target data packet is buffered. When the cumulative number of buffered target data packets reaches a preset number, or when the time elapsed since the last ACK frame sent to the server exceeds a preset time, send the ACK frames corresponding to each currently buffered target data packet to the server, send each currently buffered target data packet to the diagnostic processing thread for processing, and clear the current buffer. If it did not arrive in order, send a NACK frame to the client. The NACK frame includes the internal sequence number of the queue in the target data packet that was lost.

[0160] In one embodiment, the device further includes:

[0161] The heartbeat response unit is used to send a heartbeat response packet to the client when a heartbeat packet is received from the client.

[0162] Based on the data transmission apparatus disclosed in the above embodiments of the present invention, this solution configures a no-retransmission, no-acknowledgment strategy for broadcast streams, thus directly eliminating retransmission traffic and ACK overhead caused by broadcast data, thereby significantly reducing network bandwidth usage and the computational load on the sending end CPU. Furthermore, by maintaining an independent sequence number and transmission queue for each logical stream, when packet loss occurs in the broadcast stream, the data in the diagnostic and control streams can still be processed independently and sequentially by the server, thereby eradicating the application layer head-of-line blocking problem and greatly improving the real-time performance of critical data.

[0163] This invention also provides an electronic device, as shown in FIG6, which includes a memory 601 and a processor 602.

[0164] Among them, memory 601 is used to store computer programs;

[0165] The processor 602 is used to execute computer programs, specifically to implement a data transmission method provided in any embodiment of this application.

[0166] This application also provides a computer storage medium for storing a computer program, which, when executed, is specifically used to implement a data transmission method provided in any embodiment of this application.

[0167] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for system or system embodiments, since they are basically similar to method embodiments, the description is relatively simple, and relevant parts can be referred to the descriptions in the method embodiments. The systems and system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0168] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0169] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A data transmission method, characterized in that, A client application in a vehicle remote diagnostic system, the client communicating with both the vehicle and a server, the server communicating with a diagnostic device, the method comprising: acquiring multiple business data from the vehicle in real time; determining the logical flow type corresponding to each business data from multiple preset logical flow types; each logical flow type corresponding to a pre-built sending queue; setting a corresponding transmission control strategy for each sending queue; the transmission control strategy including at least: the priority and data sending rules corresponding to the sending queue; constructing a corresponding data packet for each business data and adding the corresponding logical flow type to the data packet; adding each data packet to the corresponding sending queue according to the logical flow type in each data packet, and adding an internal sequence number and a status flag to the data packet; the internal sequence number representing the order of the data packet in the corresponding sending queue; when the business data sending thread is awakened, polling the status flags corresponding to each data packet in each sending queue in descending order of priority to determine the target data packet in each sending queue; and sending each target data packet corresponding to each sending queue to the server according to the corresponding data sending rules.

2. The method according to claim 1, characterized in that, The step of determining the logical flow type corresponding to each business data from multiple preset logical flow types includes: obtaining data source information corresponding to each business data; the data source information includes: CAN ID or API call information; and determining the logical flow type corresponding to each business data from multiple preset logical flow types based on the data source information corresponding to each business data.

3. The method according to claim 1, characterized in that, The logical flow type includes one or more of control flow, diagnostic flow, and broadcast flow. Correspondingly, when the service data sending thread is awakened, the status flags corresponding to each data packet in each sending queue are polled sequentially according to the priority from high to low to determine the target data packet in each sending queue. This includes: when the service data sending thread is awakened, the status flags corresponding to each data packet in each sending queue are polled sequentially according to the priority from high to low; for the sending queue corresponding to the broadcast flow, the data packets with the status flag set to "to be sent" are determined as target data packets; for the sending queue corresponding to the control flow or the diagnostic flow, the data packets to be retransmitted and the data packets with the status flag set to "to be sent" are determined as target data packets. The data packets to be retransmitted include: data packets with the status flag set to "packet loss" or data packets that have previously timed out.

4. The method according to claim 3, characterized in that, The step of sending each target data packet corresponding to each sending queue to the server according to the corresponding data sending rules includes: for the sending queue corresponding to the broadcast stream, sending each target data packet to the server and deleting each target data packet from the sending queue corresponding to the broadcast stream; for the sending queue corresponding to the control flow and the sending queue corresponding to the diagnostic flow, sending each target data packet to the server, and for each sent target data packet, if an ACK frame sent by the server is received, changing the corresponding status flag to a sending completion flag; if a NACK frame sent by the server is received, determining the target data packet that has been lost based on the NACK frame, and changing the status flag corresponding to the target data packet that has been lost to a packet loss flag.

5. The method according to any one of claims 1 to 4, characterized in that, The method further includes: using a heartbeat packet sending thread that is in a real-time wake-up state to send heartbeat packets to the server at preset intervals, and receiving heartbeat response packets sent by the server.

6. A data transmission method, characterized in that, A server-side application in a vehicle remote diagnostic system; the server-side is communicatively connected to a diagnostic device and a client, and the client-side is communicatively connected to a vehicle; the method includes: receiving each target data packet sent by the client; parsing each target data packet to obtain the business data, logical flow type, and queue internal sequence number in each target data packet; and performing differentiated business processing on each target data packet based on the logical flow type and queue internal sequence number in each target data packet.

7. The method according to claim 6, characterized in that, The logical flow type includes one or more of control flow, diagnostic flow, and broadcast flow. Correspondingly, based on the logical flow type and the internal sequence number of each target data packet, differentiated service processing is performed on each target data packet, including: for each target data packet containing the broadcast flow logical flow type, sending the target data packet to the broadcast processing thread for processing; for each target data packet containing the control flow logical flow type, determining whether the target data packet arrived in order based on the internal sequence number of the target data packet; if it arrived in order, sending it to the control processing thread for processing and sending an ACK frame corresponding to the target data packet to the client; if it did not arrive in order, sending a NACK frame to the client; the NACK frame packet... The process includes: the internal sequence number of the target data packet in which packet loss occurred; for each target data packet containing the logical flow type of the diagnostic flow, determining whether the target data packet arrived in order based on the internal sequence number of the target data packet in the target data packet; if it arrived in order, the target data packet is cached; when the cumulative number of cached target data packets reaches a preset number, or when the time elapsed since the last ACK frame sent to the server exceeds a preset time, an ACK frame corresponding to each of the currently cached target data packets is sent to the server, and each of the currently cached target data packets is sent to the diagnostic processing thread for processing, and the current cache is cleared; if it did not arrive in order, a NACK frame is sent to the client; the NACK frame includes the internal sequence number of the target data packet in which packet loss occurred.

8. The method according to claim 6 or 7, characterized in that, The method further includes: when a heartbeat packet is received from the client, sending a heartbeat response packet to the client.

9. A data transmission device, characterized in that, A client application for a vehicle remote diagnostic system, the client communicating with both the vehicle and a server, the server communicating with a diagnostic device, the device comprising: an acquisition unit for acquiring multiple business data from the vehicle in real time; a determination unit for determining the logical flow type corresponding to each business data from multiple preset logical flow types; each logical flow type corresponding to a pre-built transmission queue; each transmission queue having a corresponding transmission control strategy; the transmission control strategy including at least: the priority of the transmission queue and data transmission rules; and a construction unit for constructing a corresponding data packet for each business data and adding the corresponding logical flow type to the data packet. The system comprises: an adding unit, configured to add each data packet to the corresponding sending queue according to the logical flow type in each data packet, and add an internal sequence number and a status flag to the data packet; the internal sequence number represents the order of the data packet in the corresponding sending queue; a polling unit, configured to poll the status flags corresponding to each data packet in each sending queue in descending order of priority when the service data sending thread is awakened, to determine the target data packet in each sending queue; and a sending unit, configured to send each target data packet corresponding to each sending queue to the server according to the corresponding data sending rules.

10. A data transmission device, characterized in that, A server-side application in a vehicle remote diagnostic system; the server-side is communicatively connected to a diagnostic device and a client, and the client is communicatively connected to a vehicle. The device includes: a receiving unit for receiving each target data packet sent by the client; a parsing unit for parsing each target data packet to obtain the business data, logical flow type, and queue internal sequence number in each target data packet; and a processing unit for performing differentiated business processing on each target data packet based on the logical flow type and queue internal sequence number in each target data packet.

Images