A vehicle diagnostic communication method and related apparatus

Abstract

The application discloses a vehicle diagnosis communication method and related device, which is applied to a terminal, the terminal is in communication connection with a vehicle diagnosis device, and comprises the following steps: writing diagnosis data to be processed returned by the vehicle diagnosis device into a first processing queue; predicting a second queuing delay of the diagnosis data to be processed based on a first queuing delay of historical diagnosis data in the first processing queue; if the second queuing delay meets preset delay conditions, moving the diagnosis data to be processed from the first processing queue to a second processing queue with higher processing priority; and if the diagnosis data to be processed meets preset dequeue conditions corresponding to the second processing queue, reading and processing the diagnosis data to be processed from the second processing queue. The second queuing delay of the diagnosis data to be processed is predicted based on the first queuing delay of historical diagnosis data, and the diagnosis data to be processed is moved to a high-priority processing queue when the second queuing delay meets preset delay conditions, so that the diagnosis data to be processed can be read and processed in time.

Description

Technical Field

[0001] This application relates to the field of vehicle electronic control technology, and in particular to a vehicle diagnostic communication method and related device. Background Technology

[0002] With the development of vehicle electronic control technology, diagnostic applications can complete vehicle diagnostics through data interaction between terminals, vehicle diagnostic equipment, and electronic control units (ECUs). Specifically, a diagnostic application can be run on a terminal, and a communication connection can be established between the terminal and the vehicle diagnostic equipment. The vehicle diagnostic equipment can then be connected to the ECU. After connection, the vehicle diagnostic equipment can interact with the ECU and return diagnostic data to the terminal. The terminal processes the diagnostic data returned by the vehicle diagnostic equipment to complete diagnostic tasks such as fault reading, data reading, ECU remapping, or ADAS calibration.

[0003] In existing terminal systems, diagnostic data returned by vehicle diagnostic equipment typically needs to be written into the terminal's processing queue after arriving at the terminal. The terminal then reads and processes the data once the dequeue conditions are met. However, the reading and processing of diagnostic data in the processing queue is affected by the terminal's task scheduling. Existing task scheduling schemes usually employ a completely fair scheduler, which primarily focuses on the fair execution of tasks and overall throughput within the terminal system. Under this scheme, when multiple frames of diagnostic data enter the processing queue, they need to participate in the terminal system's task scheduling along with other application tasks and background tasks. This can easily lead to prolonged queuing time for diagnostic data at the terminal, preventing timely reading and processing. Consequently, the processing interval between adjacent diagnostic data may exceed the time limit requirements of the corresponding diagnostic service. Summary of the Invention

[0004] In view of the above problems, this application provides a vehicle diagnostic communication method and related apparatus to solve the problem that the queuing time of diagnostic data at the terminal is easily prolonged, causing the processing interval of adjacent diagnostic data to exceed the time limit requirements of the corresponding diagnostic service. The specific solution is as follows:

[0005] The first aspect of this application provides a vehicle diagnostic communication method applied to a terminal, wherein the terminal is communicatively connected to a vehicle diagnostic device, comprising:

[0006] Receive the diagnostic data to be processed returned by the vehicle diagnostic equipment, and write the diagnostic data to be processed into the first processing queue;

[0007] Obtain the first queuing delay corresponding to the historical diagnostic data in the first processing queue, and predict the second queuing delay corresponding to the diagnostic data to be processed based on the first queuing delay;

[0008] If the second queuing delay meets the preset delay condition, the diagnostic data to be processed is moved from the first processing queue to the second processing queue, and the processing priority of the second processing queue is higher than that of the first processing queue.

[0009] If the diagnostic data to be processed meets the preset dequeue condition corresponding to the second processing queue, then the diagnostic data to be processed is read from the second processing queue and processed.

[0010] In one possible implementation, the step of obtaining the first queuing delay corresponding to the historical diagnostic data in the first processing queue, and predicting the second queuing delay corresponding to the diagnostic data to be processed based on the first queuing delay, includes:

[0011] Collect the first queuing delay corresponding to each of the multiple historical diagnostic data in the first processing queue;

[0012] A weighted moving average is applied to multiple first queuing delays to obtain the second queuing delay corresponding to the diagnostic data to be processed.

[0013] In one possible implementation, moving the diagnostic data to be processed from the first processing queue to the second processing queue when the second queuing delay meets a preset delay condition includes:

[0014] Obtain the diagnostic scenario type corresponding to the diagnostic data to be processed;

[0015] If the diagnostic scenario type belongs to a preset scenario type and the second queuing delay meets the preset delay condition, the diagnostic data to be processed is moved from the first processing queue to the second processing queue.

[0016] In one possible implementation, the step of moving the diagnostic data to be processed from the first processing queue to the second processing queue when the diagnostic scenario type belongs to a preset scenario type and the second queuing delay meets the preset delay condition includes:

[0017] If the diagnostic scenario type belongs to the preset scenario type and the second queuing delay meets the preset delay condition, determine the delay difference between the second queuing delay and the delay threshold corresponding to the preset delay condition;

[0018] Based on the time delay difference, determine the queue position of the diagnostic data to be processed in the second processing queue;

[0019] According to the queue position, the diagnostic data to be processed is moved from the first processing queue to the second processing queue;

[0020] The larger the time delay difference, the earlier the diagnostic data to be processed is in the second processing queue.

[0021] In one possible implementation, the terminal is communicatively connected to an external network device, which is distinct from the vehicle diagnostic device, and the method further includes:

[0022] If the second queuing delay meets the preset delay condition, the communication resource allocation parameters between the data transmission corresponding to the vehicle diagnostic device and the data transmission corresponding to the external network device are adjusted.

[0023] In one possible implementation, the communication resource allocation parameters include a bandwidth allocation ratio. The step of adjusting the communication resource allocation parameters between the data transmission corresponding to the vehicle diagnostic device and the data transmission corresponding to the external network device, when the second queuing delay meets the preset delay condition, includes:

[0024] When the second queuing delay meets the preset delay condition, the bandwidth allocation ratio for data transmission to the vehicle diagnostic device is increased, and the bandwidth allocation ratio for data transmission to the external network device is correspondingly decreased.

