Vehicle diagnosis method and device, electronic equipment and storage medium

Abstract

Embodiments of the present application disclose a vehicle diagnosis method and device, electronic equipment and a storage medium. The method comprises the following steps: before diagnosing an electronic control unit of a target vehicle, sending a first request message to a target interface, the first request message being used to obtain a communication state between the target interface and the electronic control unit; obtaining a first response message of the target interface to the first request message; if the first response message indicates that the communication state is a second communication state, sending a third request message to the target interface, the third request message being used to convert the communication state from the second communication state to a first communication state; obtaining a third response message of the target interface to the third request message; and if the third response message indicates that the conversion result is the first communication state, sending a fourth request message to the target interface, the fourth request message being used to diagnose the electronic control unit. By using the embodiments of the present application, the diagnosis efficiency can be improved when diagnosing a vehicle.

Description

Technical Field

[0001] This invention relates to the field of vehicle technology, and more particularly to vehicle diagnostic methods, devices, electronic equipment, and storage media. Background Technology

[0002] During use, diagnostic equipment may malfunction due to unstable power supply, static electricity, interference, software issues, or other reasons.

[0003] However, when diagnostic equipment disconnects for unknown reasons, it must be restarted and manually reconnected before vehicle fault diagnosis can be performed, which results in low diagnostic efficiency. Summary of the Invention

[0004] To address the aforementioned problems, embodiments of the present invention provide a vehicle diagnostic method, apparatus, electronic device, and storage medium, which can improve diagnostic efficiency when diagnosing vehicles.

[0005] In a first aspect, embodiments of the present invention provide a vehicle diagnostic method applied to a diagnostic module of a diagnostic device, wherein the diagnostic device further includes a target interface connected to a target vehicle; the method includes:

[0006] Before diagnosing the electronic control unit of the target vehicle, a first request message is sent to the target interface. The first request message is used to obtain the communication status between the target interface and the electronic control unit.

[0007] Obtain the first response message from the target interface in response to the first request message, wherein the first response message is used to reflect the communication status;

[0008] If the first response message indicates that the communication state is the first communication state, a second request message is sent to the target interface. The second request message is used to diagnose the electronic control unit.

[0009] If the first response message indicates that the communication state is the second communication state, a third request message is sent to the target interface, the third request message being used to change the communication state from the second communication state to the first communication state;

[0010] Obtain the third response message from the target interface in response to the third request message, wherein the third response message is used to reflect the result of the communication state transition;

[0011] If the third response message indicates that the conversion result is the first communication state, a fourth request message is sent to the target interface. The fourth request message is used to diagnose the electronic control unit.

[0012] Secondly, embodiments of the present invention provide a vehicle diagnostic device, which is applied to a diagnostic module of a diagnostic device. The diagnostic device further includes a target interface connected to a target vehicle. The device includes a first processing unit and a second processing unit.

[0013] The first processing unit is configured to send a first request message to the target interface before diagnosing the electronic control unit of the target vehicle. The first request message is used to obtain the communication status between the target interface and the electronic control unit.

[0014] The second processing unit is configured to obtain a first response message from the target interface in response to the first request message, wherein the first response message is used to reflect the communication status;

[0015] If the first response message indicates that the communication state is the first communication state, a second request message is sent to the target interface. The second request message is used to diagnose the electronic control unit.

[0016] If the first response message indicates that the communication state is the second communication state, a third request message is sent to the target interface, the third request message being used to change the communication state from the second communication state to the first communication state;

[0017] Obtain the third response message from the target interface in response to the third request message, wherein the third response message is used to reflect the result of the communication state transition;

[0018] If the third response message indicates that the conversion result is the first communication state, a fourth request message is sent to the target interface. The fourth request message is used to diagnose the electronic control unit.

[0019] Thirdly, embodiments of the present invention provide an electronic device, the electronic device including a processor and a memory, the processor being connected to the memory, the memory being used to store a computer program, and the processor being used to execute the computer program stored in the memory, so that the electronic device performs the method as described in the first aspect.

[0020] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program that is executed by a processor to implement the method described in the first aspect.

[0021] Fifthly, embodiments of this application provide a computer program product, the computer program product including a non-transitory computer-readable storage medium storing a computer program, the computer being operable to perform the method as described in the first aspect.

[0022] Implementing the embodiments of this application has the following beneficial effects:

[0023] In this embodiment, before diagnosing the electronic control unit (ECU) of the target vehicle, a first request message is sent to the target interface. This first request message is used to obtain the communication status between the target interface and the ECU, and to obtain a first response message from the target interface to the first request message. The first response message reflects the communication status. If the first response message indicates a first communication status, a second request message is sent to the target interface. This second request message is used to diagnose the ECU; that is, if the communication status is normal, the ECU is directly diagnosed. If the first response message indicates a second communication status, a third request message is sent to the target interface. The message is used to switch the communication state from the second communication state to the first communication state and obtain the third response message from the target interface in response to the third request message. The third response message reflects the result of the communication state switch. If the third response message indicates that the switch result is the first communication state, a fourth request message is sent to the target interface. The fourth request message is used to diagnose the electronic control unit. That is, when the communication state is abnormal, the communication state is switched first through the third request message, and the electronic control unit is diagnosed when the communication state is switched back to normal. In this way, unlike traditional manual intervention, the communication state can be automatically detected and the abnormality can be resolved when the communication state is abnormal, and the communication state can be automatically restored, thus improving the diagnostic efficiency. Attached Figure Description

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

[0025] Figure 1 This is a schematic diagram of the architecture of a vehicle diagnostic system provided in an embodiment of this application;

[0026] Figure 2 This is a modular schematic diagram of a diagnostic app provided in an embodiment of this application;

[0027] Figure 3 This is a flowchart of a vehicle diagnostic method provided in an embodiment of this application;

[0028] Figure 4 This is a communication diagram illustrating a diagnostic method provided in an embodiment of this application;

[0029] Figure 5This is a communication diagram illustrating a re-verification method provided in an embodiment of this application;

[0030] Figure 6 This is a communication diagram illustrating multiple verifications in the first communication stage provided in an embodiment of this application;

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

[0032] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0034] The terms "first," "second," "third," and "fourth," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or modules is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other steps or modules inherent to these processes, methods, products, or devices.

[0035] In this document, the term "embodiment" means that a particular feature, result, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0036] The following describes the relevant content, concepts, technical issues, technical solutions, and beneficial effects involved in the embodiments of this application.

[0037] First, let me explain some of the technical terms used in this application:

[0038] Vehicle Communication Interface (VCI): It typically takes the form of a Bluetooth connector box.

[0039] Electronic Control Unit (ECU): This is the core control system of a vehicle, equivalent to the "brain" of the car. It is responsible for processing sensor data, controlling the operation of systems such as the engine and transmission, and optimizing the driving experience.

[0040] Diagnostic application (App): An application used for diagnosis on a diagnostic device.

