Vehicle diagnosis method, system, device and equipment

Abstract

The invention provides a vehicle diagnosis method, system, device and equipment, relates to the technical field of automobiles, and improves the universality, flexibility and interaction efficiency of vehicle diagnosis. And the vehicle end operates applications in the cloud container through a unified protocol, synchronously inputs events and audio and video streams, and optimizes user interaction. The method comprises the steps of establishing connection with a vehicle, detecting a communication protocol adopted by the vehicle, determining a visual operation interface based on the communication protocol, responding to node arrangement operations of a user on the visual operation interface, combining the node arrangement operations to form a diagnosis workflow, converting the diagnosis workflow into an executable program, and sending the executable program to the vehicle. And an instruction corresponding to the executable program is converted according to the communication protocol and then is sent to the vehicle.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of automobiles, in particular to a vehicle diagnosis method, system, device and equipment. BACKGROUND

[0002] With the increasing complexity of automotive electronic systems, information exchange between various sensors and controllers becomes increasingly important.

[0003] Taking vehicle diagnosis as an example, a vehicle integrates an average of 4 communication protocols. In the vehicle diagnosis process, multiple communication protocols need to be adapted, and the incompatibility between different communication protocols becomes a huge challenge. In addition, during vehicle diagnosis, technicians often need to manually operate through multiple steps, which not only consumes time and effort, but also is prone to errors. SUMMARY

[0004] The present application provides a vehicle diagnosis method, system, device and equipment, which can improve the versatility, flexibility and interaction efficiency of vehicle diagnosis.

[0005] To achieve the above-mentioned purpose, the present application adopts the following technical solutions:

[0006] In a first aspect, the present application provides a vehicle diagnosis method, which comprises:

[0007] establishing a connection with the vehicle, detecting the communication protocol adopted by the vehicle, determining a visual operation interface based on the communication protocol, responding to the user's node arrangement operation on the visual operation interface, combining the node arrangement operation to form a diagnosis workflow, converting the diagnosis workflow into an executable program, and sending the instructions corresponding to the executable program to the vehicle after converting the instructions according to the communication protocol.

[0008] By automatically detecting the vehicle communication protocol, generating a visual interface, supporting the user to flexibly arrange the diagnosis workflow, and then converting it into an executable program and converting the instructions according to the protocol, the problem of manually switching tools in the traditional scheme is solved, the multi-protocol compatibility and diagnosis efficiency are improved, the vehicle operation process is optimized, and the user experience is enhanced.

[0009] One possible implementation is to detect the communication protocol adopted by the vehicle, which can be specifically implemented as follows: detecting the electrical characteristics of a preset pin, determining a first communication protocol identification result based on the electrical characteristics, verifying based on the first communication identification result, determining a second identification result based on the verification result, and determining the communication protocol based on the second identification result. This solves the problem of easy errors in traditional single detection, and improves the protocol identification reliability.

[0010] In another possible implementation, the visual operation interface is determined based on the communication protocol, which can be specifically implemented as follows: based on the type of the communication protocol, a node compatible with the type of the communication protocol is selected from a preset service node library, and a parameter option panel of the visual operation interface is configured according to characteristics of the communication protocol, where the type of the node includes a diagnostic service node and a logic control node. This ensures that the node is compatible with the protocol, avoids incompatibility problems, and enables the parameter configuration to be in line with the protocol requirements and reduce operation errors. Meanwhile, the diagnostic service node and the logic control node are provided to meet complex diagnostic requirements and improve diagnostic efficiency and accuracy.

[0011] In another possible implementation, the node arrangement operation can be specifically implemented as follows: an association relationship between nodes is defined, and parameters of the nodes are configured based on the parameter option panel; and the node arrangement operation is combined to form a diagnostic workflow, which can be specifically implemented as follows: a logic verification rule corresponding to the communication protocol is acquired, the association relationship between the nodes is verified for legality based on the logic verification rule, and the nodes and the association relationship between the nodes that pass the legality verification are encapsulated into the diagnostic workflow. The node association and the parameter configuration are completed through arrangement, the node association is verified for legality in combination with the logic verification rule of the communication protocol, and the diagnostic workflow is encapsulated. This ensures that the node association is in line with the protocol logic and avoids incorrect arrangement, enables the parameter configuration to be accurately adapted to the protocol, and at the same time, standardizes the workflow to form a process, reduces execution errors, and improves diagnostic reliability and efficiency.

[0012] In another possible implementation, the diagnostic workflow is converted into an executable program, which can be specifically implemented as follows: the nodes in the diagnostic workflow are topologically sorted, corresponding execution code is generated according to the type of the nodes, and the execution code is encapsulated into the executable program in a preset format. The nodes in the diagnostic workflow are topologically sorted, the execution code is generated according to the type of the nodes and encapsulated into the executable program. The topological sorting ensures that the node execution order is reasonable and avoids logic confusion, the execution code is generated according to the type of the nodes to ensure that the execution logic is adapted to the node function, and the preset format encapsulation enables the program to be directly run. This improves the standardization and accuracy of the workflow conversion and improves the stability of the diagnostic process.

[0013] The vehicle diagnostic method provided in the application further includes the following steps, which can be specifically implemented as follows: after the converted instruction is sent to the vehicle, response data returned by the vehicle is received, and the instruction is processed based on the response data.

[0014] The vehicle diagnostic method provided in the application further includes the following steps, which can be specifically implemented as follows: a communication session with the vehicle is maintained during the diagnostic process.

[0015] In a second aspect, the application provides a vehicle diagnosis system, which specifically comprises: a host computer and a protocol adaptation device, the protocol adaptation device being configured to establish a connection with a vehicle, detect a communication protocol adopted by the vehicle, and the host computer being configured to determine a visual operation interface based on the communication protocol, acquire a node arrangement operation of a user on the visual operation interface, and combine the node arrangement operation to form a diagnosis workflow.

[0016] The host computer is configured to convert the diagnosis workflow into an executable program and send the converted communication protocol to the vehicle.

[0017] In another possible implementation, the host computer is further configured to, after sending the converted instruction to the vehicle, receive response data returned by the vehicle, and process the instruction based on the response data.

