Remote diagnostic methods and related equipment

Abstract

This application discloses a remote diagnostic method and related equipment to avoid diagnostic failures caused by excessive network latency. The method includes: receiving a first diagnostic request sent by a diagnostic device through a second device, and sending the first diagnostic request to a vehicle; determining a diagnostic request corresponding to the first diagnostic response based on the response type of the first diagnostic response sent by the vehicle; if the first diagnostic response corresponds to the first diagnostic request, obtaining a first request identifier from the first diagnostic request record and a first response identifier from the diagnostic response; sending a request-response identifier pair to the second device, such that the second device stores the request-response identifier pair, which includes a first request identifier, a first response identifier, and the association between the two.

Description

Technical Field

[0001] This application relates to the field of automotive diagnostics, and more particularly to remote diagnostic methods and related equipment. Background Technology

[0002] Automotive diagnostics require sufficiently low latency; diagnostic response timeouts typically lead to diagnostic failure. However, in remote diagnostics, users usually use wireless networks such as WiFi or 4G. The network latency of wireless networks is unstable, making it difficult to consistently meet the low latency requirements of automotive diagnostics, thus causing remote diagnostic failures.

[0003] To address this issue, the current approach is to define a negative response code 0x78 in the Unified Diagnostic Services (UDS). If network latency does not meet the vehicle's diagnostic requirements, and a second device connected to the diagnostic device receives a diagnostic request, the second device will respond with a negative response code 0x78. Upon receiving this negative response code 0x78, the diagnostic device will wait for a period of time to avoid diagnostic failures caused by network latency not meeting the vehicle's diagnostic requirements.

[0004] In order to respond to the negative response code 0x78 for the diagnostic request, the second device needs to look up the corresponding response identifier in the preset configuration file based on the request identifier in the diagnostic request in order to generate a negative response including the aforementioned negative response code, thus responding to the diagnostic request. However, the existing configuration file is manually configured. Whether it is a configuration error or a failure to update the configuration in a timely manner, the second device will be unable to send the negative response code, which will lead to the diagnostic timeout and failure. Summary of the Invention

[0005] This application provides a remote diagnostic method and related equipment to avoid diagnostic failures caused by excessive network latency.

[0006] A first aspect of this application provides a remote diagnostic method applied to a first device, the first device being communicatively connected to a vehicle and a second device, the second device being communicatively connected to a diagnostic device, the remote diagnostic method comprising:

[0007] Receive the first diagnostic request sent by the diagnostic device through the second device, and send the first diagnostic request to the vehicle;

[0008] Based on the response type of the first diagnostic response sent by the vehicle, determine the diagnostic request corresponding to the first diagnostic response;

[0009] If the first diagnostic response corresponds to the first diagnostic request, then the first request identifier is obtained from the first diagnostic request record, and the first response identifier is obtained from the first diagnostic response;

[0010] Send a request-response identifier pair to the second device so that the second device stores the request-response identifier pair, which includes the first request identifier, the first response identifier, and the association between the two.

[0011] In one specific implementation, determining the diagnostic request corresponding to the first diagnostic response includes:

[0012] Parse the first diagnostic response to obtain the first diagnostic identifier, and determine whether there is a target historical diagnostic request record including the first diagnostic identifier in the buffer;

[0013] If the target historical diagnostic request record exists, then the diagnostic request corresponding to the target historical diagnostic request record is determined to be the diagnostic request corresponding to the first diagnostic response.

[0014] In one specific implementation, parsing the first diagnostic response to obtain the first diagnostic identifier includes:

[0015] If the response type is a positive response, then subtract 0x40 from the first byte of the first diagnostic response to obtain the first diagnostic identifier;

[0016] If the response type is a negative response, then the second byte of the first diagnostic response is determined to be the first diagnostic identifier.

[0017] In one specific implementation, the method further includes:

[0018] Receive the first diagnostic request sent by the second device, and send the first diagnostic request to the vehicle;

[0019] Parse the first diagnostic request to obtain the first request identifier and the first diagnostic identifier;

[0020] If there is no historical diagnostic request record in the buffer that has the same historical request identifier as the first request identifier and the same historical diagnostic identifier as the first diagnostic identifier, then a new first diagnostic request record is added to the buffer. The first diagnostic request record includes the first request identifier, the first diagnostic identifier, and the relationship between the two.