[0025] In one possible implementation, the terminal communicates with the vehicle diagnostic device via a first communication channel, and receiving the diagnostic data to be processed returned by the vehicle diagnostic device includes:

[0026] Obtain the link quality information corresponding to the first communication channel;

[0027] If the link quality information meets the channel switching conditions, a second communication channel for communicating with the vehicle diagnostic equipment is established.

[0028] The system receives candidate diagnostic data returned by the vehicle diagnostic device through the first communication channel and the second communication channel, and performs deduplication processing on the received candidate diagnostic data to obtain the diagnostic data to be processed.

[0029] A second aspect of this application provides a vehicle diagnostic communication device applied to a terminal, the terminal being communicatively connected to a vehicle diagnostic device, comprising:

[0030] The writing module is used to receive the diagnostic data to be processed returned by the vehicle diagnostic equipment and write the diagnostic data to be processed into the first processing queue.

[0031] The prediction module is used to obtain the first queuing delay corresponding to the historical diagnostic data in the first processing queue, and predict the second queuing delay corresponding to the diagnostic data to be processed based on the first queuing delay.

[0032] The move-in module is used to move the diagnostic data to be processed from the first processing queue to the second processing queue when the second queuing delay meets the preset delay condition. The processing priority of the second processing queue is higher than that of the first processing queue.

[0033] The processing module is used to read the diagnostic data to be processed from the second processing queue and process the diagnostic data to be processed if the diagnostic data to be processed meets the preset dequeue conditions corresponding to the second processing queue.

[0034] A third aspect of this application provides a computer program product including computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the vehicle diagnostic communication method of the first aspect or any implementation thereof.

[0035] A fourth aspect of this application provides an electronic device, comprising at least one processor and a memory connected to the processor, wherein:

[0036] The memory is used to store computer programs;

[0037] The processor is used to execute the computer program so that the electronic device can implement the vehicle diagnostic communication method of the first aspect or any implementation thereof.

[0038] The fifth aspect of this application provides a computer storage medium carrying one or more computer programs that, when executed by an electronic device, enable the electronic device to perform the vehicle diagnostic communication method described in the first aspect or any implementation thereof.

[0039] Using the above technical solution, the vehicle diagnostic communication method provided in this application is applied to a terminal communicating with a vehicle diagnostic device. After receiving the diagnostic data to be processed returned by the vehicle diagnostic device, the terminal writes the diagnostic data to be processed into a first processing queue. Based on the first queuing delay of historical diagnostic data in the first processing queue, the terminal predicts the second queuing delay corresponding to the diagnostic data to be processed. Historical diagnostic data can refer to diagnostic data that was written into the first processing queue and has been read before the diagnostic data to be processed. When the predicted second queuing delay meets a preset delay condition, the terminal moves the diagnostic data to be processed from the first processing queue to a second processing queue with a higher processing priority. When the diagnostic data to be processed meets the preset dequeue condition corresponding to the second processing queue, the terminal reads the diagnostic data to be processed from the second processing queue and processes it, thereby solving the problem that the long queuing time of diagnostic data at the terminal causes the processing interval of adjacent diagnostic data to exceed the time limit requirement of the corresponding diagnostic service. Attached Figure Description

[0040] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0041] Figure 1 This application provides a schematic diagram of the architecture of a vehicle diagnostic communication system.

[0042] Figure 2 A flowchart illustrating a vehicle diagnostic communication method provided in this application;

[0043] Figure 3 This is a schematic diagram of the structure of a vehicle diagnostic communication device provided in an embodiment of this application;

[0044] Figure 4 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0045] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0046] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0047] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0048] See Figure 1 , Figure 1 A schematic diagram of a system architecture is shown. The system may include a terminal 100, a vehicle diagnostic device 200, and an external network device 300. The terminal 100 can communicate with the vehicle diagnostic device 200, which can perform diagnostic interactions with the electronic control unit (ECU) in the vehicle and return diagnostic data to the terminal 100. The terminal 100 can also communicate with the external network device 300, which is distinct from the vehicle diagnostic device 200.

[0049] The terminal 100 may have a vehicle diagnostic application installed, which provides a vehicle diagnostic communication interface. The terminal 100 can receive configuration parameters such as vehicle diagnostic device connection information and diagnostic scenario type input by the user on the vehicle diagnostic communication interface, and communicate with the vehicle diagnostic device 200 based on these configuration parameters. The vehicle diagnostic device 200 can return diagnostic data to the terminal 100, and the terminal 100 can read and process the diagnostic data returned by the vehicle diagnostic device 200.

[0050] It should be understood that in some optional implementations, terminal 100 can communicate with vehicle diagnostic device 200 and external network device 300 respectively. Terminal 100 can send diagnostic requests to vehicle diagnostic device 200, and vehicle diagnostic device 200 can return diagnostic data to terminal 100 based on the diagnostic requests. Terminal 100 can also transmit data with external network device 300. External network device 300 may include servers, cloud platforms, network storage devices, etc.

[0051] The following description Figure 1 The product form of the mid-terminal 100.

[0052] The terminal 100 in this application embodiment can be a tablet computer, in-vehicle device, mobile phone, laptop computer, wearable device, personal digital assistant, etc., and this application embodiment does not limit it.

[0053] Terminal 100 may include components such as a communication unit, a memory, an input unit, a display unit, a processor, an external interface, and a power supply. Those skilled in the art will understand that the above-described components are merely examples and do not constitute a limitation on terminal 100. Terminal 100 may include more or fewer components, or combine certain components, or employ different components.

[0054] The input unit can be used to receive input numeric or character information, and to generate key signal inputs related to user settings and function control of the terminal 100. Specifically, the input unit may include a touch screen and / or other input devices. Other input devices may include a physical keyboard, function keys, a mouse, a joystick, etc.

[0055] The display unit can be used to display information input by the user or information provided to the user, menus of the terminal 100, interactive interfaces, etc. In this embodiment, the display unit can be used to display the vehicle diagnostic communication interface, diagnostic data processing status, diagnostic data processing results, etc.

[0056] The memory can be used to store software code, diagnostic data, historical diagnostic data, first queuing delay, second queuing delay, and other data related to the vehicle diagnostic communication method. The processor can execute the steps of the vehicle diagnostic communication method and can also schedule the input unit, display unit, and communication unit to achieve corresponding functions.