[0018] In another possible implementation, the host computer is further configured to maintain a communication session with the vehicle during the diagnosis process.

[0019] In another possible implementation, the protocol adaptation device is further configured to detect an electrical characteristic of a preset pin, determine a first communication protocol identification result based on the electrical characteristic, perform verification based on the first communication identification result, determine a second identification result based on a verification result, and determine the communication protocol based on the second identification result.

[0020] In another possible implementation, the host computer is further configured to, based on a type of the communication protocol, filter a node compatible with the type of the communication protocol from a preset service node library, and configure a parameter option panel of the visual operation interface according to a characteristic of the communication protocol. The type of the node includes a diagnosis service node and a logic control node.

[0021] In another possible implementation, the host computer is further configured to acquire a logic verification rule corresponding to the communication protocol, perform legality verification on an association relationship between the nodes based on the logic verification rule, and encapsulate the nodes and the association relationship between the nodes that pass the legality verification into the diagnosis workflow.

[0022] In another possible implementation, the host computer is further configured to perform topological sorting on the nodes in the diagnosis workflow, generate corresponding execution code according to the type of the node, and encapsulate the execution code into the executable program in a preset format.

[0023] In another possible implementation, the protocol adaptation device is further configured to convert an instruction corresponding to the executable program into the communication protocol.

[0024] In a third aspect, the application provides a vehicle diagnosis device, which specifically comprises: a connection module, configured to establish a connection with a vehicle, and detect a communication protocol adopted by the vehicle; an interaction module, configured to determine a visual operation interface based on the communication protocol, obtain a node arrangement operation of a user on the visual operation interface, combine the node arrangement operation to form a diagnosis workflow, and a transmission module, configured to convert the diagnosis workflow into an executable program, and send instructions corresponding to the executable program to the vehicle after conversion according to the communication protocol.

[0025] In a fourth aspect, a computer device is provided, which comprises a processor and a memory, and the memory stores at least one computer program, which is loaded and executed by the processor to implement the vehicle diagnosis method of the first aspect.

[0026] The solutions provided in the second aspect to the fourth aspect are used to implement the method provided in the first aspect, and the specific implementation will not be described again. The technical effects corresponding to any one of the implementation manners of the second aspect to the fourth aspect can be referred to the technical effects corresponding to any one of the implementation manners of the first aspect, which will not be described again.

[0027] It should be noted that the various possible implementation manners of any one of the aspects can be combined on the premise that the solutions are not contradictory. BRIEF DESCRIPTION OF DRAWINGS

[0028] In order to more clearly illustrate the technical solutions in the embodiments of the application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the application, and other drawings can be obtained by those skilled in the art without creative labor.

[0029] Figure 1 The architecture diagram of the vehicle diagnosis server provided in the embodiments of the application is shown in the figure.

[0030] Figure 2 The flowchart of the vehicle diagnosis method provided in the embodiments of the application is shown in the figure.

[0031] Figure 3 The schematic diagram of the visual operation interface provided in the embodiments of the application is shown in the figure.

[0032] Figure 4 The flowchart of another vehicle diagnosis method provided in the embodiments of the application is shown in the figure.

[0033] Figure 5 The structure diagram of the vehicle diagnosis system provided in the embodiments of the application is shown in the figure.

[0034] Figure 6A structural schematic diagram of a vehicle diagnosis device provided in an embodiment of the present application is shown in the figure.

[0035] Figure 7 A structural schematic diagram of a computer device provided in an embodiment of the present application is shown in the figure. DETAILED DESCRIPTION

[0036] In the embodiments of the present application, in order to clearly describe the technical solutions of the embodiments of the present application, the same items or similar items with basically the same functions and roles are distinguished by using "first", "second", etc. The skilled in the art can understand that "first", "second", etc. do not limit the quantity and execution order, and "first", "second", etc. also do not limit being different. The technical features described by "first", "second" have no sequence or size order.

[0037] In the embodiments of the present application, the words such as "exemplarily" or "for example" are used to represent an example, illustration or description. Any embodiment or design scheme described as "exemplarily" or "for example" in the embodiments of the present application should not be interpreted as more preferred or more advantageous than other embodiments or design schemes. In fact, the words such as "exemplarily" or "for example" are intended to present the related concept in a specific manner for understanding.

[0038] In the embodiments of the present application, at least one can also be described as one or more, and the plurality can be two, three, four or more, which is not limited by the present application.

[0039] In addition, the network architecture and the scenario described in the embodiments of the present application are used to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided by the embodiments of the present application. The skilled in the art can know that, with the evolution of network architecture and the appearance of new business scenarios, the technical solutions provided by the embodiments of the present application are also applicable to similar technical problems.

[0040] In order to facilitate understanding, the terms involved in the embodiments of the present application are first explained.

[0041] Communication protocol: refers to a rule set followed when data is exchanged between electronic control units inside a vehicle and between an electronic control unit and an external device, including data frame format, transmission rate, verification method, instruction set, etc. In the present application, protocols such as Controller Area Network (CAN), LIN, vehicle Ethernet, UDS, etc. are used to realize the standardized transmission of diagnosis instructions and data.

[0042] CAN: A serial communication protocol used in vehicle interiors, supporting multi-node communication with high reliability and real-time performance. The traditional CAN bus transmission rate can reach 500 kbps. In this application, CAN with Flexible Data-Rate (CAN FD) is used as an extension, supporting a maximum transmission rate of 5 Mbps. It connects to the vehicle through the On-Board Diagnostics (OBD) interface pins 6 and 14.

[0043] Local Interconnect Network (LIN): A low-cost serial communication protocol, often used as an auxiliary network to CAN bus, connecting devices with lower real-time requirements (such as window and seat control modules), with lower transmission rates, suitable for simple data exchange scenarios.

[0044] Electronic Control Unit (ECU): An electronic module inside the vehicle responsible for controlling specific functions, such as engine ECU and body control ECU. It receives and sends data through the vehicle bus and executes corresponding control instructions, making it the target of diagnostic services.

[0045] Unified Diagnostic Services (UDS): A diagnostic service specification based on ISO 14229 standards, defining a series of service functions for vehicle diagnostics. Through standardized service IDs and data formats, it enables unified diagnostic interaction between different brands and models of ECUs.