[0021] In one specific implementation, the first diagnostic request record further includes: a first moment; the historical diagnostic request record includes: a historical moment; and the method further includes:

[0022] If there is a historical diagnostic request record in the buffer that has the same historical request identifier as the first request identifier, the same historical diagnostic identifier as the first diagnostic identifier, and a different historical time from the first time, then the historical time in the historical diagnostic request record to be updated will be updated to the first time.

[0023] In one specific implementation, the method further includes:

[0024] If there is a historical diagnostic request record to be deleted in the buffer whose corresponding historical request identifier is inconsistent with the first request identifier and whose corresponding historical diagnostic identifier is consistent with the first diagnostic identifier, then the historical diagnostic request record to be deleted will be deleted.

[0025] In one specific implementation, each diagnostic request record further includes: the request time, and the method further includes:

[0026] Delete diagnostic request records in the buffer whose corresponding request time meets the preset timeout deletion condition. The request time includes a first time and / or a historical time. The diagnostic request record includes the first diagnostic request record and / or a historical diagnostic request record.

[0027] A second aspect of this application provides a remote diagnostic method applied to a second device, the second device being connected to a diagnostic device, the remote diagnostic method comprising:

[0028] Receive a request-response identifier pair sent by a first device connected to the vehicle and store it in the identifier storage area. The request-response identifier pair includes the first request identifier, the first response identifier, and the association between the two.

[0029] Parse the second diagnostic request sent by the diagnostic device to obtain the second request identifier;

[0030] If the second request identifier matches the first request identifier, a second diagnostic response including the first response identifier is sent to the diagnostic device. The second diagnostic response is a negative response with a negative response code of 0x78.

[0031] A third aspect of this application provides a first device, which is communicatively connected to a vehicle and a second device, and the second device is communicatively connected to a diagnostic device. The first device includes:

[0032] The receiving unit is configured to receive a first diagnostic request sent by the diagnostic device through the second device, and send the first diagnostic request to the vehicle;

[0033] The determining unit is configured to determine a diagnostic request corresponding to the first diagnostic response based on the response type of the first diagnostic response sent by the vehicle.

[0034] The acquisition unit is configured to, if the first diagnostic response corresponds to the first diagnostic request, acquire a first request identifier from the first diagnostic request record and acquire a first response identifier from the first diagnostic response;

[0035] The sending unit is configured to send a request-response identifier pair to the second device, so that the second device stores the request-response identifier pair, wherein the request-response identifier pair includes the first request identifier, the first response identifier, and the association relationship between the two.

[0036] In one specific implementation, the determining unit is specifically used to parse the first diagnostic response to obtain a first diagnostic identifier, and to determine whether there is a target historical diagnostic request record including the first diagnostic identifier in the buffer.

[0037] If the target historical diagnostic request record exists, then the diagnostic request corresponding to the target historical diagnostic request record is determined to be the diagnostic request corresponding to the first diagnostic response.

[0038] In one specific implementation, the determining unit is specifically used to subtract 0x40 from the first byte of the first diagnostic response to obtain the first diagnostic identifier if the response type is a positive response.

[0039] If the response type is a negative response, then the second byte of the first diagnostic response is determined to be the first diagnostic identifier.

[0040] In one specific implementation, the first device further includes: a new addition unit;

[0041] The receiving unit is further configured to receive a first diagnostic request sent by the second device and send the first diagnostic request to the vehicle;

[0042] The determining unit is further configured to parse the first diagnostic request to obtain a first request identifier and a first diagnostic identifier;

[0043] The newly added unit is used to add a first diagnostic request record to the buffer if there is no corresponding historical request record in the buffer that matches the first request record and the corresponding historical diagnostic record that matches the first diagnostic record. The first diagnostic request record includes the first request record, the first diagnostic record, and the relationship between the two.

[0044] In one specific implementation, the first diagnostic request record further includes: a first moment; the historical diagnostic request record includes: a historical moment; and the first device further includes: an update unit.

[0045] The update unit is configured to update the historical time in the historical diagnostic request record to the first time if there is a historical request record in the buffer that has the same historical request identifier as the first request identifier, the same historical diagnostic identifier as the first diagnostic identifier, and a different historical time than the first time.

[0046] In one specific implementation, the first device further includes: a deletion unit;

[0047] The deletion unit is used to delete a historical diagnostic request record to be deleted if there is a historical request record in the buffer whose corresponding historical request identifier is inconsistent with the first request identifier and whose corresponding historical diagnostic identifier is consistent with the first diagnostic identifier.