[0057] The communication unit can be used for data transmission and reception between the terminal 100 and the vehicle diagnostic device 200, and also for data transmission and reception between the terminal 100 and the external network device 300. In this embodiment, the communication unit can be used to establish at least a portion of the first and second communication channels, and to receive diagnostic data returned by the vehicle diagnostic device 200.

[0058] Terminal 100 also includes a power supply for powering the various components. Terminal 100 may also include an external interface, which can be used to connect terminal 100 to other devices for communication, or to connect a charger to charge terminal 100.

[0059] The vehicle diagnostic device 200 can be used to perform diagnostic interactions with the electronic control unit and return diagnostic data to the terminal 100. The vehicle diagnostic device 200 can communicate with the terminal 100 through a first communication channel. In some embodiments, when the link quality information corresponding to the first communication channel meets the channel switching conditions, the terminal 100 can establish a second communication channel for communicating with the vehicle diagnostic device 200, and receive diagnostic data returned by the vehicle diagnostic device 200 through both the first and second communication channels.

[0060] The external network device 300 can be used to transmit data with the terminal 100. Examples include video data transmission, web page data transmission, and file download data transmission. It can also receive diagnostic result data uploaded by the terminal 100. In some embodiments, the terminal 100 can adjust the communication resource allocation parameters corresponding to the first and second communication channels based on the second queuing delay.

[0061] First, a definition of the terminology used in this application is provided:

[0062] ECU (Electronic Control Unit): An electronic control module in a vehicle used to control functions such as engine, braking, steering, body, and battery management.

[0063] ADAS (Advanced Driver Assistance System): A system that assists a vehicle in performing functions such as environmental perception, warning, braking, and lane keeping through sensors, controllers, and actuators.

[0064] Secondly, to facilitate understanding of the technical solutions provided in the embodiments of this application by those skilled in the art, the relevant technologies are described below: The inventors have discovered that in existing vehicle diagnostic communication schemes, the terminal can communicate simultaneously with both the vehicle diagnostic device and external network devices. The terminal can send diagnostic requests to the vehicle diagnostic device, and the vehicle diagnostic device can return diagnostic data to the terminal based on the diagnostic requests. The terminal can also transmit data with external network devices. After the diagnostic data arrives at the terminal, it typically enters the terminal's processing queue and is read and processed under the task scheduling of the terminal system. Existing terminal task scheduling is typically geared towards general task processing scenarios, primarily focusing on the fair execution of system tasks and overall throughput.

[0065] However, the aforementioned solutions primarily process diagnostic data through communication channel division of labor and general task scheduling. When diagnostic data from scenarios such as ECU remapping and ADAS calibration is continuously returned, the waiting time for the diagnostic data in the terminal's processing queue is prone to fluctuations. In situations involving high-volume data interaction between external network devices and the terminal, the diagnostic data reception process is easily affected by resource consumption, further increasing the queuing latency after the diagnostic data enters the terminal. Therefore, existing technologies suffer from poor stability in the queuing latency of diagnostic data on the terminal side.

[0066] To address the aforementioned problems, this application provides a vehicle diagnostic communication method. The vehicle diagnostic communication method of this application embodiment will be described in detail below with reference to the accompanying drawings.

[0067] Reference Figure 2 , Figure 2This is a flowchart illustrating a vehicle diagnostic communication method provided in an embodiment of this application, such as... Figure 2 As shown, the vehicle diagnostic communication method provided in this application embodiment may include steps 201 to 204, which are described in detail below.

[0068] 201. Receive the diagnostic data to be processed returned by the vehicle diagnostic device and write the diagnostic data to be processed into the first processing queue.

[0069] Specifically, the diagnostic data to be processed can be diagnostic data returned by the vehicle diagnostic equipment to the terminal that has not yet been read and processed by the terminal. The diagnostic data to be processed can include fault code data, data stream data, write feedback data, calibration feedback data, etc. The vehicle diagnostic equipment can be a device that interacts with the vehicle's electronic control unit (ECU) for diagnostic purposes and returns diagnostic data to the terminal. The first processing queue can be a queue used by the terminal to temporarily store the diagnostic data to be processed. After the diagnostic data to be processed is written into the first processing queue, it can wait for the terminal to read and process it according to the dequeue rules corresponding to the queue. The first processing queue can be used to receive diagnostic data continuously returned by the vehicle diagnostic equipment, enabling the terminal to manage unprocessed diagnostic data according to the queue order. The terminal can monitor the communication connection with the vehicle diagnostic equipment. When diagnostic data returned by the vehicle diagnostic equipment is present in the communication connection, the terminal can obtain the diagnostic data and identify it as diagnostic data to be processed. Subsequently, the terminal can write the diagnostic data to be processed into the first processing queue, where it awaits subsequent reading and processing. In some embodiments, the writing time of the diagnostic data to be processed can be recorded when it is written into the first processing queue. The write time can be used to characterize the point in time when the diagnostic data to be processed enters the first processing queue. The usage of the write time in the queuing delay determination process will be described in subsequent embodiments and will not be repeated here. For example, during ECU flashing, the vehicle diagnostic device can continuously return flashing feedback data to the terminal. After receiving the flashing feedback data, the terminal can write the flashing feedback data as diagnostic data to be processed into the first processing queue. The diagnostic data to be processed returned by the vehicle diagnostic device can be received through single-channel reception, dual-channel parallel reception, etc. An example of a receiving scheme for the diagnostic data to be processed is provided below.

[0070] In one possible implementation, the terminal communicates with the vehicle diagnostic device through a first communication channel. The specific steps of step 201 may include: establishing a second communication channel for communication with the vehicle diagnostic device when the link quality information meets the channel switching conditions; receiving candidate diagnostic data returned by the vehicle diagnostic device through the first and second communication channels; and performing deduplication on the received candidate diagnostic data to obtain the diagnostic data to be processed.