[0041] See Figure 1 , Figure 1 This is a schematic diagram of the architecture of a vehicle diagnostic system provided in an embodiment of this application. The vehicle diagnostic system includes a diagnostic device and an electronic control unit (ECU). The diagnostic device includes a diagnostic module and a target interface. The diagnostic module interacts with the ECU through the target interface; for example, the diagnostic module sends a request to the target interface, and the target interface responds to the diagnostic module. The target interface is an intelligent interface with data processing capabilities, used for assembling and unpacking data from the diagnostic app and the ECU, respectively.

[0042] Further, see Figure 2 , Figure 2 This is a modular schematic diagram of a diagnostic app provided in an embodiment of this application. The diagnostic module can be a diagnostic app for a diagnostic device. This diagnostic app has a pre-installed vehicle fault diagnosis module responsible for configuring the functions of each ECU in the vehicle. The diagnostic app configures the list of ECUs for vehicle fault diagnosis and the functions performed by each ECU, such as writing VIN, writing configuration, clearing fault codes, reading fault codes, and other ECU function sets. The diagnostic app also has a pre-installed hardware detection module responsible for initializing the diagnostic device, identifying the device type, and switching diagnostic modes.

[0043] It should be noted that the vehicle diagnostic method provided in this application embodiment is applied to the diagnostic module of a diagnostic device, and the diagnostic device also includes a target interface, which is connected to a target vehicle.

[0044] The main reason diagnostic equipment cannot diagnose vehicle faults is that the VCI (Vehicle Communication Interface) fails to communicate with the vehicle, resulting in no response from the ECUs when VCI diagnostic commands are sent. Therefore, when diagnosing each ECU in the vehicle, the diagnostic app first checks the communication commands with the VCI, that is, it identifies the device type. The diagnostic app then judges the response result. If the VCI's response data is not 0x7F, it indicates that the communication is normal, and the ECU fault is checked. If the response is 0x7F, it indicates that the diagnostic app and the VCI have lost communication.

[0045] See Figure 3 , Figure 3This is a flowchart illustrating a vehicle diagnostic method provided in an embodiment of this application. The vehicle diagnostic method provided in this application includes, but is not limited to, the following steps:

[0046] Step S101: Before diagnosing the electronic control unit of the target vehicle, send a first request message to the target interface;

[0047] The first request message is used to obtain the communication status between the target interface and the electronic control unit;

[0048] Step S102: Obtain the first response message from the target interface to the first request message;

[0049] The first response message is used to reflect the communication status;

[0050] Step S103: If the first response message indicates that the communication status is the first communication status, send a second request message to the target interface;

[0051] The second request message is used to diagnose the electronic control unit;

[0052] Step S104: If the first response message indicates that the communication status is the second communication status, send a third request message to the target interface;

[0053] The third request message is used to change the communication state from the second communication state to the first communication state.

[0054] Step S105: Obtain the third response message from the target interface in response to the third request message;

[0055] The third response message is used to reflect the result of the communication state transition;

[0056] Step S106: If the third response message indicates that the conversion result is the first communication state, send a fourth request message to the target interface;

[0057] The fourth request message is used to diagnose the electronic control unit.

[0058] Specifically, the target interface is VCI, which serves as an intermediate node connecting the diagnostic module and the ECU. The diagnostic module can be a diagnostic app on a diagnostic device. The first communication state reflects normal communication between VCI and ECU, for example, the ECU is in a diagnostic state and supports diagnostic services. The second communication state reflects abnormal communication between VCI and ECU, for example, the ECU is in sleep mode and does not respond to diagnostic commands. The message format can include fields such as sub-functions and data segments.

[0059] In one possible embodiment, before diagnosing the electronic control unit (ECU) of the target vehicle, a first request message is sent to the target interface. This first request message is used to obtain the communication status between the target interface and the ECU. Specifically, the diagnostic module sends the first request message to the VCI (Vehicle Interface Council). Its core function is to query the real-time communication link status between the VCI and the target ECU. Taking the UDS protocol as an example, the first request message can be [0x3E, 0x00], where Service ID = 0x3E and Sub-function = 0x00, meaning querying the ECU communication status. Further, additional parameters include the CANID of the target ECU, such as 0x710, to specify the ECU being queried and avoid interfering with other nodes. The current status of the ECU, such as whether the ECU is ready or supports diagnostics, is obtained indirectly through the VCI, avoiding invalid communication caused by directly sending diagnostic commands.

[0060] In one possible embodiment, the target interface obtains a first response message to the first request message, which reflects the communication status. After receiving the first request message, the VCI sends a status probe frame to the target ECU, such as [0x02, 0x10, 0x01], and forwards the ECU's response to the diagnostic module, forming a first response message. If the first response message is [0x7E, 0x00, 0x01], it indicates a positive response, with 0x01 indicating that the ECU is ready, thus determining the first communication status. If the first response message is [0x7F, 0x3E, 0x22], it indicates a negative response, with 0x22 indicating that the ECU is not ready, thus determining the second communication status. The VCI acts as an intermediary to forward status queries, and the diagnostic module directly determines whether the ECU is diagnosable through the response code, without directly interacting with the ECU. Optionally, if the first response message is not received within a preset response time, the communication status can also be determined to be the second communication status. The preset response time can be 300ms, 400ms, 500ms, etc.

[0061] In one possible embodiment, if the first response message indicates a first communication state, a second request message is sent to the target interface. This second request message is used to diagnose the electronic control unit (ECU). The diagnostic module sends the second request message to the VCI, directly triggering diagnostic functions for the ECU, such as reading fault codes and data streams. Taking reading fault codes as an example, the second request message could be [0x19, 0x02], where Service ID = 0x19 and Subfunction = 0x02, meaning "read the current fault code." Further, based on the CANID, the VCI directly forwards the message to the target ECU and sends the ECU's diagnostic response back to the diagnostic module. If the ECU is in normal operating mode, such as after vehicle ignition, the ECU is activated and can directly respond to diagnostic commands.

[0062] In one possible embodiment, if the first response message indicates a second communication state, a third request message is sent to the target interface. This third request message is used to change the communication state from the second to the first communication state. The diagnostic module sends the third request message to the VCI, and its core function is to trigger the VCI to perform a state transition operation on the ECU, such as restarting the VCI or activating the VCI's diagnostic mode.

[0063] In one possible embodiment, a third response message from the target interface to the third request message is obtained. This third response message reflects the communication state transition result. If the third response message indicates that the transition result is a first communication state, a fourth request message is sent to the target interface. This fourth request message is used to diagnose the electronic control unit. The fourth request message can be identical to the second request message, or it can differ partially depending on the diagnostic time. For example, whether a request message for the same diagnostic function differs due to time depends on whether the message contains dynamic parameters strongly correlated with time. If it is a basic diagnostic service without timestamps, dynamic keys, etc., the message is unrelated to time and there is no difference. However, if it involves timestamps, dynamic security verification, retransmission counters, etc., the message will contain different parameters due to time changes, thus creating a difference.

[0064] In this embodiment, the communication status between the VCI and the ECU is first confirmed through a first request message, avoiding the direct sending of diagnostic commands to the ECU with abnormal communication status, thus reducing bus redundancy data. In the traditional process, if the ECU does not respond, manual operation is required, such as restarting the vehicle or plugging and unplugging the VCI. In this embodiment, the wake-up activation operation is automatically executed through a third request message, which improves the processing efficiency when the communication status is abnormal, thereby improving the diagnostic efficiency.