[0048] In one specific implementation, each diagnostic request record further includes: a request time. The deletion unit is also used to delete diagnostic request records in the buffer whose corresponding request time meets the preset timeout deletion condition. The request time includes a first time and / or a historical time. The diagnostic request record includes the first diagnostic request record and / or a historical diagnostic request record.

[0049] A fourth aspect of this application provides a second device connected to a diagnostic device, the second device comprising:

[0050] The receiving unit is used to receive a request-response identifier pair sent by a first device connected to the vehicle and store it in the identifier storage area. The request-response identifier pair includes the first request identifier, the first response identifier, and the association relationship between the two.

[0051] The parsing unit is used to parse the second diagnostic request sent by the diagnostic device to obtain the second request identifier;

[0052] The sending unit is configured to send a second diagnostic response, including the first response identifier, to the diagnostic device if the second request identifier matches the first request identifier. The second diagnostic response is a negative response with a negative response code of 0x78.

[0053] A fifth aspect of this application provides a remote diagnostic device, comprising:

[0054] Central processing unit, memory, and input / output interfaces;

[0055] The memory is either a short-term storage memory or a persistent storage memory;

[0056] The central processing unit is configured to communicate with the memory and execute instructions in the memory to perform the method described in the first or second aspect.

[0057] A sixth aspect of this application provides a computer program product containing instructions that, when run on a computer, cause the computer to perform the method described in the first or second aspect.

[0058] A seventh aspect of this application provides a computer storage medium storing instructions that, when executed on a computer, cause the computer to perform the method described in the first or second aspect.

[0059] As can be seen from the above technical solutions, the embodiments of this application have the following advantages: After receiving a first diagnostic response sent by the vehicle, the first device can determine the diagnostic request corresponding to the first diagnostic response based on the response type of the first diagnostic response. If the first diagnostic response corresponds to the first diagnostic request, the first request identifier is parsed from the first diagnostic request, and the first response identifier is parsed from the first diagnostic response. After receiving a request-response identifier pair including the first request identifier, the first response identifier, and the association between the two, if the second device receives a diagnostic request including the first request identifier, it can send a negative response with a negative response code of 0x78 to the diagnostic device based on the first request response when the network latency is large. This allows the diagnostic device to wait after receiving the negative response, avoiding diagnostic failures caused by network latency not meeting the vehicle diagnostic requirements. Attached Figure Description

[0060] Figure 1 This is a system architecture diagram of the remote diagnostic method disclosed in the embodiments of this application;

[0061] Figure 2 This is a schematic flowchart of a remote diagnostic method disclosed in an embodiment of this application;

[0062] Figure 3 This is a schematic diagram of the structure of the first device disclosed in an embodiment of this application;

[0063] Figure 4 This is a schematic diagram of the structure of the second device disclosed in an embodiment of this application;

[0064] Figure 5 This is another structural schematic diagram of the remote diagnostic device disclosed in the embodiments of this application. Detailed Implementation

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

[0066] This application provides a remote diagnostic method and related equipment to avoid diagnostic failures caused by excessive network latency.

[0067] Please see Figure 1 To better implement the remote diagnostic method of this application embodiment, this application embodiment provides a remote diagnostic system, which includes: a vehicle 101, a first device 102, a server 103, a second device 104, and a diagnostic device 105. Data generated by the diagnostic device 105 is transmitted to the vehicle 101 via the second device 104, the server 103, and the first device 102. Data generated by the vehicle 101 can also be transmitted to the diagnostic device 105 via the first device 102, the server 103, and the second device 104. Furthermore, in this application embodiment, the first device 102 can determine a request-response identifier pair based on the diagnostic request and the corresponding diagnostic response sent by the vehicle 101. The second device 104 stores the request-response identifier pair transmitted by the first device 102 through the server 103 in a preset identifier storage area. When network latency is high, the second device 104 will parse the request identifier from each diagnostic request sent by the diagnostic device 105, and generate a negative response with a negative response code of 0x78 based on the response identifier corresponding to the parsed request identifier obtained in the identifier storage area. This ensures that the diagnostic device 105 can receive the negative response with a negative response code of 0x78, thereby avoiding diagnostic failure caused by excessive network latency.

[0068] The first device 102 and the second device 104 can respectively interact with the vehicle 101 and the diagnostic device 105 through the OBD interface.