[0046] On-Board Diagnostics (OBD): A built-in system in vehicles for monitoring and reporting vehicle faults. It connects to external diagnostic devices through a standardized OBD interface, enabling fault diagnosis and data reading of key systems such as engines and transmissions.

[0047] OBD-Central Unit: A dedicated diagnostic control device integrated into the vehicle, directly connected to the vehicle bus system, with localized diagnostic logic processing capabilities. It can collect real-time data from various ECUs and support diagnostic operations through vehicle display screens or specialized interfaces.

[0048] It should be noted that the information (including but not limited to device information, subject personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.) and signals involved in this application are all authorized by the subject or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards.

[0049] For example, in the traditional vehicle diagnostics field, commonly used solutions in the industry are mostly based on dedicated hardware and firmware. These solutions are often developed for specific vehicle models or a single communication protocol. For example, early diagnostic tools were only compatible with the CAN 2.0A / B protocol. When users encountered vehicles equipped with FlexRay or LIN, they had to manually switch between different diagnostic tools, or even carry multiple devices to adapt to different vehicle protocols.

[0050] As automotive electronic architecture evolves towards domain centralization, the coexistence of multiple protocols has become an industry standard. In the vehicle network, CAN is responsible for real-time communication of the body control module, the vehicle Ethernet is responsible for large data transmission, and the Bluetooth and Wi-Fi protocols are used for vehicle-computer interconnection. Multiple protocols work in parallel in the same network environment. Traditional diagnostic solutions lack cross-protocol parsing capabilities, and when processing mixed protocol messages, they need to frequently switch parsing rules, which affects diagnostic efficiency. At the same time, there is a lack of unified standards for data interaction between the vehicle and the cloud. For example, the UDS service identifiers used by different car companies are different, and some event data have protocol conversion errors when uploading to the cloud. In remote diagnosis scenarios, the synchronization delay between audio and video streams and diagnostic events is as high as 300-500 milliseconds, making it difficult for engineers to locate faults based on real-time images.

[0051] Based on this, the present application provides a vehicle diagnostic method that automatically detects the vehicle communication protocol, adapts and generates a visual interface, supports users to flexibly arrange diagnostic workflows, and then converts them into executable programs and sends them according to protocol conversion instructions. This solves the problem of traditional solutions requiring manual tool switching, improves multi-protocol compatibility and diagnostic efficiency, and at the same time optimizes the vehicle-side operation process and enhances the user experience.

[0052] The solutions provided by the embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0053] The solution provided in this application can be applied to Figure 1 In the vehicle diagnostic server shown, Figure 1 A schematic diagram of the architecture of a vehicle diagnostic server is shown.

[0054] For example, Figure 1The vehicle diagnosis server 101 shown can be an intelligent terminal integrating diagnosis logic and interaction functions, for example, an on-board diagnosis central control unit, a portable diagnosis instrument host, or an industrial computer or edge node device of a cloud diagnosis platform loaded with special diagnosis software.

[0055] The on-board diagnosis central control unit refers to a special diagnosis control device integrated in the vehicle interior, which is usually directly connected to the vehicle bus system, can collect running data of each ECU in the vehicle interior in real time, has local diagnosis logic processing capability, and supports diagnosis operation through the vehicle display screen or a special interaction interface.

[0056] The portable diagnosis host refers to a compact diagnosis device with mobility, small size and a built-in power supply module, which can be temporarily connected to the vehicle end system of different vehicle models through an OBD interface or a special connection line, and has a built-in multi-protocol adaptation capability.

[0057] The vehicle diagnosis server 101 can locally deploy diagnosis algorithms and protocol analysis modules, directly establish communication with vehicle end devices, or serve as a lightweight client to call cloud diagnosis services to complete complex calculations through the network. The "acquisition" of the vehicle diagnosis server 101 in the present application includes any term with acquisition function such as query, discovery and extraction, which is not limited in the present application.

[0058] Optionally, the vehicle diagnosis server 101 can be an integrated diagnosis device with a touch interaction screen, integrating visual operation interface display and node arrangement operation input functions.

[0059] Optionally, it supports external keyboard and mouse, and adapts to different vehicle end communication connectors through an expansion interface, and flexibly adapts to multi-vehicle diagnosis scenarios.

[0060] Specifically, when performing node arrangement and diagnosis workflow conversion, the vehicle diagnosis server 101 can rely on the locally stored communication protocol library to quickly match the protocol type of the vehicle end device, call preset diagnosis service nodes and logic control nodes, present a drag-and-drop and configurable diagnosis process arrangement area on the visual operation interface to the user, and simultaneously display a protocol parameter configuration panel on the sidebar of the interface to allow the user to intuitively define node association and set parameters, and then generate a legal diagnosis workflow through built-in verification logic, and finally convert it into executable instructions for the vehicle end.

[0061] Specifically, the vehicle diagnosis server 101 includes a hardware layer and a software function layer.

[0062] Specifically, the hardware layer refers to physical components supporting the operation of the vehicle diagnosis server 101, including a processor, a memory, a local storage unit, a visual interaction screen, an expansion interface module, and a power module.

[0063] Optionally, the hardware layer can integrate a wireless communication module to support wireless data interaction with a cloud diagnostic platform or a mobile terminal.

[0064] The software function layer refers to a collection of program modules that implement diagnostic logic, including a protocol matching module, a node management module, a visual interaction module, a logic verification module, a workflow conversion module, an instruction adaptation module, and a data interaction module.

[0065] Figure 2 is a flowchart of a vehicle diagnostic method provided by an embodiment of the present application. The method can be executed by a vehicle diagnostic server, which can be the vehicle diagnostic server 101 in Figure 1 The vehicle diagnostic method provided by the embodiment of the present application can be applied to vehicle fault diagnosis, parameter configuration, performance detection, and the like in a multi-vehicle model and multi-communication protocol scenario, including automobile production off-line detection, vehicle fleet batch diagnosis, and vehicle remote fault troubleshooting, and the like. By automatically detecting the vehicle communication protocol, generating a visual interface, supporting user flexible arrangement of diagnostic workflows, and converting the executable program and sending the protocol conversion instructions, the problem of manual switching of tools in the traditional scheme is solved, the multi-protocol compatibility and diagnostic efficiency are improved, the vehicle operation process is optimized, and the user experience is enhanced.