[0071] Specifically, link quality information can be used to represent the communication quality of the first communication channel. Link quality information may include signal strength, signal-to-noise ratio (SNR), packet loss rate, and retransmission count. Channel switching conditions can be used to determine if there is a decline in communication quality in the first communication channel. For example, channel switching conditions may include a signal strength lower than a preset signal strength threshold, a signal-to-noise ratio lower than a preset SNR threshold, or a packet loss rate higher than a preset packet loss rate threshold. The second communication channel can be a communication channel established by the terminal outside the first communication channel for communication with the vehicle diagnostic equipment. During the establishment of the second communication channel, the first communication channel can remain connected. This allows the terminal to establish the second communication channel before the first communication channel is disconnected. After the second communication channel is established, the terminal can receive diagnostic data returned by the vehicle diagnostic equipment through both the first and second communication channels. In other words, during channel switching, diagnostic data returned by the vehicle diagnostic equipment can reach the terminal through either the first or second communication channel. If the same diagnostic data arrives at the terminal through both the first and second communication channels, the terminal can perform deduplication on the received diagnostic data. Deduplication can be performed based on the data identifier, timestamp, data sequence number, and data content of the diagnostic data. For example, in a mobile diagnostic scenario within a workshop, the signal strength of the first communication channel may decrease due to the terminal's relocation. If the link quality information corresponding to the first communication channel meets the channel switching conditions, the terminal can establish a second communication channel and receive diagnostic data returned by the vehicle diagnostic equipment through both the first and second communication channels while maintaining a connection with the first communication channel. If the two communication channels receive the same diagnostic data, the terminal can perform deduplication based on the data sequence number.

[0072] In this embodiment, the terminal can establish a second communication channel for communicating with the vehicle diagnostic equipment when the link quality of the first communication channel meets the channel switching conditions, and receive diagnostic data while maintaining the connection in the first communication channel. This preserves the receiving path of diagnostic data during the communication channel switching process and reduces the occurrence of duplicate diagnostic data entering subsequent processing through deduplication.

[0073] 202. Obtain the first queuing delay corresponding to the historical diagnostic data in the first processing queue, and predict the second queuing delay corresponding to the diagnostic data to be processed based on the first queuing delay.

[0074] Specifically, historical diagnostic data can refer to diagnostic data that was written to the first processing queue before the diagnostic data to be processed and has already been read from the first processing queue by the terminal. The first queuing delay can be the duration from when the historical diagnostic data is written to the first processing queue to when it is read from the first processing queue. The second queuing delay can be the waiting time of the diagnostic data to be processed in the first processing queue, predicted based on the queuing status of the historical diagnostic data. Before processing the diagnostic data, the terminal can record the write time of the historical diagnostic data to the first processing queue and the read time of the historical diagnostic data from the first processing queue. The terminal can determine the first queuing delay of the historical diagnostic data in the first processing queue based on the time interval between the read time and the write time. If there are multiple historical diagnostic data sets, the terminal can determine the first queuing delay corresponding to each set of historical diagnostic data. After obtaining the first queuing delays corresponding to multiple historical diagnostic data sets, the terminal can predict the second queuing delay corresponding to the diagnostic data to be processed based on the first queuing delays corresponding to the multiple historical diagnostic data sets. The prediction method can include prediction based on changes in the multiple first queuing delays, or prediction based on the current data quantity and historical queuing status of the first processing queue. Taking the prediction method based on the changes in multiple first queuing delays as an example, during the ECU flashing process, the vehicle diagnostic equipment may continuously return multiple frames of flashing feedback data. The terminal can predict the possible waiting time when the current diagnostic data to be processed continues to remain in the first processing queue based on the actual waiting time of the previous few frames of flashing feedback data in the first processing queue. In some embodiments, the allowable processing time for diagnostic data to be returned from the vehicle diagnostic equipment to the terminal and processed by the terminal can be divided into multiple stage durations, which may include queuing time, wireless transmission time, receiving and processing time, and application processing time. For example, the allowable processing time can be 15ms, where the delay threshold corresponding to the queuing time can be 3ms, the delay threshold corresponding to the wireless transmission time can be 4ms, the delay threshold corresponding to the receiving and processing time can be 3ms, and the delay threshold corresponding to the application processing time can be 5ms. The embodiments of this application can predict the second queuing delay of the diagnostic data to be processed based on the first queuing delay of historical diagnostic data, and determine whether the second queuing delay meets the preset delay condition based on the comparison result between the second queuing delay and the delay threshold corresponding to the queuing time mentioned above.

[0075] The second queuing delay for the diagnostic data to be processed can be predicted using methods such as weighted moving average processing, regression prediction models, or time series prediction models. An example prediction scheme for the second queuing delay is provided below.

[0076] In one possible implementation, step 202 may include: collecting the first queuing delay corresponding to each of the multiple historical diagnostic data in the first processing queue; and performing a weighted moving average on the multiple first queuing delays to obtain the second queuing delay corresponding to the diagnostic data to be processed.

[0077] Specifically, the terminal can acquire the first queuing delay corresponding to multiple historical diagnostic data sets and perform a weighted moving average processing on these first queuing delays. The weighted moving average processing involves assigning weights to each of the multiple first queuing delays; that is, calculating the second queuing delay of the diagnostic data to be processed based on the multiple first queuing delays and their corresponding weights. The weights can be determined based on the time distance between the historical diagnostic data and the diagnostic data to be processed. Historical diagnostic data closer to the data to be processed can have a larger weight, while historical diagnostic data farther away can have a smaller weight. For example, the terminal can collect the first queuing delays of the most recent N historical diagnostic data sets in the first processing queue and assign decreasing weights to these N first queuing delays in ascending order of time. N can be an integer greater than 1. The terminal can then perform a weighted summation of the N first queuing delays and their corresponding weights to obtain the second queuing delay corresponding to the diagnostic data to be processed. The second queuing delay obtained through weighted moving average processing can reflect recent changes in the queuing pressure of the first processing queue. For example, during ECU rewriting, the vehicle diagnostic equipment may continuously return rewriting feedback data. The terminal can collect the first queuing delay of multiple write feedback data points preceding the current write feedback data in the first processing queue, and perform a weighted moving average on the multiple first queuing delays to obtain the second queuing delay corresponding to the current write feedback data. Therefore, the potential waiting time for the current write feedback data in the first processing queue can be predicted before reading.