[0065] Optionally, the third request message includes a hardware information acquisition message, a connection reset message, a software verification message, and a mode switching message. In step S104, sending the third request message to the target interface may include the following steps:

[0066] Step S201: Send a hardware information acquisition message to the target interface. The hardware information acquisition message is used to acquire the hardware information of the target interface.

[0067] Step S202: Receive the second hardware sub-response message from the target interface for the hardware information acquisition message;

[0068] Step S203: If the second hardware sub-response message indicates that the hardware information was successfully obtained, a connection reset message is sent to the target interface. The connection reset message is used to establish a connection with the target interface.

[0069] Step S204: Receive the second reset sub-response message from the target interface in response to the connection reset message;

[0070] Step S205: If the second reset sub-response message indicates that the target interface has been successfully reset, a software verification message is sent to the target interface. The software verification message is used to verify the communication status of the target interface.

[0071] Step S206: Receive the second verification sub-response message from the target interface in response to the software verification message;

[0072] Step S207: If the second verification sub-response message indicates that the target interface verification is successful, a mode switching message is sent to the target interface. The mode switching message is used to switch the working mode of the target interface to the diagnostic mode. The diagnostic mode is used to diagnose the target vehicle.

[0073] In one possible embodiment, a hardware information acquisition message is sent to the target interface to acquire the hardware information of the target interface. The target interface then receives a second hardware sub-response message in response to the hardware information acquisition message. The hardware information acquisition message is a device information query instruction sent by the diagnostic app to the VCI, based on the UDS protocol extension service. The format of the hardware information acquisition message can be [0x22, 0xF1, 0x90], where Service ID = 0x22 and DID = 0xF190, meaning "read VCI hardware information". When the VCI responds, if it is a positive response, the format of the second hardware sub-response message can be [0x62, 0xF1, 0x90, 0x01, 0x02, ...], where 0x62 is the positive response code for the 0x22 service, the data segment contains the sequence number (e.g., 0x53 0x4E 0x31 0x32 0x33, indicating SN123), the software version number (e.g., 0x01 0x02 0x03, indicating V1.2.3), and the chip ID (e.g., 0xA1 0xB2 0xC3, indicating a unique hardware identifier); if it is a negative response, the format of the second hardware sub-response message can be [0x7F, 0x22, 0x13], where 0x7F is the negative response prefix, and 0x13 indicates that the request is out of range, meaning that the VCI does not support the query. Furthermore, if a positive response is received and the data segment contains the complete serial number, version number, and chip ID, the hardware information acquisition is considered successful; otherwise, if a negative response or missing data is received, the diagnostic process is considered a failure and exits.

[0074] In one possible embodiment, if the second hardware sub-response message indicates successful acquisition of hardware information, a connection reset message is sent to the target interface. The connection reset message is used to establish a connection with the target interface and receive the second reset sub-response message from the target interface in response to the connection reset message. The connection reset message is a VCI restart and communication parameter reset instruction. Based on the UDS session control service, the format of the connection reset message can be [0x11, 0x01], where service ID = 0x11, sub-function = 0x01, meaning VCI soft reset. When the VCI responds, if it is a positive response, the format of the second reset sub-response message can be [0x51, 0x01], where 0x51 is the positive response code of the 0x11 service, indicating that the VCI has been restarted, clearing cached error parameters, such as residual CAN baud rate, ECU address, and resetting the USB or Bluetooth communication port; if it is a negative response, the format of the second reset sub-response message can be [0x7F, 0x11, 0x24], where 0x24 indicates that the request was rejected, such as when the VCI is in a hardware locked state. Furthermore, if a positive response is received, the VCI reset is considered successful and the basic communication link is restored to normal; otherwise, the process is considered a failure and the diagnostic process is exited.

[0075] In one possible embodiment, if the second reset sub-response message indicates that the target interface has been successfully reset, a software verification message is sent to the target interface. The software verification message is used to verify the communication status of the target interface. The second verification sub-response message of the target interface in response to the software verification message is received. The software verification message is a protocol matching verification instruction between the VCI diagnostic software and the App. The format of the software verification message can be [0x3E, 0x01, 0x02, 0x03], where Service ID = 0x3E, Sub-function = 0x01, and the data segment contains the protocol version supported by the App (0x02, 0x03, V2.3). When the VCI responds, if it is a positive response, the format of the second verification sub-response message can be [0x7E, 0x01, 0x02, 0x03], where 0x7E is the positive response code for the 0x3E service, and the data segment contains the protocol version supported by the VCI, which matches the App version, indicating protocol compatibility. If it is a negative response, the format of the second verification sub-response message can be [0x7F, 0x3E, 0x31], where 0x31 indicates version incompatibility, such as VCI only supporting V1.0 while the App requires V2.3. If a positive response is received and the protocol versions match, the VCI verification is considered successful; otherwise, it is considered a failure, and the diagnostic process exits.

[0076] In one possible embodiment, if the second verification sub-response message indicates that the target interface verification is successful, a mode switching message is sent to the target interface. The mode switching message is used to switch the working mode of the target interface to the diagnostic mode, which is used to diagnose the target vehicle. The mode switching message is an instruction for the VCI to switch from standby mode, Ethernet mode, or remote diagnostic mode to diagnostic mode. Based on the UDS function activation service, the format of the mode switching message can be [0x85, 0x01], where the service ID = 0x85 and the sub-function = 0x01, meaning that the diagnostic mode is activated. When the VCI responds, if it is a positive response, it can reply with [0xC5, 0x01], where 0xC5 is the positive response code of the 0x85 service, indicating that the VCI has loaded the vehicle protocol configuration, such as the CANFD baud rate and the ECU address table, and enabled the diagnostic data transmission and reception function; if it is a negative response, it can reply with [0x7F, 0x85, 0x2F], where 0x2F indicates that the condition is not met, such as the VCI has not completed hardware initialization. If a positive response is received, the diagnostic mode is considered successfully entered; otherwise, the diagnostic mode is considered to have failed and the diagnostic mode is exited.

[0077] In this embodiment, hardware information acquisition first confirms the physical existence and communicability of the VCI, such as a valid serial number, undamaged VCI, and matching chip ID, ruling out underlying issues like broken physical connections. A connection reset clears residual error states from previous anomalies, such as cached incorrect baud rates, ensuring communication parameters return to default values ​​and resolving communication failures. Software verification verifies the protocol compatibility between the VCI diagnostic software and the App, such as version matching and consistent function support, avoiding instruction parsing errors caused by software incompatibility. Finally, mode switching activates the VCI's diagnostic function, ensuring it can forward diagnostic commands to the ECU. If hardware information acquisition fails, it indicates the VCI is not properly connected or is damaged, eliminating the need for subsequent reset or verification steps. By exiting directly when preset conditions are not met, this process reduces unnecessary operations, improves diagnostic efficiency, and avoids resource waste.