[0066] As shown in Figure 2 The vehicle diagnostic method provided by the embodiment of the present application can include:

[0067] Step S201: Establishing a connection with a vehicle and detecting a communication protocol adopted by the vehicle.

[0068] The communication protocol adopted by the vehicle refers to a collection of rules followed when data is exchanged between internal electronic control units of the vehicle or between the electronic control unit and external devices, including data frame format, transmission rate, verification method, instruction set, and the like, such as CAN, LIN, FlexRay, vehicle-mounted Ethernet, UDS, and the like.

[0069] Establishing a connection with the vehicle means that the vehicle diagnostic server establishes a data transmission channel with the bus system or ECU of the vehicle through a physical interface, so that the server can send instructions to the vehicle and receive feedback data.

[0070] In some embodiments, the electrical characteristics of the preset pin are detected, the first communication protocol identification result is determined based on the electrical characteristics, the verification is performed based on the first communication identification result, the second identification result is determined based on the verification result, and the communication protocol is determined based on the second identification result.

[0071] The preset pin refers to a specific pin in a vehicle diagnostic interface that is predefined and associated with a communication protocol. Its function and number generally follow industry standards, such as the 6th and 14th pins of the OBD-II interface, which are commonly used for CAN bus communication.

[0072] The electrical characteristics refer to the electrical parameter characteristics of the preset pin, including the voltage range between pins, signal transmission rate, differential signal characteristics, signal period, etc. The pins of different protocols will exhibit unique electrical characteristics.

[0073] Optionally, the preset pin can be dynamically selected according to the vehicle type. For example, for new energy vehicles, the pins related to the vehicle-mounted Ethernet are preferentially detected, and for traditional fuel vehicles, the pins corresponding to the CAN / LIN protocol are mainly detected.

[0074] For example, the 6th and 14th pins of the OBD-II interface usually exhibit a reference voltage of about 2.5V during communication, and the voltage difference between them changes with data transmission, with a high-level difference of about 2V and a low-level difference of about 0V, which is a typical electrical characteristic of the CAN protocol.

[0075] The first communication protocol identification result refers to the communication protocol that the vehicle may use based on the preliminary matching of the electrical characteristics of the preset pin. It is a preliminary judgment result. For example, after detecting the electrical characteristics of the above-mentioned CAN protocol, it is preliminarily identified as "CAN 2.0 protocol".

[0076] Specifically, the determination process of the first communication protocol identification result is as follows: the server has a protocol electrical characteristic library, and the detected pin electrical parameters are compared with the characteristic parameters of each protocol in the library, and the protocol with the highest matching degree is selected as the first identification result.

[0077] Optionally, if the detected electrical characteristics match multiple protocols at the same time, such as the overlapping of some characteristics of CAN and CAN FD, the first identification result can include multiple candidate protocols, sorted by matching degree.

[0078] The matching degree refers to the degree of coincidence or similarity between the detected electrical characteristic parameters and the target protocol parameters in the protocol electrical characteristic library, which is calculated by a quantitative algorithm. The higher the degree of coincidence, the higher the matching degree score.

[0079] For example, for the vehicle-mounted Ethernet protocol, the electrical characteristics of its preset pin usually exhibit: supporting high-speed transmission rates such as 100Mbps / 1Gbps, using differential signal transmission, and working voltage range complying with IEEE standards. If the pin exhibits a 100Mbps transmission rate and corresponding differential signal characteristics, the first identification result may be: vehicle-mounted Ethernet, 100BASE-T1, matching degree 95%.

[0080] For example, when the pin transmission rate is detected as 500kbps and the extended frame format is supported, the first identification result can be: CAN 2.0B matching degree 90%, CAN FD matching degree 70%.

[0081] Optionally, in the verification stage, if the first identification result contains the vehicle-mounted Ethernet protocol, the server can send a test frame conforming to the IEEE 802.3 protocol specification, and if the vehicle returns a response frame containing a MAC address, the verification is passed, and the second identification result is determined as "vehicle-mounted Ethernet protocol".

[0082] The verification based on the first communication identification result refers to sending a test instruction or a probe frame conforming to the protocol corresponding to the first identification result to the vehicle, and verifying the accuracy of the preliminary identification result by judging whether the vehicle returns a response conforming to the protocol specification.

[0083] The second identification result refers to the vehicle communication protocol finally determined after verification, which has high reliability and is the protocol basis for subsequent diagnosis processes, for example, the vehicle actually adopts "CAN FD protocol" after verification.

[0084] Optionally, if the first identification result contains multiple candidate protocols, the verification process can send test instructions of corresponding protocols in descending order of matching degree until a valid response is received to determine the final protocol.

[0085] For example, for "CAN 2.0B" and "CAN FD" in the first identification result, first send a test frame in CAN 2.0B format, if no response is received, send a test frame in CAN FD format, and after receiving a response, determine the second identification result as "CAN FD protocol".

[0086] Step S202: Determine the visual operation interface based on the communication protocol, and combine the node arrangement operation to form a diagnosis workflow in response to the user's node arrangement operation on the visual operation interface.

[0087] The visual operation interface refers to the interactive interface provided by the upper computer for the user to design and operate the diagnosis process, which integrates protocol configuration, service combination, process monitoring and other functional areas, and supports drag-and-drop node operation and parameter configuration.

[0088] Specifically, the visual operation interface includes a protocol configuration area, a service combination area, a parameter configuration panel and a monitoring window.

[0089] The embodiment of the application provides a schematic diagram of a visual operation interface. As shown in the figure, Figure 3 The visual operation interface includes a service toolbox, a logic canvas and a parameter configuration panel.

[0090] Specifically, the left side of the visual operation interface is a service toolbox, containing various diagnostic service nodes and logical control nodes of the service toolbox, the middle is a logical flow canvas, and the user drags nodes to combine the process on the logical canvas, and the right side is a parameter configuration panel, on which the service ID, security level and other parameters of the node can be set.