[0078] In this embodiment, the terminal can perform a weighted moving average processing on the first queuing delay of multiple historical diagnostic data in the first processing queue, so that historical diagnostic data closer to the diagnostic data to be processed has a higher influence weight on the second queuing delay. This allows the second queuing delay to reflect the recent queuing changes in the first processing queue, reduces the influence of earlier historical diagnostic data on the current prediction result, and thus improves the matching degree between the second queuing delay and the current queue state, providing a more accurate basis for determining whether the diagnostic data to be processed needs to be moved into the second processing queue.

[0079] 203. If the second queuing delay meets the preset delay condition, the diagnostic data to be processed is moved from the first processing queue to the second processing queue, and the processing priority of the second processing queue is higher than that of the first processing queue.

[0080] Specifically, the preset delay condition can be used to determine whether the waiting time is too long when the diagnostic data to be processed continues to remain in the first processing queue. The preset delay condition can be preset based on the allowed waiting time of the diagnostic data, the historical queuing status of the first processing queue, and the terminal's reading cycle of the diagnostic data. In some embodiments, the allowed waiting time of the diagnostic data can be determined based on the diagnostic scenario type. For example, the allowed waiting time of the diagnostic data corresponding to the ECU flashing scenario and the ADAS calibration scenario can be less than the allowed waiting time of the diagnostic data corresponding to the conventional diagnostic scenario and the data reading scenario. The second processing queue can be a queue with a higher processing priority than the first processing queue. After the diagnostic data to be processed is moved into the second processing queue, it can be read and processed earlier than the diagnostic data in the first processing queue. Diagnostic data to be processed that meets the preset delay condition in the second queuing delay can be directly moved into the second processing queue, or the data type of the diagnostic data can be used to determine whether it needs to be moved into the second processing queue, or the diagnostic scenario type corresponding to the diagnostic data can be used to determine whether it needs to be moved into the second processing queue. The following provides an exemplary scheme for moving diagnostic data.

[0081] In one possible implementation, step 203 may include: obtaining the diagnostic scenario type corresponding to the diagnostic data to be processed. If the diagnostic scenario type belongs to a preset scenario type and the second queuing delay meets the preset delay condition, the diagnostic data to be processed is moved from the first processing queue to the second processing queue.

[0082] Specifically, the diagnostic scenario type can be used to represent the vehicle diagnostic scenario to which the diagnostic data to be processed belongs. The diagnostic scenario type can be determined based on the content of the diagnostic data returned by the vehicle diagnostic equipment, the diagnostic business currently being executed by the diagnostic application, and the current diagnostic status recorded by the terminal. The preset scenario type can be used to represent the diagnostic scenario type that requires queue adjustment judgment. For example, preset scenario types may include ECU flashing scenarios, ADAS calibration scenarios, etc.

[0083] After receiving the diagnostic data to be processed, the terminal can determine whether the second queuing delay meets the preset delay condition. If the second queuing delay meets the preset delay condition, the terminal can further obtain the diagnostic scenario type corresponding to the diagnostic data to be processed. If the diagnostic scenario type belongs to the preset scenario type, the diagnostic data to be processed can be moved from the first processing queue to the second processing queue. For example, in the ECU flashing scenario, the flashing feedback data returned by the vehicle diagnostic equipment can correspond to the ECU flashing scenario. The terminal can first determine the diagnostic scenario type (ECU flashing scenario) corresponding to the flashing feedback data, and if the diagnostic scenario type belongs to the preset scenario type (ECU flashing scenario) and the second queuing delay meets the preset delay condition, move the flashing feedback data from the first processing queue to the second processing queue.

[0084] In this embodiment, the processing queue containing the diagnostic data to be processed can be adjusted based on the diagnostic scenario type and the second queuing delay. This ensures that the queue adjustment process matches the vehicle diagnostic scenario to which the diagnostic data to be processed belongs, reducing the number of diagnostic data that does not belong to the preset scenario type entering the second processing queue. This, in turn, reduces the impact of an excessive number of diagnostic data in the second processing queue on the outgoing processing.

[0085] In one possible implementation, moving the diagnostic data to be processed from the first processing queue to the second processing queue when the diagnostic scenario type belongs to a preset scenario type and the second queuing delay meets the preset delay condition may include: determining the delay difference between the second queuing delay and a delay threshold corresponding to the preset delay condition; determining the queue position of the diagnostic data to be processed in the second processing queue based on the delay difference; and moving the diagnostic data to be processed from the first processing queue to the second processing queue according to the queue position. The larger the delay difference, the earlier the diagnostic data to be processed is in the queue of the second processing queue.

[0086] Specifically, the preset delay condition may include a second queuing delay greater than or equal to a delay threshold, or the ratio between the second queuing delay and the delay threshold being greater than or equal to a preset ratio, or the second queuing delay being greater than or equal to the delay threshold in multiple consecutive predictions. The delay threshold can be determined based on the diagnostic scenario type, terminal reading cycle, and allowable waiting time for diagnostic data. For example, the second queuing delay can be associated with the diagnostic scenario type corresponding to the diagnostic data to be processed. For diagnostic scenario types such as ECU flashing and ADAS calibration, the terminal can use a smaller delay threshold to determine whether the second queuing delay meets the preset delay condition; for diagnostic scenario types such as fault reading and data reading, the terminal can use a larger delay threshold to determine whether the second queuing delay meets the preset delay condition.

[0087] The latency difference indicates the extent to which the second queuing latency exceeds a latency threshold. For example, if the second queuing latency is greater than or equal to the latency threshold, it can be determined that the second queuing latency meets a preset latency condition, and the latency difference can be determined based on the difference between the second queuing latency and the latency threshold. The terminal can determine the queue position of the diagnostic data to be processed in the second processing queue based on the latency difference. If the latency difference is large, the diagnostic data to be processed can be placed in a higher position in the second processing queue. If the latency difference is small, the diagnostic data to be processed can be placed in a higher position in the second processing queue. Here, "higher" and "lower" can be relative to diagnostic data already existing in the second processing queue. In one example, other diagnostic data may already exist in the second processing queue. The terminal can determine the latency difference corresponding to the diagnostic data to be processed and the latency difference corresponding to other diagnostic data separately, and determine the queue position of the diagnostic data to be processed in the second processing queue based on the magnitude of the latency differences. Diagnostic data with larger latency differences will be placed earlier in the queue of the second processing queue. For example, in an ADAS calibration scenario, if the latency difference corresponding to the first calibration feedback data is greater than the latency difference corresponding to the second calibration feedback data, then the queue position of the first calibration feedback data in the second processing queue can be before that of the second calibration feedback data. The terminal can move the diagnostic data to be processed from the first processing queue to the second processing queue according to the determined queue position. In some embodiments, the terminal can determine the specific scheduling parameters corresponding to the diagnostic data to be processed based on the diagnostic scenario type. The scheduling parameters may include period parameters, execution time parameters, deadline parameters, and priority parameters. The period parameter can be used to determine the reading period corresponding to the diagnostic data to be processed, the execution time parameter can be used to represent the processing duration corresponding to the diagnostic data to be processed, the deadline parameter can be used to determine the latency threshold corresponding to the preset latency condition, and the priority parameter can be used to determine the processing priority corresponding to the diagnostic data to be processed.