[0078] Optionally, after obtaining the first response message from the target interface to the first request message in step S102, the following steps may also be included:

[0079] Step S301: Parse the first response message and determine the reply code. The reply code is used to reflect the device type of the target interface.

[0080] Step S302: If the response code is inconsistent with the preset code, determine the communication status as the first communication status;

[0081] Step S303: If the reply code matches the preset code, determine the communication state as the second communication state.

[0082] Specifically, the first response message structure includes a basic communication status code and a device type response code. For example, based on the UDS protocol, the format is [Response Identifier, Response Code, Status Parameter], such as [0x7E, 0x02, 0x01]. The response code occupies 1-2 bytes and is a device type identifier preset by the VCI hardware or firmware, used to distinguish the VCI model, supported protocol types, or functional levels. For example, 0x01 represents a diagnostic VCI supporting CANFD, and 0x03 represents a basic VCI that only supports the LIN bus. The preset code is a predefined incompatible or abnormal device identifier in the diagnostic app, usually indicating a VCI type that cannot support the current target ECU diagnosis. For example, if the target ECU requires the CANFD protocol, the preset code would include 0x03, indicating only LIN support, and 0x05, indicating support for older CAN protocols, etc.

[0083] In one possible embodiment, the response code is first extracted. The diagnostic app parses the first response message and extracts the response code from a fixed byte position, such as the second byte. For example, if the first response message is [0x7E, 0x02, 0x01], then the response code = 0x02. Then, the response code is compared with a preset code. If the preset code list is [0x03, 0x05, 0x07], it indicates that the VCI type of the target ECU is not supported. Taking a response code of 0x02 as an example, it is not in the preset code list, and the response code is inconsistent with the preset code, indicating a first communication state where the VCI type is compatible and the basic conditions for communication with the ECU are met. Taking a response code of 0x03 as an example, it is in the preset code list, and the response code is consistent with the preset code, indicating a second communication state where the VCI type is incompatible and the basic conditions for communication with the ECU are missing.

[0084] In a specific embodiment, assuming the target ECU is an engine ECU supporting the CANFD protocol, the diagnostic app's preset codes are 0x03, indicating that only LIN bus-supported VCIs are supported, and 0x05, indicating that only basic CAN-supported VCIs are supported. If the VCI is a diagnostic device supporting CANFD, its response code is 0x01, which is not in the preset code list, indicating the first communication state, and diagnostic commands can be sent directly. If the VCI is an older device that only supports basic CAN, its response code is 0x05, which is in the preset code list, indicating the second communication state, requiring a state change, such as prompting to replace the VCI or activate compatibility mode.

[0085] In this embodiment of the application, the communication status is determined by the response code, which improves the accuracy of communication status determination.

[0086] Optionally, after sending the fourth request message to the target interface in step S106, the following steps may also be included:

[0087] Step S401: If the target interface does not receive a fourth response message for the third request message within the target response time, a fifth request message is sent to the target interface. The fifth request message is used to obtain the communication status between the target interface and the electronic control unit again.

[0088] Step S402: Obtain the fifth response message from the target interface in response to the fifth request message. The fifth response message is used to reflect the communication status again.

[0089] Step S403: If the fifth response message indicates that the communication state is the second communication state, send a sixth request message to the target interface. The sixth request message is used to change the communication state from the second communication state to the first communication state again.

[0090] Step S404: Obtain the sixth response message from the target interface in response to the sixth request message. The sixth response message is used to reflect the result of the communication state transition again.

[0091] Step S405: If the sixth response message indicates that the communication status is the first communication status, a seventh request message is sent to the target interface. The seventh request message is used to diagnose the electronic control unit again.

[0092] Specifically, the target response time can be the waiting response time preset by the diagnostic app, or different target response times can be set according to different diagnostic functions of the electronic control unit. If no response is received after this time, it is judged as a timeout. The fourth request message is used to execute diagnostic instructions for the ECU, such as reading fault codes. The fourth request timeout may be due to temporary communication interference, such as bus conflict, or state rollback, such as the VCI changing from the first communication state to the second communication state again. It needs to be distinguished and handled through the retry mechanism.

[0093] In one possible embodiment, if a fourth response message is not received after the target response timeout period following the sending of the fourth request message, a fourth request timeout is detected, and a fifth request message is sent to re-check the status. The fifth request message has the same function as the first request message, used to query the communication status between the VCI and the ECU. This determines whether the timeout is due to temporary interference or a status rollback, avoiding blind retries for diagnosis.

[0094] In one possible embodiment, the fifth response message is parsed to determine the current communication state. The fifth response message is the status response of the VCI forwarding the ECU, and its format can be consistent with the first response message. Further, if the fifth response message indicates that the communication state is the second communication state, a sixth request message is sent to change the state again. The sixth request message has the same function as the third request message, both of which change the communication state from the second communication state to the first communication state. It includes four sub-messages used to perform VCI hardware information acquisition, connection reset, software verification, and mode switching to reactivate the communication link between the VCI and the ECU and fix the state rollback problem.

[0095] In one possible embodiment, the sixth response message is the final result of the VCI state transition, which is a summary of all sub-responses. Parsing the sixth response message confirms the state transition result. If it is a positive response, the mode switch is successful and the state has been restored to the first communication state. If it is a negative response, the mode switch fails and the state transition fails. In this case, the user needs to be prompted to check the hardware.

[0096] Furthermore, if the sixth response message indicates that the communication state has been restored to the first communication state and the transition is successful, a seventh request message is sent to perform the diagnosis again. The definition of the seventh request message can be consistent with the content of the fourth request message, or the format and content of the seventh request message can be determined according to the storage amount of the response data corresponding to the fourth request message.

[0097] In this embodiment, the communication status is identified and determined not only before diagnosing the electronic control unit, but also during the diagnosis process if no corresponding response message is received, so as to indicate whether to continue waiting for the response message or to restart the VCI and re-diagnose.

[0098] Optionally, before sending the fifth request message to the target interface in step S401, the following steps may also be included:

[0099] Step S501: Based on the fourth request message, determine the target diagnostic function that the electronic control unit needs to perform;

[0100] Step S502: Based on the target diagnostic function, predict the first execution time of the electronic control unit;

[0101] Step S503: Based on the time interval between the first request message and the first response message, predict the second execution duration corresponding to the fourth request message. The time interval is the duration between the sending time of the first request message and the receiving time of the first response message.

[0102] Step S504: Determine the target response time based on the first execution time and the second execution time.

[0103] Specifically, the fourth request message is used to trigger the ECU to execute a specific diagnostic function. The target diagnostic function is the ECU operation corresponding to the fourth request message, such as reading fault codes, writing configuration parameters, and firmware updates. The first execution time is the time required for the ECU to execute the target diagnostic function itself, excluding communication delay. The second execution time is the communication delay from when the fourth request message is sent to the ECU to receive a response, including VCI forwarding, bus transmission, and ECU processing preparation time. The target response time is the maximum allowed time for the diagnostic app to wait for the fourth response message, which must cover the ECU execution time and communication delay time to avoid misjudgment of timeout.