[0069] Based on the aforementioned remote diagnostic system, please refer to Figure 2 This application provides a remote diagnostic method, which can be implemented by a first device 102, wherein the first device 102 is communicatively connected to a vehicle 101 and a second device 104, and the second device 104 is communicatively connected to a diagnostic device 105. The remote diagnostic method includes the following steps:

[0070] 201. Receive the first diagnostic request sent by the diagnostic device through the second device, and send the first diagnostic request to the vehicle.

[0071] Upon receiving the first diagnostic request transmitted by the second device 104, a first diagnostic request is sent to the vehicle 101, so that the vehicle 101 returns a corresponding first diagnostic response based on the first diagnostic request. The first diagnostic request is generated by the diagnostic device 105.

[0072] 202. Determine the diagnostic request corresponding to the first diagnostic response based on the response type of the first diagnostic response sent by the vehicle.

[0073] Upon receiving the first diagnostic response from vehicle 101, the response type of the first diagnostic response should be determined first. The response type determines what information each byte obtained from parsing the first diagnostic response is used to identify, and based on the parsed first diagnostic response, the diagnostic request corresponding to the first diagnostic response can be determined, that is, which diagnostic request the first diagnostic response is a response to.

[0074] 203. If the first diagnostic response corresponds to the first diagnostic request, then obtain the first request identifier from the first diagnostic request record and obtain the first response identifier from the first diagnostic response.

[0075] If it is determined based on step 202 that the diagnostic request corresponding to the first diagnostic response is the first diagnostic request, then the first diagnostic request record can be obtained from the diagnostic request record stored in the first device 102, the first request identifier contained in the first diagnostic request can be obtained from the first diagnostic request record, and the first response identifier can be obtained from the first diagnostic response.

[0076] 204. Send a request-response identifier pair to the second device so that the second device stores the request-response identifier pair, wherein the request-response identifier pair includes a first request identifier, a first response identifier, and the association between the two.

[0077] The second device 104 sends a request-response pair including a first request identifier, a first response identifier, and the relationship between the two. The second device 104 stores the request-response identifier pair so that when it receives a diagnostic request containing the first request identifier and the network latency is large, it can replace the negative response with a negative response code of 0x78 based on the first response identifier, thereby extending the response waiting time of the diagnostic device 105.

[0078] The first request identifier is used to identify the request object of the first diagnostic request (i.e., the request identifier of a certain ECU of vehicle 101), and the first diagnostic identifier is used to identify the current diagnostic performed by diagnostic device 105 (i.e., a diagnostic corresponding to the first diagnostic request).

[0079] In this embodiment, after receiving a first diagnostic response from the vehicle 101, the first device 102 can determine the diagnostic request corresponding to the first diagnostic response based on the response type of the first diagnostic response. If the first diagnostic response corresponds to the first diagnostic request, the first request identifier is parsed from the first diagnostic request, and the first response identifier is parsed from the first diagnostic response. After receiving a request-response identifier pair including the first request identifier, the first response identifier, and the association between the two, if the second device 104 receives a diagnostic request including the first request identifier, it can send a negative response with a negative response code of 0x78 to the diagnostic device 105 based on the first request response when the network latency is large. This allows the diagnostic device 105 to wait after receiving the negative response, avoiding diagnostic failures caused by network latency not meeting the vehicle diagnostic requirements.

[0080] In practical applications, the self-learning process (i.e., determining the response identifier corresponding to the request identifier, or the process of determining the request-response identifier pair) will only be applied to request identifiers that do not exist in the preset configuration file, request identifiers whose type is not function addressing, and request identifiers whose first diagnostic request is a UDS diagnostic request. No specific limitations are made here.

[0081] In some specific implementations, after step 204 mentioned above, this application embodiment further includes the following steps, which can be implemented by the second device 104: receiving a request-response identifier pair sent by the first device 102 connected to the vehicle 101 and storing it in the identifier storage area, wherein the request-response identifier pair includes a first request identifier, a first response identifier, and the association between the two; parsing the second diagnostic request sent by the diagnostic device 105 to obtain a second request identifier; if the second request identifier is consistent with the first request identifier, then sending a second diagnostic response including the first response identifier to the diagnostic device 105, wherein the second diagnostic response is a negative response with a negative response code of 0x78.