[0091] Among them, the diagnostic service node refers to a modular unit encapsulating a specific UDS diagnostic service function, which is adapted to the communication protocol and can directly call the corresponding service to complete the diagnostic operation.

[0092] Specifically, each diagnostic service node is associated with one or a group of UDS service IDs, contains the input and output parameters required by the service, and supports adapting the data frame format according to the communication protocol.

[0093] Optionally, custom service nodes are supported, for example, users add private UDS services based on protocol specifications, such as vendor-defined read-write services.

[0094] For example, the "10 diagnostic session" node corresponds to UDS service ID 0x10, and the subfunction code 0x03 can be set on the parameter panel; the "34 download data" node corresponds to service ID 0x34, and the data file path and target address need to be configured.

[0095] The logical control node refers to a functional node used to regulate the execution logic of the diagnostic process, which does not directly execute the diagnostic service, but is responsible for condition judgment, loop control or exception handling of the process.

[0096] Specifically, the logical control node is based on the logical rules of the communication protocol, such as the execution dependency relationship of the UDS service, to realize the scheduling of the diagnostic service node and ensure the compliance of the process.

[0097] Optionally, the logical control node supports nested logic, including conditional branches in the loop node to realize complex process control.

[0098] For example, the "conditional branch" node can judge the execution result of the previous node, such as whether the response contains a 0x50 positive reply, to decide to execute the "continue download" or "trigger error report" path, and the "loop control" node can set the number of loops, such as a maximum of 5 retries, to handle temporary communication failure scenarios.

[0099] Node arrangement operation refers to defining the association relationship between nodes, and configuring the parameters of the nodes based on the parameter option panel.

[0100] Optionally, advanced parameters of the node can be configured through the right-click menu, such as timeout time, retry times, or triggering an error handling branch when the node execution returns a specific error code.

[0101] For example, after dragging the "27 secure access" node, set the security level Level = 1 in the parameter panel, when the node returns NRC = 0x78 response pending, add a "loop retry" branch by right-clicking, and set the retry interval to 3s.

[0102] The association relationship between nodes refers to the logical connection mode of the nodes in the diagnostic process, which is used to define the execution order, condition judgment or parallel relationship. It includes sequential execution, conditional branching, loop control, parallel execution, etc.

[0103] For example, the "10 diagnostic session" node to the "27 secure access" node is sequential execution; the "34 download data" node is followed by a conditional branch, and if successful, the "36 transmission exit" is executed, and if failed, the "retry loop" is executed.

[0104] Sequential execution means that the next node is triggered after the previous node is completed, conditional branching means that different paths are selected according to the node execution result, loop control means that the node is repeatedly executed when the condition is met, and parallel execution means that multiple nodes are started simultaneously.

[0105] In some embodiments, based on the type of communication protocol, nodes compatible with the type of communication protocol are selected from a preset service node library. The types of nodes include diagnostic service nodes and logic control nodes.

[0106] Exemplarily, according to the characteristics of the communication protocol, the parameter option panel of the visual operation interface is configured.

[0107] The preset service node library refers to a set of modular nodes covering various diagnostic functions stored in the system in advance, including diagnostic service nodes and logic control nodes, and each node is associated with specific communication protocol compatibility information, so that the adaptive node can be quickly called according to different protocol types.

[0108] The selected node refers to selecting a node compatible with the currently detected communication protocol type from the preset service node library, excluding nodes that do not support the protocol, and ensuring that the diagnostic process arranged by the user can be executed normally under the corresponding protocol.

[0109] For example, when it is detected that the vehicle uses the CAN FD protocol, the diagnostic service nodes and logic control nodes that support the CAN FD transmission format are selected from the service node library, and the nodes that only support traditional CAN or Ethernet protocol are filtered.

[0110] The characteristics of the communication protocol refer to the unique attributes of different communication protocols in terms of data transmission, format specification, function limitation, etc., including transmission rate, data frame length, addressing method, protocol stack requirement, etc. These characteristics determine the specific content of parameter configuration.

[0111] For example, the characteristics of CAN protocol include 500kbps / 1Mbps transmission rate, 8-byte maximum standard frame, physical / function addressing; the characteristics of vehicle Ethernet include 100Mbps / 1Gbps transmission rate, IP-based addressing method, large file transmission support.

[0112] For example, the characteristics of CAN protocol include 500kbps / 1Mbps transmission rate, 8-byte maximum standard frame, physical / function addressing; the characteristics of vehicle Ethernet include 100Mbps / 1Gbps transmission rate, IP-based addressing method, large file transmission support.

[0113] For example, the characteristics of CAN protocol include 500kbps / 1Mbps transmission rate, 8-byte maximum standard frame, physical / function addressing; the characteristics of vehicle Ethernet include 100Mbps / 1Gbps transmission rate, IP-based addressing method, large file transmission support.

[0114] For example, the execution order rule of UDS service requires entering the extended mode through "10 diagnostic session" first, and then executing "27 security access"; the protocol frame format rule requires that the data length of CAN FD node conforms to the range of 5-64 bytes; the error handling rule requires resetting the session and retrying when NRC=0x34.

[0115] For example, the execution order rule of UDS service requires entering the extended mode through "10 diagnostic session" first, and then executing "27 security access"; the protocol frame format rule requires that the data length of CAN FD node conforms to the range of 5-64 bytes; the error handling rule requires resetting the session and retrying when NRC=0x34.

[0116] For example, the execution order rule of UDS service requires entering the extended mode through "10 diagnostic session" first, and then executing "27 security access"; the protocol frame format rule requires that the data length of CAN FD node conforms to the range of 5-64 bytes; the error handling rule requires resetting the session and retrying when NRC=0x34.

[0117] For example, the execution order rule of UDS service requires entering the extended mode through "10 diagnostic session" first, and then executing "27 security access"; the protocol frame format rule requires that the data length of CAN FD node conforms to the range of 5-64 bytes; the error handling rule requires resetting the session and retrying when NRC=0x34.

[0118] For example, the execution order rule of UDS service requires entering the extended mode through "10 diagnostic session" first, and then executing "27 security access"; the protocol frame format rule requires that the data length of CAN FD node conforms to the range of 5-64 bytes; the error handling rule requires resetting the session and retrying when NRC=0x34.