[0104] In one possible embodiment, the diagnostic app parses the service ID and sub-function of the fourth request message to locate the corresponding diagnostic function. For example, if the fourth request message is [0x19, 0x02], with service ID = 0x19 indicating a fault code service and sub-function = 0x02, then the target diagnostic function is to read the current fault code; if the message is [0x31, 0x01], with service ID = 0x31 indicating a firmware refresh service and sub-function = 0x01, then the target diagnostic function is to start firmware data transmission.

[0105] Furthermore, based on the complexity of the target diagnostic function and combined with historical data or protocol specifications, the theoretical execution time of the ECU for this function is preset. For example, if the target diagnostic function is reading fault codes, the complexity is low, and since it only requires querying the ECU's internal fault register, the first execution time can be 50-200ms; if the target diagnostic function is reading real-time data streams, such as engine speed, the complexity is medium, and since the ECU needs to collect sensor data in real time, the first execution time can be 200-500ms; if the target diagnostic function is firmware updating, the complexity is high, and since it requires receiving data, verification, and chip erasure / writing, the first execution time can be 10s-5min. The first execution time can be dynamically adjusted based on the historical execution data of the corresponding ECU. If the diagnostic app has recorded the historical execution time of the ECU, such as the last execution of the same function taking 300ms, the historical average value will be used first.

[0106] Furthermore, within the same diagnostic session, the communication link between the VCI and ECU, such as the CAN bus load and VCI forwarding efficiency, is typically stable, and the delay of the first request can represent the typical delay of the current link. The time interval between the sending of the first request message and the receiving of the first response message is calculated and denoted as T1. This time interval is used to estimate the communication delay of the fourth request, and the second execution duration is denoted as T2. For example, if the first request is sent at 10:00:00.000 and the first response is received at 10:00:00.120, then T1 = 120ms. Since the communication path of the fourth request is the same as that of the first request, both being forwarded to the ECU via VCI, the predicted T2 ≈ T1 = 120ms. In addition, a ±50ms redundancy can be added to this to address bus load fluctuations.

[0107] In one possible embodiment, the target response time = first execution time + second execution time + redundancy time, where the redundancy time is typically 20% of the sum of the first two. For example, if the target diagnostic function is reading fault codes: first execution time = 200ms, second execution time = 120ms, then the target response time = 200 + 120 + (200 + 120) × 20% = 320 + 64 = 384ms, which can be further rounded up to 400ms. If the target diagnostic function is firmware refresh: first execution time = 3min, or 180000ms, second execution time = 120ms, then the target response time = 180000 + 120 + (180000 + 120) × 20% ≈ 180120 + 36024 = 216144ms, approximately 3.6 minutes.

[0108] In this embodiment, since traditional diagnostic processes often use a fixed response time, but the actual time required for different diagnostic functions varies greatly, the dynamically calculated target response time can be adapted as needed, making timeout judgment more accurate, and combined with real-time communication status, it can adapt to link fluctuations.

[0109] Optionally, the first request message corresponds to n first target response messages, and the first response message includes m first sub-response messages, where m is less than or equal to n. In step S405, before sending the seventh request message to the target interface, the following steps may also be included:

[0110] Step S601: Based on n first target response messages and m first sub-response messages, determine the first message packet loss rate and the first message packet loss duration of the first response message;

[0111] Step S602: Based on the packet loss rate and the packet loss duration of the first packet, predict the packet loss rate and the packet loss duration of the second packet of the fourth response packet;

[0112] Step S603: Determine the data buffer parameters of the fourth response message based on the packet loss rate and duration of the second message;

[0113] Step S604: Determine the seventh request message based on the data cache parameters and the fourth request message.

[0114] Specifically, the first request message is the initial instruction used to query the communication status between the VCI and the ECU. The n first target response messages are the total number of first response messages that the diagnostic app is expected to receive. For example, a single ECU may correspond to multiple response messages, or there may be a broadcast query for multiple ECUs, with an expected n = 3 responses, corresponding to the engine, transmission, and body ECUs. The m first sub-response messages are the total number of first response messages actually received, where m ≤ n. For example, if only responses from the engine and body ECUs are received, m = 2. The first message packet loss rate is the proportion of response messages lost corresponding to the first request. The first message packet loss duration is the time interval from the occurrence of the first packet loss to the confirmation of the last packet loss after the first request is sent. Data caching parameters include cache size, cache retention time, retransmission trigger threshold, etc., which are used to optimize the transmission reliability of the seventh request message.

[0115] In one possible embodiment, the packet loss rate and packet loss duration of the first response message are calculated. The packet loss rate is (nm) / n × 100%. For example, if n = 3, 3 ECUs are expected to respond, and m = 2, 2 are actually received, then the packet loss rate is (3-2) / 3 ≈ 33.3%. When calculating the packet loss duration, the time t0 when the first request is sent is recorded, the theoretical receiving window for each expected response is recorded, such as t0+1s to t0+3s, the ECUs that did not receive a response are identified, the theoretical timeout time t1 for the first packet loss is determined (e.g., the transmission ECU did not respond at t0+2s), and the theoretical timeout time t2 for the last packet loss is determined. If there are no other packet losses, then t2 = t1, and the packet loss duration is t2 - t1. For example, t2 - t1 = 0s indicates a single packet loss. If multiple packet losses are scattered, then it is the longest interval.

[0116] In one possible embodiment, the packet loss rate and duration of the second packet loss in the fourth response message are predicted. The prediction of the second packet loss rate is based on the principle of communication link stability correlation in the same diagnostic session, combined with the fluctuation trend of the first packet loss rate. If the first packet loss rate is ≤10%, the link is stable, and the predicted second packet loss rate is ≈ first packet loss rate × (1±20%). If the first packet loss rate is 5%, the predicted rate is 4% to 6%. If the first packet loss rate is >10%, the link is unstable, and the predicted second packet loss rate is ≈ first packet loss rate × (1±50%). If the first packet loss rate is 33.3%, the predicted rate is 16.7% to 50%. In addition, a correction factor is set. If the bus load of the first request and the fourth request are different, such as when other devices are connected during the fourth request, the load influence coefficient needs to be added. For example, if the load increases by 10%, the packet loss rate will increase by 20%. The predicted packet loss duration for the second message is based on the packet loss duration for the first message, combined with the complexity of the fourth request message, such as diagnostic instructions with larger data volumes. If the length of the fourth request message is the same as that of the first request message, the second packet loss duration is approximately equal to the first packet loss duration multiplied by 1.2, with an additional 20% redundancy to address potential delays. If the fourth request message is longer, such as containing batch data, the second packet loss duration is approximately equal to the first packet loss duration multiplied by (1 + message length multiple). If the length is twice that of the first request message, the duration is multiplied by 2.2.