[0082] Specifically, after receiving the request-response identifier pair, the second device 104 can store the request-response identifier pair in a preset identifier storage area. If the diagnostic device 105 does not receive the first diagnostic response corresponding to the first diagnostic request within a certain time, it will initiate a corresponding retry diagnostic request, where the data requested in the retry diagnostic request is consistent with the data requested in the first diagnostic request. When network latency is high, after receiving the retry diagnostic request sent by the diagnostic device 105, the second device 104 will parse the retry diagnostic request (i.e., the second diagnostic request) to obtain the second request identifier. The second device 104 can search in the identifier storage area to see if the second request identifier exists. If the search finds that the first request identifier matches the second request identifier, it will retrieve the first response identifier from the request-response identifier pair and construct the second diagnostic response based on the first response identifier. The second diagnostic response is a negative response with a negative response code of 0x78. After receiving the second diagnostic response, the diagnostic device 105 will wait for a period of time to avoid diagnostic failures caused by high network latency.

[0083] It is understood that the aforementioned identifier storage area can be located on server 103 or the second device 104, without specific limitations here. In addition, besides storing each request-response identifier sent by the first device 102, the identifier storage area can also be manually configured with request-response identifier pairs, without limitations here.

[0084] In some specific implementations, step 202 can be implemented in the following way: parsing the first diagnostic response to obtain the first diagnostic identifier, and determining whether there is a target historical diagnostic request record including the first diagnostic identifier in the buffer; if there is a target historical diagnostic request record, then determining the diagnostic request corresponding to the target historical diagnostic request record as the diagnostic request corresponding to the first diagnostic response.

[0085] Specifically, the buffer of the first device 102 contains multiple historical diagnostic request records, each containing a diagnostic identifier. Different diagnostic requests can be distinguished based on the diagnostic identifier. Therefore, if a target historical diagnostic request record containing the first diagnostic identifier exists, it means that the target historical diagnostic request record describes the relevant information of the first diagnostic request, that is, the first diagnostic response corresponds to the first diagnostic request.

[0086] Furthermore, depending on the response type, the first diagnostic identifier obtained by parsing the first diagnostic response in the aforementioned steps can be achieved in the following two ways: if the response type is a positive response, then subtract 0x40 from the first byte of the first diagnostic response to obtain the first diagnostic identifier; if the response type is a negative response, then determine the second byte of the first diagnostic response as the first diagnostic identifier.

[0087] Specifically, if the first diagnostic response is positive, the first byte of the corresponding message should be: First Diagnostic Identifier + 0x40. Therefore, subtracting 0x40 from the first byte of the message yields the First Diagnostic Identifier. If the first diagnostic response is positive, the second byte of the corresponding message should be: First Diagnostic Identifier. It should be noted that a negative response here refers to a diagnostic response whose first byte is 7F, meaning a diagnostic response containing any negative response code, and not specifically, but only, a negative response with a negative response code of 0x78.

[0088] Furthermore, after receiving the first diagnostic request sent by the second device 104, the first device 102 may also perform the following methods: receive the first diagnostic request sent by the second device 104 and send the first diagnostic request to the vehicle 101; parse the first diagnostic request to obtain the first request identifier and the first diagnostic identifier; if there is no corresponding historical diagnostic request record in the buffer that matches the first request identifier and the first diagnostic identifier, then add a first diagnostic request record in the buffer. The first diagnostic request record includes the first request identifier, the first diagnostic identifier, and the association between the two.

[0089] Specifically, the request identifier (i.e., the first request identifier) ​​and the diagnostic identifier (i.e., the first diagnostic identifier) ​​are parsed from the first diagnostic request. Then, it is checked whether there is a historical diagnostic request in the cache that includes the first request identifier and the first diagnostic identifier. If not, a new first diagnostic request record should be added to the cache to describe the first diagnostic request.

[0090] Based on the aforementioned embodiments, if a historical diagnostic request record to be deleted is found in the buffer where the corresponding historical request identifier is inconsistent with the first request identifier but the corresponding historical diagnostic identifier is consistent with the first diagnostic identifier, then the historical diagnostic request record to be deleted will be deleted. This ensures that each request-response identifier pair determined by the first device 102 is unique and reliable.

[0091] In some other embodiments, if the first diagnostic request record also includes a first moment, then the embodiments of this application further include the following steps:

[0092] If a historical diagnostic request record to be updated exists in the buffer, and its corresponding historical request identifier matches the first request identifier, its corresponding historical diagnostic identifier matches the first diagnostic identifier, but its corresponding historical time does not match the first time, then the historical time in the historical diagnostic request record to be updated will be updated to the first time. This is to avoid prematurely deleting the historical record to be updated.

[0093] It is understandable that the information items recorded in the historical diagnostic request record are the same as those recorded in the first diagnostic request record (i.e., both include the request time, request identifier, and diagnostic identifier). The only difference is that the historical diagnostic request record is a diagnostic request record added before the first diagnostic request record, which will not be elaborated here.

[0094] Based on the foregoing embodiments, in one specific implementation, to avoid an excessively large buffer, diagnostic request records whose corresponding request time is greater than the current time (the time of execution of timeout deletion) are deleted according to preset timeout deletion conditions, thereby freeing up storage space. The diagnostic request records include first diagnostic request records and / or historical diagnostic request records.

[0095] The remote diagnostic method of this application embodiment is described below in a specific scenario:

[0096] 1. The C-end (i.e., the first device 102, hereinafter the same) sends the self-learning process.

[0097] Step 1: Receive bus data (i.e., the first diagnostic request) transmitted from end B (i.e., the second device 104, hereinafter the same).

[0098] Step 2: Parse the data to obtain the Request CAN ID (i.e., the first request identifier) ​​and SID (i.e., the first diagnostic identifier). Obtain the current timestamp (i.e., the first moment).

[0099] Step 3 sends the data to the vehicle (i.e., vehicle 101, hereinafter the same) bus.

[0100] If the data in step 4 is not UDS diagnostic data, no processing is required, and the process ends.

[0101] Step 4: If the CAN ID is a function-addressable ID, no processing is required, and the process ends.

[0102] Step 4: If the CAN ID is a pair of CAN IDs that have already been saved (either saved in the preset configuration file or in the buffer on the C end), no processing is required, and this process ends.

[0103] Step 5 compares the data with the data in the ID buffer (i.e., the buffer). If there is a record with the same CAN ID and SID, then update the timestamp of that record to the current timestamp.

[0104] Step 5 compares the data with the data in the ID buffer to be processed. If there are records with different CAN IDs but the same SID, then delete the record in the buffer to be processed.

[0105] Step 5 compares the data with the data in the ID buffer to be processed. If there is no record in the buffer that has the same CAN ID and SID, then the CAN ID, SID, timestamp, and the relationship between the three are saved to the ID buffer to be processed.

[0106] 2. C-end receiving self-learning process

[0107] Step 1: Receive vehicle bus data (this is the first diagnostic response).

[0108] Step 2: Parse the data to determine whether the diagnostic response is positive or negative, and obtain the response CAN ID and SID. If it is a positive response, the first byte of the message is the SID corresponding to the diagnostic response + 0x40; if it is a negative response, the second byte of the message is the SID corresponding to the diagnostic response.

[0109] Step 3: Transmit the message to end B.

[0110] If the ID buffer to be processed in step 4 is empty, no processing is performed, and the process ends.

[0111] Step 5: If the SID parsed in Step 2 matches a certain SID in the ID buffer to be processed, then record the CAN ID of the response obtained in Step 2 and delete the corresponding record in the ID buffer to be processed.

[0112] Step 6 saves the response CAN ID and the corresponding request CAN ID recorded in the buffer (lookup based on SID), that is, saves the request response identifier pair.

[0113] Step 7: Send the request response identifier pair to client B.

[0114] 3. Deletion process for timed-out records in the pending ID buffer

[0115] Step 1: Get the current time

[0116] Step 2: Traverse the ID buffer to be processed and delete records whose current time minus the corresponding timestamp is greater than the preset value (preset timeout threshold).

[0117] It should be noted that a pending ID buffer timeout record deletion process can be executed before executing the C-end sending and receiving self-learning processes to delete records that have timed out without a response. Furthermore, this embodiment does not restrict the B-end's flow control handling logic. This embodiment only self-learns paired request CAN IDs and response CAN IDs, and sends the identified paired CAN IDs to the B-end. The B-end processes whether to send the request (negative response with a 0x78 negative code) and when to send the request according to its original logic.

[0118] Please see Figure 3 This application provides a first device 102, which is communicatively connected to a vehicle 101 and a second device 104. The second device 104 is communicatively connected to a diagnostic device 105. The first device 102 includes:

[0119] The receiving unit 301 is used to receive a first diagnostic request sent by the diagnostic device through the second device, and to send the first diagnostic request to the vehicle;