[0119] For example, the execution order rule of UDS service requires entering the extended mode through "10 diagnostic session" first, and then executing "27 security access"; the protocol frame format rule requires that the data length of CAN FD node conforms to the range of 5-64 bytes; the error handling rule requires resetting the session and retrying when NRC=0x34.

[0120] Specifically, the service combination compiler is implemented to: first, topologically sort the visual diagnostic workflow to determine the node execution order, then generate corresponding code according to the node type, such as generating service call code for UDS service nodes, generating logical judgment code for conditional branch nodes, and integrating into an executable program, and finally calling the protocol conversion middleware to convert the instructions in the program into a message format conforming to the protocol specification according to the detected communication protocol, and sending the message to the vehicle through the hardware interface.

[0121] The instructions corresponding to the executable program refer to specific UDS service instructions and logical control instructions for implementing diagnostic operations parsed from the executable program, including service ID, subfunction code, data parameters, and other core information.

[0122] For example, the corresponding instructions in the executable program generated by the ECU software flashing workflow include UDS service instructions such as "10 03 (extended diagnostic session)", "27 01 (request security seed)", and "34 00 (download data)", as well as logical control instructions such as "if NRC = 0x78, then retry 3 times".

[0123] Protocol conversion refers to encapsulating the instructions in the executable program into a message conforming to the current communication protocol format, adapting the data frame structure, transmission rate, addressing method, and other characteristics of the protocol. If the communication protocol is CAN / CAN FD, the conversion process is to call the "CAN frame construction process" to generate single or multiple frames according to the data length, such as encapsulating the "22F189" instruction into a standard frame with CAN ID = 0x7E0 and data field [0x22, 0xF1, 0x89]. If the communication protocol is vehicle Ethernet, the conversion process is to construct a data packet according to the vehicle Ethernet protocol specification, including the source IP address, port number, and UDS service data, such as encapsulating the "19 02 read fault code" instruction into a vehicle Ethernet message conforming to the ISO 13400 standard and sending it through the Ethernet channel.

[0124] Figure 4 is a flowchart of another vehicle diagnostic method provided by an embodiment of the present application. The method can be executed by a vehicle diagnostic server, which can be Figure 1 the vehicle diagnostic server 101 in the vehicle diagnostic system 100.

[0125] Step S400: Establish a connection with the vehicle and detect the communication protocol used by the vehicle.

[0126] This step can be referred to as step S201, which will not be described in detail here.

[0127] Step S401: Determine the visual operation interface based on the communication protocol, obtain the node arrangement operation of the user on the visual operation interface, and combine the node arrangement operation to form a diagnostic workflow.

[0128] The introduction of this step can be referred to step S202, which will not be described in detail here.

[0129] Step S402: Convert the diagnostic workflow into an executable program, and send the instructions corresponding to the executable program to the vehicle after conversion according to the communication protocol.

[0130] The introduction of this step can be referred to step S203, which will not be described in detail here.

[0131] Step S403: Receive the response data returned by the vehicle.

[0132] The response data refers to the feedback information returned by the ECU in response to the instructions sent by the diagnostic server, including instruction execution results, vehicle state parameters, fault codes, etc., and its format follows the communication protocol specification detected.

[0133] For example, for the "19 02 read fault code" instruction, the response data may be a message containing fault codes, fault states, and fault occurrence times. For the "22F189 read DID" instruction, the response data may be the specific parameter value corresponding to the DID.

[0134] Optionally, the response data may also include negative response codes, such as 0x78, which indicates that the request is received but needs to be waited for, and 0x22, which indicates that the requested parameters are not supported, used to prompt the reason for the abnormal execution of the instruction.

[0135] Step S404: Process the instruction based on the response data.

[0136] Processing the instruction means adjusting or supplementing the execution logic of subsequent diagnostic instructions according to the response data returned by the vehicle, including confirming the instruction execution result, processing abnormal responses, triggering subsequent nodes, etc., to ensure that the diagnostic process proceeds as expected.

[0137] Specifically, the processing method includes: if the response data is a positive reply, it is determined that the current instruction is executed successfully, and the next node in the diagnostic workflow is triggered; if the response data contains a negative response code, a waiting mechanism is started, such as re-sending the instruction after a delay of 3 seconds; if the response data contains an error code, the current process is terminated and an error handling node is triggered, such as recording logs and prompting the user to re-authenticate; if the response data is in an intermediate state, such as partial data transmission completion, the remaining instructions are continued to be sent, such as "36 transmission exit" before supplementing the incomplete data packet.

[0138] For example, when the response data of the "34 download data" instruction shows "50% data received", the processing logic is to continue sending the remaining data fragments, and when the response data is NRC=0x22, the processing logic is to terminate the download process and prompt "the target ECU does not support the data address" on the interface.

[0139] The above mainly introduces the scheme provided in the application. Correspondingly, the application also provides a vehicle diagnosis system for implementing the above method embodiments.

[0140] As Figure 5 The structure diagram of the vehicle diagnosis system is shown. The vehicle diagnosis system can include a host computer 501 and a protocol diagnosis device 502.

[0141] The host computer 501 refers to a computer terminal device for user diagnosis operation and control, and is a core interface carrier for human and diagnosis system interaction.

[0142] Specifically, the main functions of the host computer 501 include: providing a visual operation interface, supporting users to combine diagnostic service nodes and logic control nodes through drag and drop to form a customized diagnostic workflow; containing a protocol configuration area, which can automatically detect or manually set the communication protocol and parameters of the vehicle; provided with a monitoring window, which can display the real-time bidirectional message in the diagnosis process, highlight mark the error frame, and support HEX / ASCII / analysis view switching; can automatically generate a diagnosis report, export a standard-compliant file, and support PDF / Excel format output.

[0143] For example, the user can drag the nodes such as "10 diagnostic session" and "27 security access" in the service combination area of the host computer 501, configure the parameters through the right-click menu, form a diagnostic workflow for ECU software flashing, and then convert the workflow into an executable program by a service combination compiler, and then send it to the protocol diagnosis device 502 for execution.