[0117] In one possible embodiment, the data caching parameters for the fourth response message are determined based on the prediction results. These parameters must match the packet loss risk level; higher packet loss rates and longer durations require greater caching. Specific data caching parameters include: cache size, cache retention time, retransmission trigger threshold, and message priority. The cache size must cover the maximum number of messages that may be lost within the second packet loss duration. Cache size = fourth request message sending rate × second packet loss duration × (1 + second packet loss rate). The cache retention time must be greater than the second packet loss duration to ensure sufficient time for lost messages to be retransmitted. Retention time = second packet loss duration × 2, setting double redundancy. The retransmission trigger threshold is used to trigger automatic retransmission when the proportion of messages without a response reaches 50% of the second packet loss rate, providing early intervention. Message priority increases with higher packet loss rates to avoid bandwidth being squeezed by other messages on the bus. It can be divided into 5 levels, with level 1 being the lowest and level 5 the highest.

[0118] In one possible embodiment, a seventh request message is generated by combining data caching parameters with the fourth request message. The seventh request message is an enhanced retry instruction of the fourth request. Caching parameters need to be integrated to improve the ability to resist packet loss. When the message structure is expanded, a cache control field is added to the fourth request message. For example, the fourth request message is [0x19,0x02], and the seventh request message is [0x19,0x02,0xE0,0x0E,0x04,0x04]. Among them, 0xE0 is the cache enable flag, 11100000, the first 3 bits indicate that caching is enabled, 0x0E is the cache size, 0x04 is the cache retention time, such as 4s, and 0x04 indicates priority level 4.

[0119] Optionally, if the fourth request message is to obtain diagnostic data from the ECU for ten consecutive minutes, and due to a high packet loss rate, the data caching parameter is set to cache all diagnostic data returned by the fourth request message. If not all the data required by the fourth request message is received within the target response time, when determining the seventh request message, if the diagnostic data of the first four minutes is obtained in the data cache, then the seventh request message does not need to re-obtain the diagnostic data from the ECU for ten consecutive minutes, but only needs to obtain the diagnostic data of the last six minutes of those ten consecutive minutes. In this way, the diagnostic operation that has already been performed is avoided, and the diagnostic efficiency is increased.

[0120] In this embodiment, the packet loss characteristics of the first response message directly reflect the weaknesses of the current communication link, such as the ECU response being prone to packet loss or the bus being overloaded during a specific period. Based on this, the packet loss risk of the fourth response can be predicted, and the buffer size can be configured to avoid insufficient buffer leading to no data being transmitted during retransmission, and the retention time can be adjusted to avoid premature release of the buffer. The priority enhancement and segmented transmission design of the seventh request message can actively avoid link weaknesses, such as high-priority messages being more easily transmitted during congestion, thereby improving the retry success rate.

[0121] Optionally, before sending the first request message to the target interface in step S101, the following steps may also be included:

[0122] Step S701: Obtain the vehicle identification number of the target vehicle;

[0123] Step S702: Based on the vehicle identification code, obtain the diagnostic list of the electronic control unit corresponding to the target vehicle and the current diagnostic node;

[0124] Step S703: Determine the electronic control unit from the electronic control unit diagnostic list based on the current diagnostic node;

[0125] Step S704: Determine the bus identifier based on the electronic control unit;

[0126] Step S705: Determine the first request message based on the bus identifier.

[0127] Specifically, the Vehicle Identification Number (VIN) is a unique 17-character identifier for a vehicle, such as LFV3A24G5E3001234, containing information such as manufacturer, model, year, and assembly plant. The ECU diagnostic list includes a list of all diagnosable ECUs for a specific vehicle model, such as engine ECUs, transmission ECUs, and body control modules (BCMs), containing information such as the function, communication protocol, and location of each ECU. The current diagnostic node is the diagnostic target selected by the user or the system default. The bus identifier is the unique communication identifier of the ECU on the vehicle bus, such as CANID or LIN address, used for message routing. The first request message is a communication status query command for a specific ECU and must include the bus identifier to ensure accurate delivery.

[0128] In one possible embodiment, the VIN code of the target vehicle is obtained. The diagnostic app connects to the vehicle's OBD interface via VCI and sends a VIN read command to obtain the VIN from the body control module. Alternatively, the user can input the vehicle's VIN through the app interface.

[0129] In one possible embodiment, the corresponding ECU diagnostic list and current diagnostic node are obtained based on the VIN. The diagnostic app queries the local database or cloud vehicle model database using the VIN to match the preset ECU list for that vehicle model. The ECU diagnostic list indicates the execution order of diagnostic functions for the target vehicle's ECUs. Based on the functions already executed for the target vehicle, the current diagnostic node is determined. Based on the current diagnostic node, the target ECU is identified from the ECU diagnostic list.

[0130] In one possible embodiment, the bus identifier is determined based on the target ECU. For CAN bus, an 11-bit or 29-bit ID is used, such as the engine ECU's transmit ID = 0x18DA10F1 and receive ID = 0x18DB33F1. For LIN bus, an address code is used, such as the BCM's address on the LIN bus = 0x05. For vehicle Ethernet, an IP address + port is used, such as 0x0A010101:5000.

[0131] In one possible embodiment, a first request message is determined based on a bus identifier. The first request message must include a bus identifier, a service ID, and a sub-function to ensure it is recognized by the target ECU. For example, taking a CAN bus query from an engine ECU as an example, the first request message = [bus identifier (0x18DB33F1), service ID (0x3E), sub-function (0x00)], where the bus identifier (0x18DB33F1) specifies that it is sent to the engine ECU, the service ID (0x3E) indicates the communication status query service in the UDS protocol, and the sub-function (0x00) indicates a request to return the ECU's real-time communication status, whether it is ready, and whether diagnostics are supported.

[0132] In this embodiment, the precise designation of bus identifiers, such as the CANID of the engine ECU, ensures that the first request message is only received by the target ECU, avoiding false responses from other ECUs due to broadcast queries and reducing bus interference. Traditional diagnostic processes require manual selection of vehicle model, year, and configuration, followed by ECU filtering, which is cumbersome. This embodiment, through automatic matching based on VIN, skips manual selection and directly locates the vehicle-specific ECU list, shortening the time to locate the target ECU and improving diagnostic efficiency.

[0133] In a specific embodiment, when the diagnostic device diagnoses the target vehicle, it first performs a communication status check on each ECU before sending a diagnostic message. Specifically, see [link to relevant documentation]. Figure 4 , Figure 4 This is a flowchart illustrating a testing and diagnostic method provided in an embodiment of this application. The testing phase is designated as the first communication phase, and the diagnostic phase as the second communication phase. After the App sends a testing message to the VCI, if the first communication phase indicates that the testing has passed, the App sends a diagnostic message to the VCI and receives the corresponding diagnostic response in the second communication phase.

[0134] Optional, see below Figure 5 , Figure 5 This is a communication diagram illustrating a re-verification method provided in an embodiment of this application. If, during the second communication phase, no corresponding response is received within the target response time after the App sends a diagnostic message to the VCI, a re-verification is performed. After the App sends a verification message to the VCI again, if the verification passes, it waits until a corresponding response is received; if the verification fails, the VCI needs to be restarted.

[0135] Optionally, to increase the accuracy of inspection during the inspection phase, refer to Figure 6 , Figure 6This is a communication diagram illustrating multiple checks in the first communication phase provided in this application embodiment. The VCI is only restarted when multiple consecutive checks fail, to prevent frequent VCI restarts caused by single check failures due to misjudgment. If a single check passes, a diagnostic message is immediately sent to the VCI for diagnosis.