[0120] The determining unit 302 is used to determine the diagnostic request corresponding to the first diagnostic response based on the response type of the first diagnostic response sent by the vehicle.

[0121] The acquisition unit 303 is used to acquire a first request identifier from the first diagnostic request record and a first response identifier from the first diagnostic response if the first diagnostic response corresponds to the first diagnostic request.

[0122] The sending unit 304 is used to send a request-response identifier pair to the second device, so that the second device stores the request-response identifier pair, which includes a first request identifier, a first response identifier, and the association relationship between the two.

[0123] In one specific implementation, the determining unit 302 is specifically used to parse the first diagnostic response to obtain the first diagnostic identifier, and to determine whether there is a target historical diagnostic request record including the first diagnostic identifier in the buffer.

[0124] If a target historical diagnostic request record exists, then the diagnostic request corresponding to the target historical diagnostic request record is determined to be the diagnostic request corresponding to the first diagnostic response.

[0125] In one specific implementation, the determining unit 302 is specifically used to subtract 0x30 from the first byte of the first diagnostic response if the response type is a positive response, to obtain the first diagnostic identifier;

[0126] If the response type is a negative response, then the second byte of the first diagnostic response is determined to be the first diagnostic identifier.

[0127] In one specific implementation, the first device 102 further includes: a new unit;

[0128] The receiving unit 301 is also configured to receive a first diagnostic request sent by the second device and send the first diagnostic request to the vehicle.

[0129] The determining unit 302 is also used to parse the first diagnostic request to obtain the first request identifier and the first diagnostic identifier;

[0130] A new unit is added to the buffer if there is no corresponding historical request record in the buffer that matches the first request record and the corresponding historical diagnostic record that matches the first diagnostic record. The first diagnostic request record includes the first request record, the first diagnostic record, and the relationship between the two.

[0131] In one specific implementation, the first diagnostic request record further includes: a first moment; the historical diagnostic request record includes: a historical moment; and the first device 102 further includes: an update unit.

[0132] The update unit is used to update the historical time in the historical diagnostic request record to the first time if there is a historical request record in the buffer that has the same historical request identifier as the first request identifier, the same historical diagnostic identifier as the first diagnostic identifier, and a different historical time than the first time.

[0133] In one specific implementation, each diagnostic request record further includes: the request time, and the first device 102 further includes: a deletion unit;

[0134] The deletion unit is used to delete a historical diagnostic request record to be deleted if there is a historical request record in the buffer whose corresponding historical request identifier is inconsistent with the first request identifier and whose corresponding historical diagnostic identifier is consistent with the first diagnostic identifier.

[0135] In one specific implementation, the deletion unit is further used to delete diagnostic request records in the buffer whose corresponding request time meets the preset timeout deletion conditions. The request time includes a first time and / or a historical time, and the diagnostic request record includes a first diagnostic request record and / or a historical diagnostic request record.

[0136] Please see Figure 4 This application provides a second device 104, which is connected to a diagnostic device 105. The second device 104 includes:

[0137] The receiving unit 401 is used to receive a request-response identifier pair sent by a first device connected to the vehicle and store it in the identifier storage area. The request-response identifier pair includes a first request identifier, a first response identifier, and the association relationship between the two.

[0138] The parsing unit 402 is used to parse the second diagnostic request sent by the diagnostic device to obtain the second request identifier;

[0139] The sending unit 403 is configured to send a second diagnostic response, including a first response identifier, to the diagnostic device if the second request identifier is consistent with the first request identifier. The second diagnostic response is a negative response with a negative response code of 0x78.

[0140] Figure 5 This is a schematic diagram of a remote diagnostic device provided in an embodiment of this application. The remote diagnostic device 500 may include one or more central processing units (CPUs) 501 and a memory 505, in which one or more applications or data are stored.

[0141] The memory 505 can be volatile or persistent storage. The program stored in the memory 505 can include one or more modules, each module including a series of instruction operations on the remote diagnostic device. Furthermore, the central processing unit 501 can be configured to communicate with the memory 505 and execute the series of instruction operations in the memory 505 on the remote diagnostic device 500.

[0142] The remote diagnostic device 500 may also include one or more power supplies 502, one or more wired or wireless network interfaces 503, one or more input / output interfaces 504, and / or one or more operating systems, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0143] The central processing unit 501 can perform the aforementioned... Figures 1 to 4 The operations performed by the first device 102, vehicle 101, server 103, second device 104 and / or diagnostic device 105 in the illustrated embodiment will not be described in detail here.