[0088] In this embodiment, the queue position of the diagnostic data to be processed in the second processing queue can be determined based on the delay difference between the second queuing delay and the delay threshold, so that diagnostic data with a larger delay difference is placed earlier in the second processing queue. This reduces the waiting time for diagnostic data with a larger delay difference when multiple diagnostic data are moved into the second processing queue.

[0089] 204. If the diagnostic data to be processed meets the preset dequeue condition corresponding to the second processing queue, then the diagnostic data to be processed is read from the second processing queue and processed.

[0090] Specifically, preset dequeue conditions can be used to determine whether the diagnostic data to be processed in the second processing queue can be read by the terminal. Preset dequeue conditions can be determined based on the queue position of the second processing queue, the terminal's reading cycle, and the writing time of the diagnostic data in the second processing queue. For example, preset dequeue conditions may include the diagnostic data to be processed being at the head of the second processing queue, or the reading time corresponding to the arrival of the diagnostic data in the second processing queue. The terminal can check whether the diagnostic data to be processed meets the preset dequeue conditions according to the dequeue rules corresponding to the second processing queue. If the diagnostic data to be processed meets the preset dequeue conditions, the terminal can read the diagnostic data from the second processing queue and process it. If there are multiple diagnostic data in the second processing queue, the terminal can read the diagnostic data sequentially according to the queue position of each diagnostic data in the second processing queue. Processing the diagnostic data to be processed can include parsing, verification, status update, and display. Parsing can be used to obtain diagnostic results, fault codes, data stream parameters, write feedback status, or calibration feedback status from the diagnostic data to be processed. Verification can be used to determine whether the diagnostic data to be processed meets data format or integrity requirements. Status update processing can be used to update the execution status of the current diagnostic service based on the diagnostic data to be processed, which may include updating the execution progress of the diagnostic service. Display processing can be used to output the processing results corresponding to the diagnostic data to be processed to the terminal display interface. For example, in an ECU flashing scenario, the diagnostic data to be processed may include flashing feedback status. After the terminal reads the flashing feedback status from the second processing queue, it can parse the flashing feedback status and update the ECU flashing progress based on the flashing feedback status.

[0091] In this embodiment, the terminal can read and process the diagnostic data to be processed from the second processing queue after the diagnostic data to be processed meets the preset dequeue conditions corresponding to the second processing queue, so that the diagnostic data to be processed that has been moved into the second processing queue can enter the processing flow according to the dequeue rules corresponding to the second processing queue.

[0092] In one possible implementation, the terminal is communicatively connected to an external network device, which is distinct from the vehicle diagnostic device. The vehicle diagnostic communication method may further include: adjusting the communication resource allocation parameters between the data transmission corresponding to the vehicle diagnostic device and the data transmission corresponding to the external network device when the second queuing delay meets the preset delay condition.

[0093] Specifically, data transmission corresponding to vehicle diagnostic equipment can be used to represent diagnostic data transmission between the terminal and the vehicle diagnostic equipment. Data transmission corresponding to external network devices can be used to represent data transmission between the terminal and external network devices. External network devices can include servers, cloud platforms, network storage devices, etc. Data transmission corresponding to external network devices can include video data, web page data, file download data, etc., that is, non-diagnostic data streams such as user internet browsing, video, and downloads. Communication resource allocation parameters can be used to represent the communication resource allocation relationship between data transmission corresponding to vehicle diagnostic equipment and data transmission corresponding to external network devices. Communication resource allocation parameters can include sending queue weight, communication priority parameters, etc. Communication priority parameters can be used to represent the scheduling order of data transmission corresponding to vehicle diagnostic equipment and data transmission corresponding to external network devices in the terminal communication module. Sending queue weight can be used to represent the dequeue ratio of data transmission corresponding to vehicle diagnostic equipment and data transmission corresponding to external network devices in the sending queue. By adjusting the communication resource allocation parameters, the proportion or order of communication resources occupied by data transmission corresponding to vehicle diagnostic equipment and data transmission corresponding to external network devices in the terminal can be changed.

[0094] In some embodiments, the terminal may generate a communication resource adjustment instruction when the second queuing delay meets a preset delay condition. The communication resource adjustment instruction can be used to instruct the terminal's communication module to adjust the communication resource allocation parameters between the data transmission corresponding to the vehicle diagnostic device and the data transmission corresponding to the external network device. The communication module can, according to the communication resource adjustment instruction, increase the communication resource allocation parameters for the data transmission corresponding to the vehicle diagnostic device and decrease the communication resource allocation parameters for the data transmission corresponding to the external network device.

[0095] In this embodiment, the communication resource allocation parameters between the data transmission of the vehicle diagnostic device and the data transmission of the external network device can be adjusted according to the second queuing delay, so that the communication resource allocation process is associated with the queuing status of the terminal, thereby reducing the resource occupation caused by the data transmission of the external network device on the data transmission of the vehicle diagnostic device.

[0096] In one possible implementation, the communication resource allocation parameters may include a bandwidth allocation ratio. When the second queuing delay meets the preset delay condition, adjusting the communication resource allocation parameters between the data transmission corresponding to the vehicle diagnostic device and the data transmission corresponding to the external network device may include: increasing the bandwidth allocation ratio for the data transmission corresponding to the vehicle diagnostic device and correspondingly decreasing the bandwidth allocation ratio for the data transmission corresponding to the external network device when the second queuing delay meets the preset delay condition.