[0136] In a specific embodiment, the VCI diagnostic device connects to the vehicle to perform vehicle fault diagnosis. It launches the diagnostic app, scans the vehicle identification VIN code, starts the hardware detection module, and initializes the diagnostic device. If the hardware detection module successfully identifies the VCI diagnostic device type, it starts the vehicle fault diagnosis module to diagnose the configured ECUs. The diagnostic app executes the functions of each configured vehicle ECU in sequence. If, during vehicle diagnosis, the VCI diagnostic device disconnects abnormally due to unforeseen factors such as unstable power supply, static electricity, interference, or software issues, preventing the diagnostic device from diagnosing vehicle faults, the diagnostic app automatically calls the hardware detection module to reinitialize the diagnostic device, re-identify the device type, switch back to diagnostic mode, and re-diagnose the vehicle's ECU modules.

[0137] Specifically, the process of reinitializing the diagnostic equipment, re-identifying the equipment type, and switching back to diagnostic mode includes steps such as acquiring VCI hardware information, VCI reset, VCI verification of the diagnostic software, and VCI entering diagnostic mode. The diagnostic app verifies communication with the VCI and sends a command to acquire VCI hardware information. If the acquisition is successful, it proceeds to the next step of VCI verification; otherwise, it exits the diagnostic process. If the acquisition is successful, the diagnostic app resends a connection establishment command to establish a connection. If the VCI reset is successful, it proceeds to the next step of VCI verification; otherwise, it exits the diagnostic process. If the VCI reset is successful, the diagnostic app sends a VCI verification command (i.e., the VCI diagnostic software). If verification is successful, it proceeds to the next step; otherwise, it exits the diagnostic process. If VCI verification is successful, the diagnostic app sends a command to enter diagnostic mode. Only in diagnostic mode can the VCI perform vehicle fault diagnosis. If entering diagnostic mode is successful, vehicle fault diagnosis begins; otherwise, the diagnostic process exits. The VCI hardware information includes the VCI serial number, software version number, chip ID, etc. After the command is issued, the success (positive response) or failure (negative response) of obtaining the VCI hardware information is determined based on the VCI's response information (positive or negative response).

[0138] Among them, identifying the device type is used to check whether there are any abnormalities in the communication between VCI and ECU, and obtaining VCI hardware information is used to detect whether there are any abnormalities in the communication between App and VCI.

[0139] Therefore, during vehicle fault diagnosis, if the VCI diagnostic device disconnects abnormally due to unforeseen circumstances, the diagnostic app can automatically recover from the communication failure caused by the unforeseen circumstances and continue diagnosing vehicle fault codes without the user noticing. After the vehicle fault diagnosis is completed, the diagnostic device is unplugged from the vehicle's OBD port and used for fault diagnosis on the next vehicle.

[0140] By automatically and quickly recovering faults from vehicle diagnostic equipment, the diagnostic app can automatically recover from communication problems caused by uncertain factors in the VCI diagnostic equipment without the user's awareness. This achieves efficient, real-time, and secure vehicle diagnostics, thereby improving vehicle diagnostic efficiency, vehicle production efficiency, and significantly enhancing the user experience.

[0141] In this embodiment, the diagnostic app can automatically recover from communication failures caused by uncertain factors in the VCI diagnostic device, and perform vehicle fault diagnosis. All tasks are automatically completed by the diagnostic app program in the background. Without the user's awareness, the diagnostic app can automatically recover from communication failures caused by uncertain factors in the VCI diagnostic device, achieving efficient, real-time, and safe vehicle diagnosis, improving vehicle production efficiency, and enhancing the customer's experience with the equipment.

[0142] In summary, in this embodiment, before diagnosing the electronic control unit (ECU) of the target vehicle, a first request message is sent to the target interface. This first request message is used to obtain the communication status between the target interface and the ECU, and to obtain the first response message from the target interface to the first request message. The first response message reflects the communication status. If the first response message indicates a first communication status, a second request message is sent to the target interface. This second request message is used to diagnose the ECU, meaning that if the communication status is normal, the ECU is directly diagnosed. If the first response message indicates a second communication status, a third request message is sent to the target interface. The request message is used to switch the communication state from the second communication state to the first communication state and obtain the third response message from the target interface in response to the third request message. The third response message is used to reflect the result of the communication state switch. If the third response message indicates that the switch result is the first communication state, a fourth request message is sent to the target interface. The fourth request message is used to diagnose the electronic control unit. That is, when the communication state is abnormal, the communication state is switched first through the third request message, and the electronic control unit is diagnosed when the communication state is switched back to normal. In this way, unlike traditional manual intervention, the communication state can be automatically detected and the abnormality can be resolved when the communication state is abnormal, and the communication state can be automatically restored, thus improving the diagnostic efficiency.

[0143] The methods of the embodiments of the present invention have been described in detail above, and the apparatus of the embodiments of the present invention is provided below.

[0144] See Figure 7 , Figure 7 This is a schematic diagram of the structure of a vehicle diagnostic device provided in an embodiment of this application. Figure 7 As shown, the vehicle diagnostic device 800 includes a first processing unit 801 and a second processing unit 802. The first processing unit 801 is used to send a first request message to a target interface before diagnosing the electronic control unit (ECU) of a target vehicle. The first request message is used to obtain the communication status between the target interface and the ECU. The second processing unit 802 is used to obtain a first response message from the target interface to the first request message, which reflects the communication status. If the first response message indicates a first communication status, a second request message is sent to the target interface, which is used to diagnose the ECU. If the first response message indicates a second communication status, a third request message is sent to the target interface, which is used to change the communication status from the second to the first. A third response message from the target interface to the third request message is obtained, which reflects the result of the communication status change. If the third response message indicates a first communication status, a fourth request message is sent to the target interface, which is used to diagnose the ECU. This vehicle diagnostic device can be a diagnostic module of the aforementioned diagnostic equipment.

[0145] In specific implementations, the first processing unit 801 and the second processing unit 802 in this application embodiment may also execute other implementations described in the vehicle diagnosis method of this application embodiment, which will not be repeated here.

[0146] See Figure 8 , Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example... Figure 8 As shown, the electronic device 900 includes a transceiver 901, a processor 902, and a memory 903, which are connected via a bus 904. The memory 903 stores computer programs and data, and can transmit the data stored in the memory 903 to the processor 902. The electronic device 900 can be the vehicle diagnostic device 800 described above, and the processor 902 can be the first processing unit 801 and the second processing unit 802 described above. In this embodiment, the processor 902 is used to read the computer program in the memory 903 and execute some or all of the steps of the vehicle diagnostic method described above.

[0147] This application also provides a computer-readable storage medium storing a computer program that is executed by a processor to implement some or all of the steps of any of the vehicle diagnostic methods described in the above method embodiments.

[0148] This application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of any of the vehicle diagnostic methods described in the above method embodiments.

[0149] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0150] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0151] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules 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 through some interfaces; the indirect coupling or communication connection between devices or modules may be electrical or other forms.