[0144] The protocol diagnosis device 502 refers to a hardware device with multi-protocol adaptation and diagnosis instruction transceiving functions, which integrates protocol conversion, data transmission and hardware interface modules, and is used for establishing physical connection with the vehicle and realizing protocol conversion and execution of diagnosis instructions.

[0145] Specifically, the protocol diagnosis device 502 adopts modular design, including a main controller, a protocol acceleration FPGA, a double physical layer interface, and a wide voltage input circuit and ESD protection design, which can automatically detect the vehicle communication protocol, and convert the instructions sent by the host computer into protocol-compliant messages and send them to the vehicle ECU, while receiving vehicle response data feedback to the host computer.

[0146] The double physical layer interface is a CAN channel connected to the OBD interface Pin6 / Pin14 through a TJA1044GT transceiver, and an Ethernet channel connected to Pin12 / Pin13 through a DP83867IR chip.

[0147] For example, in the ECU software flashing scenario, after the protocol diagnosis device 502 receives the "34 download data" instruction sent by the host computer, it encapsulates the data into continuous frames conforming to the 5Mbps transmission rate through the CAN FD channel and sends them to the vehicle CAN bus.

[0148] Optionally, the protocol diagnosis device 502 and the host computer 501 establish a data transmission link through a wired interface to realize instruction and data interaction. Specifically, a USB 3.0 interface is used for connection. The host computer 501 sends executable programs and diagnosis instructions to the protocol diagnosis device 502 through the USB line, and the protocol diagnosis device 502 feeds back vehicle response data, message monitoring information and error status to the host computer through the USB interface. This connection mode supports high-speed data transmission and is suitable for large data volume scenarios such as firmware download in the diagnosis process.

[0149] Optionally, wireless connection can be realized through a wireless communication module, which is suitable for scenarios that require remote operation or are inconvenient for wiring.

[0150] For example, in the vehicle production line detection, the host computer 501 is connected with the protocol diagnosis device 502 through the USB line to issue diagnosis instructions in real time and receive feedback, ensuring efficient execution of the diagnosis process. In the mobile scenario of after-sales maintenance, wireless communication between the host computer and the protocol diagnosis device can be realized through Bluetooth connection to improve operation flexibility.

[0151] The application also provides a vehicle diagnosis device, which is used to realize the above-mentioned method embodiments.

[0152] As Figure 6 The structure diagram of the vehicle diagnosis device is shown. The vehicle diagnosis device can include a connection module 601, an interaction module 602 and a transmission module 603. The connection module 601 is used to execute Figure 2 The operation of step S201 in the schematic method and Figure 4 The operation of step S400 in the schematic method; the interaction module 602 is used to execute Figure 2 The operation of step S202 in the schematic method and Figure 4 S401, the transmission module 603 is used to execute Figure 2 Step S203 in the schematic method and Figure 3 S402, S403 and S404 in the schematic method.

[0153] In some embodiments, the vehicle diagnostic apparatus comprises hardware structures and / or software modules corresponding to each function in order to realize the above functions. Those skilled in the art should easily realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be realized in the form of hardware or a combination of hardware and computer software. Whether a certain function is realized in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to realize the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0154] The embodiments of the present application can divide the functional modules of the vehicle diagnostic apparatus according to the above method embodiments. For example, each functional module can be divided according to each function, or two or more functions can be integrated in one processing module. The integrated module can be realized in the form of hardware or software functional module. It should be noted that the division of modules in the embodiments of the present application is illustrative, and is only a logical functional division. When actually implemented, there can be another division manner.

[0155] As shown in Figure 7 The computer device provided by the embodiments of the present application can include a processor 701, a bus 702, a communication interface 703, and a memory 704. The processor 701, the memory 704, and the communication interface 703 communicate through the bus 702. It should be understood that the present application does not limit the number of processors and memories in the computer device.

[0156] The bus 702 can be a PCI bus or an extended industry standard architecture (EISA) bus, or a UB bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of representation, Figure 6 Only one line is used to represent the bus in the figure, but it does not mean that there is only one bus or only one type of bus. The bus 702 can include a path for transmitting information between various components (for example, the memory 704, the processor 701, and the communication interface 703) of the computer device.

[0157] The processor 701 can include any one or more of a CPU, a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP), etc.

[0158] The memory 704 can include volatile memory, such as random access memory (RAM), and non-volatile memory, such as read-only memory (ROM), flash memory, a hard disk drive (HDD), or a solid-state drive (SSD).

[0159] The communication interface 703 uses a transceiving module such as, but not limited to, a network interface card, a transceiver, and the like, to enable communication between the computer device and other devices or communication networks.

[0160] The memory 704 stores executable program code, and the processor 701 executes the executable program code to respectively implement the functions of the foregoing method embodiments. That is, the memory 704 has instructions for executing the vehicle diagnosis method described above.

[0161] Those skilled in the art can clearly understand the above-mentioned embodiments, for the convenience and brevity of description, only the above-mentioned division of functional modules is taken as an example, and in actual application, the above-mentioned functions can be completed by different functional modules according to needs, that is, the internal structure of the module is divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, module and unit described above can refer to the corresponding process in the foregoing method embodiments, which will not be described here.

[0162] The method steps in the embodiments can be implemented by hardware or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, which can be stored in a random access memory (RAM), a flash memory, a read-only memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM), an electrically EPROM (EEPROM), a register, a hard disk, a mobile hard disk, a CD-ROM, or any other form of storage medium well known in the art. An exemplary storage medium is coupled to a processor, so that the processor can read information from, and write information to, the storage medium. Of course, the storage medium can be a component of the processor. The processor and the storage medium can be located in an ASIC. The ASIC can be located in a network device. Of course, the processor and the storage medium can also exist as discrete components in the network device. In the above embodiments, the entire or part of the flow or function can be implemented by software, hardware, firmware, or any combination thereof. When implemented by software, the entire or part of the flow or function can be implemented in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer programs or instructions are loaded on a computer, the entire or part of the flow or function of the embodiments of the present application is executed. The computer can be a general purpose computer, a special purpose computer, a computer network, a network device, a user equipment, or other programmable modules. The computer programs or instructions can be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another computer readable storage medium, for example, from a website site, a computer, a server, or a data center to another website site, a computer, a server, or a data center through a wired or wireless way. The computer readable storage medium can be any available medium or a data storage device integrated with one or more available media in a server, a data center, or the like, which can be accessed by a computer. The available medium can be a magnetic medium, such as a floppy disk, a hard disk, or a magnetic tape; an optical medium, such as a digital video disc (DVD); or a semiconductor medium, such as a solid state drive (SSD). The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any skilled person in the art can easily think of various equivalent modifications or replacements within the technical scope disclosed in the present application, which should be covered in the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