[0097] Specifically, the terminal can determine the adjustment range of communication resource allocation parameters based on the delay difference between the second queuing delay and the delay threshold corresponding to the preset delay condition. The larger the delay difference, the greater the increase in the communication resource allocation parameters for data transmission corresponding to the vehicle diagnostic device, and the greater the decrease in the communication resource allocation parameters for data transmission corresponding to the external network device. Taking the communication resource allocation parameters including bandwidth allocation ratio as an example, the terminal can obtain the current bandwidth allocation ratios for data transmission corresponding to the vehicle diagnostic device and data transmission corresponding to the external network device when the second queuing delay meets the preset delay condition. If the current bandwidth allocation ratio for data transmission corresponding to the vehicle diagnostic device is lower than the preset ratio, or the current bandwidth allocation ratio for data transmission corresponding to the external network device is higher than the preset ratio, the terminal can increase the bandwidth allocation ratio for data transmission corresponding to the vehicle diagnostic device and correspondingly decrease the bandwidth allocation ratio for data transmission corresponding to the external network device. The bandwidth allocation ratio can be used to represent the proportional relationship of communication bandwidth allocation between the terminal and the data transmission corresponding to the vehicle diagnostic device. The bandwidth allocation ratio for data transmission corresponding to the vehicle diagnostic device corresponds to diagnostic data transmission between the terminal and the vehicle diagnostic device. The bandwidth allocation ratio for data transmission corresponding to the external network device corresponds to data transmission between the terminal and the external network device.

[0098] The bandwidth allocation ratio can be adjusted in several ways, including a fixed-ratio adjustment and a tiered adjustment. A fixed-ratio adjustment can increase the bandwidth allocation ratio for data transmission to the vehicle diagnostic equipment by a preset ratio, and decrease the bandwidth allocation ratio for data transmission to external network devices by a corresponding ratio. A tiered adjustment can determine the adjustment level based on the delay difference between a second queuing delay and a delay threshold, and adjust the bandwidth allocation ratio between data transmission to the vehicle diagnostic equipment and data transmission to external network devices according to the ratio corresponding to the adjustment level. For example, a terminal receives diagnostic data returned by the vehicle diagnostic equipment and downloads diagnostic data from an external network device. If the second queuing delay meets a preset delay condition, the terminal can increase the bandwidth allocation ratio for data transmission to the vehicle diagnostic equipment and correspondingly decrease the bandwidth allocation ratio for data transmission to external network devices, resulting in a higher bandwidth allocation ratio for data transmission to the vehicle diagnostic equipment.

[0099] In this embodiment, when the second queuing delay meets the preset delay condition, the bandwidth allocation ratio between the data transmission corresponding to the vehicle diagnostic device and the data transmission corresponding to the external network device can be adjusted in a coordinated manner to reduce the resource occupation impact of the data transmission corresponding to the external network device on the data transmission corresponding to the vehicle diagnostic device.

[0100] The above describes a vehicle diagnostic communication method provided by an embodiment of this application. The following describes the apparatus for performing the above-described vehicle diagnostic communication method.

[0101] Please see Figure 3 , Figure 3 This is a schematic diagram of the structure of a vehicle diagnostic communication device provided in an embodiment of this application. Figure 3 As shown, the vehicle diagnostic communication device 300 includes:

[0102] The writing module 301 is used to receive the diagnostic data to be processed returned by the vehicle diagnostic device and write the diagnostic data to be processed into the first processing queue.

[0103] The prediction module 302 is used to obtain the first queuing delay corresponding to the historical diagnostic data in the first processing queue, and predict the second queuing delay corresponding to the diagnostic data to be processed based on the first queuing delay.

[0104] The inbound module 303 is used to move the diagnostic data to be processed from the first processing queue to the second processing queue when the second queuing delay meets the preset delay condition. The processing priority of the second processing queue is higher than that of the first processing queue.

[0105] The processing module 304 is used to read the diagnostic data to be processed from the second processing queue and process the diagnostic data to be processed if the diagnostic data to be processed meets the preset dequeue conditions corresponding to the second processing queue.

[0106] In one possible implementation, the prediction module 302 is specifically used for:

[0107] Collect the first queuing delay corresponding to each of the multiple historical diagnostic data in the first processing queue;

[0108] A weighted moving average is applied to multiple first queuing delays to obtain the second queuing delay corresponding to the diagnostic data to be processed.

[0109] In one possible implementation, the shift module 303 is specifically used for:

[0110] Obtain the diagnostic scenario type corresponding to the diagnostic data to be processed;

[0111] If the diagnostic scenario type belongs to a preset scenario type and the second queuing delay meets the preset delay condition, the diagnostic data to be processed is moved from the first processing queue to the second processing queue.

[0112] In one possible implementation, the shift module 303 is specifically used for:

[0113] If the diagnostic scenario type belongs to the preset scenario type and the second queuing delay meets the preset delay condition, determine the delay difference between the second queuing delay and the delay threshold corresponding to the preset delay condition;

[0114] Based on the time delay difference, determine the queue position of the diagnostic data to be processed in the second processing queue;

[0115] According to the queue position, the diagnostic data to be processed is moved from the first processing queue to the second processing queue;

[0116] The larger the time delay difference, the earlier the diagnostic data to be processed is in the second processing queue.

[0117] In one possible implementation, the terminal is communicatively connected to an external network device, which is distinct from the vehicle diagnostic device. The vehicle diagnostic communication device 300 further includes an adjustment module for:

[0118] If the second queuing delay meets the preset delay condition, the communication resource allocation parameters between the data transmission corresponding to the vehicle diagnostic device and the data transmission corresponding to the external network device are adjusted.

[0119] In one possible implementation, the vehicle diagnostic communication device 300 further includes an adjustment module, specifically used for:

[0120] When the second queuing delay meets the preset delay condition, the bandwidth allocation ratio for data transmission to the vehicle diagnostic device is increased, and the bandwidth allocation ratio for data transmission to the external network device is correspondingly decreased.

[0121] In one possible implementation, the terminal communicates with the vehicle diagnostic device via a first communication channel, and the writing module 301 is specifically used for:

[0122] Obtain the link quality information corresponding to the first communication channel;

[0123] If the link quality information meets the channel switching conditions, a second communication channel for communicating with the vehicle diagnostic equipment is established.