[0152] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0153] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software program modules.

[0154] If the integrated module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). 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 memory 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 memory includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

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

Claims

1. A vehicle diagnosis method characterized by, A diagnostic module applied to a diagnostic device, the diagnostic device further including a target interface connected to a target vehicle; the method includes: Before diagnosing the electronic control unit of the target vehicle, a first request message is sent to the target interface. The first request message is used to obtain the communication status between the target interface and the electronic control unit. Obtain the first response message from the target interface in response to the first request message, wherein the first response message is used to reflect the communication status; If the first response message indicates that the communication state is the first communication state, a second request message is sent to the target interface. The second request message is used to diagnose the electronic control unit. If the first response message indicates that the communication state is the second communication state, a third request message is sent to the target interface. The third request message is used to change the communication state from the second communication state to the first communication state. The third request message includes a hardware information acquisition message, a connection reset message, a software verification message, and a mode switching message. Sending a third request message to the target interface includes: Send the hardware information acquisition message to the target interface, the hardware information acquisition message being used to acquire the hardware information of the target interface; Receive the second hardware sub-response message from the target interface in response to the hardware information acquisition message; If the second hardware sub-response message indicates that the hardware information has been successfully acquired, the connection reset message is sent to the target interface. The connection reset message is used to establish a connection with the target interface. Receive the second reset sub-response message from the target interface in response to the connection reset message; If the second reset sub-response message indicates that the target interface has been successfully reset, the software verification message is sent to the target interface. The software verification message is used to verify the communication status of the target interface. Receive the second verification sub-response message from the target interface in response to the software verification message; If the second verification sub-response message indicates that the target interface has been successfully verified, the mode switching message is sent to the target interface. The mode switching message is used to switch the working mode of the target interface to the diagnostic mode. The diagnostic mode is used to diagnose the target vehicle. Obtain the third response message from the target interface in response to the third request message, wherein the third response message is used to reflect the result of the communication state transition; If the third response message indicates that the conversion result is the first communication state, a fourth request message is sent to the target interface. The fourth request message is used to diagnose the electronic control unit.

2. The method of claim 1, wherein, After obtaining the first response message from the target interface to the first request message, the method further includes: Parse the first response message to determine the response code, which reflects the device type of the target interface; If the response code is inconsistent with the preset code, the communication state is determined to be the first communication state; If the response code matches the preset code, the communication state is determined to be the second communication state.

3. The method of claim 1 or 2, wherein, After sending the fourth request message to the target interface, the method further includes: If the target does not receive a fourth response message from the target interface for the third request message within the target response time, a fifth request message is sent to the target interface. The fifth request message is used to obtain the communication status between the target interface and the electronic control unit again. Obtain the fifth response message from the target interface in response to the fifth request message, the fifth response message being used to reflect the communication status again; If the fifth response message indicates that the communication state is the second communication state, a sixth request message is sent to the target interface. The sixth request message is used to change the communication state from the second communication state to the first communication state again. Obtain the sixth response message from the target interface in response to the sixth request message. The sixth response message is used to reflect the result of the communication state transition again. If the sixth response message indicates that the communication state is the first communication state, a seventh request message is sent to the target interface. The seventh request message is used to diagnose the electronic control unit again.

4. The method of claim 3, wherein, Before sending the fifth request message to the target interface, the method further includes: Based on the fourth request message, determine the target diagnostic function that the electronic control unit needs to perform; Based on the target diagnostic function, predict the first execution time of the electronic control unit; Based on the time interval between the first request message and the first response message, the second execution duration corresponding to the fourth request message is predicted, where the time interval is the duration between the sending time of the first request message and the receiving time of the first response message. The target response time is determined based on the first execution time and the second execution time.

5. The method of claim 3, wherein, The first request message corresponds to n first target response messages, and the first response message includes m first sub-response messages, where m is less than or equal to n. Before sending the seventh request message to the target interface, the method further includes: Based on the n first target response messages and the m first sub-response messages, determine the first message packet loss rate and the first message packet loss duration of the first response message; Based on the packet loss rate and the packet loss duration of the first packet, predict the packet loss rate and the packet loss duration of the second packet of the fourth response packet; The data caching parameters of the fourth response message are determined based on the packet loss rate and the packet loss duration of the second message. The seventh request message is determined based on the data cache parameters and the fourth request message.

6. The method of claim 1, wherein, Before sending the first request message to the target interface, the method further includes: Obtain the vehicle identification number of the target vehicle; Based on the vehicle identification code, obtain the diagnostic list and current diagnostic node of the electronic control unit corresponding to the target vehicle; The electronic control unit is determined from the electronic control unit diagnostic list based on the current diagnostic node; Determine the bus identifier based on the electronic control unit; The first request message is determined based on the bus identifier.

7. A vehicle diagnostic apparatus characterized by comprising: A diagnostic module is applied to a diagnostic device, the diagnostic device further includes a target interface connected to a target vehicle; the device includes a first processing unit and a second processing unit. The first processing unit is configured to send a first request message to the target interface before diagnosing the electronic control unit of the target vehicle. The first request message is used to obtain the communication status between the target interface and the electronic control unit. The second processing unit is configured to obtain a first response message from the target interface in response to the first request message, wherein the first response message is used to reflect the communication status; If the first response message indicates that the communication state is the first communication state, a second request message is sent to the target interface. The second request message is used to diagnose the electronic control unit. If the first response message indicates that the communication state is the second communication state, a third request message is sent to the target interface, the third request message being used to change the communication state from the second communication state to the first communication state; The third request message includes a hardware information acquisition message, a connection reset message, a software verification message, and a mode switching message; Sending a third request message to the target interface includes: Send the hardware information acquisition message to the target interface, the hardware information acquisition message being used to acquire the hardware information of the target interface; Receive the second hardware sub-response message from the target interface in response to the hardware information acquisition message; If the second hardware sub-response message indicates that the hardware information was successfully obtained, the connection reset message is sent to the target interface. The connection reset message is used to establish a connection with the target interface. Receive the second reset sub-response message from the target interface in response to the connection reset message; If the second reset sub-response message indicates that the target interface has been successfully reset, the software verification message is sent to the target interface. The software verification message is used to verify the communication status of the target interface. Receive the second verification sub-response message from the target interface in response to the software verification message; If the second verification sub-response message indicates that the target interface has been successfully verified, the mode switching message is sent to the target interface. The mode switching message is used to switch the working mode of the target interface to the diagnostic mode. The diagnostic mode is used to diagnose the target vehicle. Obtain the third response message from the target interface in response to the third request message, wherein the third response message is used to reflect the result of the communication state transition; If the third response message indicates that the conversion result is the first communication state, a fourth request message is sent to the target interface. The fourth request message is used to diagnose the electronic control unit.

8. An electronic device, comprising: include: A processor and a memory, the processor being connected to the memory, the memory being used to store a computer program, the processor being used to execute the computer program stored in the memory to cause the electronic device to perform the method as described in any one of claims 1-5.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions that, when executed by a processor, cause the processor to perform the method as described in any one of claims 1-5.

Images