[0163] Since the vehicle diagnosis apparatus, the computer readable storage medium and the computer program product in the embodiments of the present application can be applied to the above method, the technical effects that can be obtained thereby can also be referred to the above method embodiments, and the embodiments of the present application will not be described here. The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto, and any change or replacement within the technical scope disclosed in the present application should be covered in the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims. The method steps in the embodiments can be realized by hardware or by the processor executing software instructions. The software instructions can be composed of corresponding software modules, and the software modules can be stored in a random access memory (RAM), a flash memory, a read-only memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM), an electrically EPROM (EEPROM), a register, a hard disk, a mobile hard disk, a CD-ROM or any other form of storage medium well known in the art. An exemplary storage medium is coupled to the processor, so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be an integral part of the processor. The processor and the storage medium can be located in an ASIC. In addition, the ASIC can be located in a network device. Of course, the processor and the storage medium can also exist as discrete components in the network device. In the above embodiments, all or part of the processes or functions can be realized by software, hardware, firmware or any combination thereof. When realized by software, all or part of the processes or functions can be realized in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer programs or instructions are loaded and executed on the computer, all or part of the processes or functions of the embodiments of the present application are executed. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment or other programmable modules. The computer programs or instructions can be stored in a computer readable storage medium or transferred from one computer readable storage medium to another, for example, the computer programs or instructions can be transferred from one website site, computer, server or data center to another website site, computer, server or data center through wired or wireless manner. The computer readable storage medium can be any available medium that can be accessed by the computer or a data storage device such as a server, data center and the like integrated with one or more available media.The medium can be a magnetic medium, such as a floppy disk, a hard disk, or a magnetic tape; an optical medium, such as a digital video disc (DVD); or a semiconductor medium, such as a solid state drive (SSD). The above are merely specific embodiments of the present application, but the scope of protection of the present application is not limited thereto. Any person skilled in the art can easily think of various equivalent modifications or replacements within the technical scope disclosed by the present application, and these modifications or replacements shall be encompassed within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be subject to the scope of protection of the claims.

Claims

1. A vehicle diagnostic method, characterized in that: The method comprises: Establish a connection with the vehicle and detect the communication protocol used by the vehicle; Determining a visual operation interface based on the communication protocol, and in response to a user's node orchestration operation on the visual operation interface, combining the node orchestration operations to form a diagnostic workflow; The diagnostic workflow is converted into an executable program, and instructions corresponding to the executable program are converted according to the communication protocol and then sent to the vehicle.

2. The method according to claim 1, characterized in that The communication protocol used by the detection vehicle includes: Detecting electrical characteristics of a preset pin, and determining a first communication protocol identification result based on the electrical characteristics; performing verification based on the first communication identification result, and determining a second identification result based on the verification result; The communication protocol is determined based on the second recognition result.

3. The method according to claim 1, characterized in that The determining of a visual operation interface based on the communication protocol includes: Based on the type of the communication protocol, select nodes compatible with the type of the communication protocol from a preset service node library, the types of the nodes including: diagnostic service nodes and logical control nodes; According to the characteristics of the communication protocol, the parameter option panel of the visual operation interface is configured.

4. The method according to claim 1, wherein The node orchestration operation includes: defining the association relationship between the nodes, configuring the parameters of the nodes based on the parameter option panel; combining the node orchestration operations to form a diagnostic workflow, including: Obtaining a logic verification rule corresponding to the communication protocol, and verifying the legitimacy of the association relationship between nodes based on the logic verification rule; The nodes that have passed the validity verification and the association relationships between the nodes are encapsulated as a diagnosis workflow.

5. The method according to claim 3, characterized in that Converting the diagnostic workflow into an executable program includes: Performing topological sorting on the nodes in the diagnostic workflow, and generating corresponding execution codes according to the node types; The execution code is packaged into the executable program according to a preset format.

6. The method according to claim 1, wherein Also includes: After sending the converted command to the vehicle, receiving response data returned by the vehicle; The instruction is processed based on the response data.

7. The method according to claim 1, characterized in that Also includes: A communication session with the vehicle is maintained during the diagnostic process.

8. A vehicle diagnostic system, characterized in that: The system includes: a host computer and a protocol adapter; Protocol adapter: used to establish a connection with the vehicle and detect the communication protocol used by the vehicle; The host computer is used to determine a visual operation interface based on the communication protocol, obtain the node arrangement operation of the user on the visual operation interface, and combine the node arrangement operations to form a diagnostic workflow; Host computer: used to convert the diagnostic workflow into an executable program; The converted communication protocol is sent to the vehicle.

9. The system according to claim 8, characterized in that The host computer is also used for: After sending the converted command to the vehicle, receiving response data returned by the vehicle; processing the instruction based on the response data; A communication session with the vehicle is maintained during the diagnostic process.

10. The system according to claim 8, wherein: The protocol adapter is further configured to: The instructions corresponding to the executable program are converted according to the communication protocol.

11. A vehicle diagnostic device, characterized in that: The device includes: Connection module: used to establish a connection with the vehicle and detect the communication protocol used by the vehicle; Interaction module: used to determine a visual operation interface based on the communication protocol, obtain the node arrangement operation of the user on the visual operation interface, and combine the node arrangement operations to form a diagnostic workflow; Transmission module: converts the diagnostic workflow into an executable program, and converts the instructions corresponding to the executable program according to the communication protocol and sends them to the vehicle.

12. A computer device, characterized in that: The computer device includes: a processor and a memory, wherein at least one computer program is stored in the memory, and the at least one computer program is loaded and executed by the processor to implement the vehicle diagnostic method according to any one of claims 1 to 7.

Images