[0124] The system receives candidate diagnostic data returned by the vehicle diagnostic device through the first communication channel and the second communication channel, and performs deduplication processing on the received candidate diagnostic data to obtain the diagnostic data to be processed.

[0125] This application also provides an electronic device in its embodiments. (See reference...) Figure 4 The diagram illustrates a structural schematic of an electronic device suitable for implementing the vehicle diagnostic communication method in the embodiments of this application. The electronic device in the embodiments of this application may include, but is not limited to, fixed terminals such as mobile phones, laptops, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, etc. Figure 4 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0126] like Figure 4 As shown, the electronic device may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 401, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 402 or a program loaded from a storage device 408 into a random access memory (RAM) 403. When the electronic device is powered on, the RAM 403 also stores various programs and data required for the operation of the electronic device. The processing unit 401, ROM 402, and RAM 403 are interconnected via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.

[0127] Typically, the following devices can be connected to I / O interface 405: input devices 406 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 407 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 408 including, for example, memory cards, hard drives, etc.; and communication devices 409. Communication device 409 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 4 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have alternatively.

[0128] This application also provides a computer program product including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the vehicle diagnostic communication methods provided in this application.

[0129] This application also provides a computer-readable storage medium carrying one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the vehicle diagnostic communication methods provided in this application.

[0130] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and 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. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0131] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0132] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0133] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A vehicle diagnostic communication method, characterized in that, Applied to a terminal, the terminal is communicatively connected to vehicle diagnostic equipment, including: Receive the diagnostic data to be processed returned by the vehicle diagnostic equipment, and write the diagnostic data to be processed into the first processing queue; Obtain the first queuing delay corresponding to the historical diagnostic data in the first processing queue, and predict the second queuing delay corresponding to the diagnostic data to be processed based on the first queuing delay; If the second queuing delay meets the preset delay condition, the diagnostic data to be processed is moved from the first processing queue to the second processing queue, and the processing priority of the second processing queue is higher than that of the first processing queue. If the diagnostic data to be processed meets the preset dequeue condition corresponding to the second processing queue, then the diagnostic data to be processed is read from the second processing queue and processed.

2. The method according to claim 1, characterized in that, The step of obtaining the first queuing delay corresponding to the historical diagnostic data in the first processing queue, and predicting the second queuing delay corresponding to the diagnostic data to be processed based on the first queuing delay, includes: Collect the first queuing delay corresponding to each of the multiple historical diagnostic data in the first processing queue; A weighted moving average is applied to multiple first queuing delays to obtain the second queuing delay corresponding to the diagnostic data to be processed.

3. The method according to claim 1, characterized in that, When the second queuing delay meets the preset delay condition, the step of moving the diagnostic data to be processed from the first processing queue to the second processing queue includes: Obtain the diagnostic scenario type corresponding to the diagnostic data to be processed; If the diagnostic scenario type belongs to a preset scenario type and the second queuing delay meets the preset delay condition, the diagnostic data to be processed is moved from the first processing queue to the second processing queue.

4. The method according to claim 3, characterized in that, The step of moving the diagnostic data to be processed from the first processing queue to the second processing queue when the diagnostic scenario type belongs to a preset scenario type and the second queuing delay meets the preset delay condition includes: If the diagnostic scenario type belongs to the preset scenario type and the second queuing delay meets the preset delay condition, determine the delay difference between the second queuing delay and the delay threshold corresponding to the preset delay condition; Based on the time delay difference, determine the queue position of the diagnostic data to be processed in the second processing queue; According to the queue position, the diagnostic data to be processed is moved from the first processing queue to the second processing queue; The larger the time delay difference, the earlier the diagnostic data to be processed is in the second processing queue.

5. The method according to claim 1, characterized in that, The terminal is communicatively connected to an external network device, which is distinct from the vehicle diagnostic device. The method further includes: If the second queuing delay meets the preset delay condition, the communication resource allocation parameters between the data transmission corresponding to the vehicle diagnostic device and the data transmission corresponding to the external network device are adjusted.

6. The method according to claim 5, characterized in that, The communication resource allocation parameters include a bandwidth allocation ratio. The step of adjusting the communication resource allocation parameters between the data transmission corresponding to the vehicle diagnostic device and the data transmission corresponding to the external network device when the second queuing delay meets the preset delay condition includes: When the second queuing delay meets the preset delay condition, the bandwidth allocation ratio for data transmission to the vehicle diagnostic device is increased, and the bandwidth allocation ratio for data transmission to the external network device is correspondingly decreased.

7. The method according to claim 1, characterized in that, The terminal communicates with the vehicle diagnostic device through a first communication channel, and receiving the diagnostic data to be processed returned by the vehicle diagnostic device includes: Obtain the link quality information corresponding to the first communication channel; If the link quality information meets the preset channel switching conditions, a second communication channel is established for communicating with the vehicle diagnostic equipment. The system receives candidate diagnostic data returned by the vehicle diagnostic device through the first communication channel and the second communication channel, and performs deduplication processing on the received candidate diagnostic data to obtain the diagnostic data to be processed.

8. A vehicle diagnostic communication device, characterized in that, Applied to a terminal, the terminal is communicatively connected to vehicle diagnostic equipment, including: The writing module is used to receive the diagnostic data to be processed returned by the vehicle diagnostic equipment and write the diagnostic data to be processed into the first processing queue. The prediction module is used to obtain the first queuing delay corresponding to the historical diagnostic data in the first processing queue, and predict the second queuing delay corresponding to the diagnostic data to be processed based on the first queuing delay. The move-in module is used to move the diagnostic data to be processed from the first processing queue to the second processing queue when the second queuing delay meets the preset delay condition. The processing priority of the second processing queue is higher than that of the first processing queue. The processing module is used to read the diagnostic data to be processed from the second processing queue and process the diagnostic data to be processed if the diagnostic data to be processed meets the preset dequeue conditions corresponding to the second processing queue.

9. An electronic device, characterized in that, It includes at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program to enable the electronic device to implement the vehicle diagnostic communication method as described in any one of claims 1 to 7.

10. A computer storage medium, characterized in that, The storage medium carries one or more computer programs that, when executed by an electronic device, enable the electronic device to implement the vehicle diagnostic communication method as described in any one of claims 1 to 7.

Images