[0144] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0145] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0146] 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 units can be selected to achieve the purpose of this embodiment according to actual needs.

[0147] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0148] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0149] This application also provides a computer program product containing instructions that, when run on a computer, cause the computer to perform the remote diagnostic method described above.

Claims

1. A remote diagnostic method, characterized in that, Applied to a first device and a second device, the first device is communicatively connected to both the vehicle and the second device, and the second device is communicatively connected to a diagnostic device. The remote diagnostic method corresponding to the first device includes: Receive the first diagnostic request sent by the diagnostic device through the second device, and send the first diagnostic request to the vehicle; Based on the response type of the first diagnostic response sent by the vehicle, determine the diagnostic request corresponding to the first diagnostic response; If the first diagnostic response corresponds to the first diagnostic request, then the first request identifier is obtained from the first diagnostic request record, and the first response identifier is obtained from the first diagnostic response; The second device sends a request-response identifier pair to the second device, such that the second device stores the request-response identifier pair, which includes the first request identifier, the first response identifier, and the association between the two; wherein, the second device is configured to parse the second diagnostic request sent by the diagnostic device to obtain the second request identifier; the second device is further configured to, if the second request identifier is consistent with the first request identifier, send a second diagnostic response including the first response identifier to the diagnostic device, wherein the second diagnostic response is a negative response with a negative response code of 0x78.

2. The method according to claim 1, characterized in that, The step of determining the diagnostic request corresponding to the first diagnostic response includes: Parse the first diagnostic response to obtain the first diagnostic identifier, and determine whether there is a target historical diagnostic request record including the first diagnostic identifier in the buffer; If the target historical diagnostic request record exists, then the diagnostic request corresponding to the target historical diagnostic request record is determined to be the diagnostic request corresponding to the first diagnostic response.

3. The method according to claim 2, characterized in that, The process of parsing the first diagnostic response to obtain the first diagnostic identifier includes: If the response type is a positive response, then subtract 0x40 from the first byte of the first diagnostic response to obtain the first diagnostic identifier; If the response type is a negative response, then the second byte of the first diagnostic response is determined to be the first diagnostic identifier.

4. The method according to claim 1, characterized in that, The method further includes: Receive the first diagnostic request sent by the second device, and send the first diagnostic request to the vehicle; Parse the first diagnostic request to obtain the first request identifier and the first diagnostic identifier; If there is no historical diagnostic request record in the buffer that has the same historical request identifier as the first request identifier and the same historical diagnostic identifier as the first diagnostic identifier, then a new first diagnostic request record is added to the buffer. The first diagnostic request record includes the first request identifier, the first diagnostic identifier, and the relationship between the two.

5. The method according to claim 4, characterized in that, The first diagnostic request record further includes: a first moment; the historical diagnostic request record includes: a historical moment; the method further includes: If there is a historical diagnostic request record in the buffer that has the same historical request identifier as the first request identifier, the same historical diagnostic identifier as the first diagnostic identifier, and a different historical time from the first time, then the historical time in the historical diagnostic request record to be updated will be updated to the first time.

6. The method according to claim 4, characterized in that, The method further includes: If there is a historical diagnostic request record to be deleted in the buffer whose corresponding historical request identifier is inconsistent with the first request identifier and whose corresponding historical diagnostic identifier is consistent with the first diagnostic identifier, then the historical diagnostic request record to be deleted will be deleted.

7. The method according to claim 4, characterized in that, Each diagnostic request record also includes: the request time, and the method further includes: Delete diagnostic request records in the buffer whose corresponding request time meets the preset timeout deletion condition. The request time includes a first time and / or a historical time. The diagnostic request record includes the first diagnostic request record and / or a historical diagnostic request record.

8. A remote diagnostic device, characterized in that, include: Central processing unit, memory, and input / output interfaces; The memory is either a short-term storage memory or a persistent storage memory; The central processing unit is configured to communicate with the memory and execute instructions in the memory to perform the method of any one of claims 1 to 7.

9. A computer storage medium, characterized in that, The computer storage medium stores instructions that, when executed on the computer, cause the computer to perform the method as described in any one of claims 1 to 7.

10. A computer program product containing instructions, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 1 to 7.

Images