Method and device for executing diagnostic test sequence
By calling the external API interface to parse and execute node values in the diagnostic test sequence, the problem of developers in the prior art need to write complex code for ODX file parsing and ECU communication is solved, and the effect of reducing workload and improving development efficiency is achieved.
Patent Information
- Application Number
- CN202510056592.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-01-14
- Publication Date
- 2025-04-29
AI Technical Summary
Execution of existing diagnostic test sequences requires developers to write complex code to parse ODX files and implement communication with the ECU, resulting in excessive workload.
By calling the external API interface to load the ODX file, parse the node values in the diagnostic test sequence, generate communication connections and diagnostic service requests, and realize communication and diagnostic service execution between the diagnostic device and the ECU.
Reduces the workload of developers, improves development efficiency, and allows developers to focus on the implementation of diagnostic logic without writing too much code for ODX file parsing and ECU communication.
Smart Images

Figure CN119902920A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of automobile diagnostic testing, and in particular to a method and device for executing a diagnostic testing sequence. Background Art
[0002] Diagnostic testing is an important part of vehicle diagnostic development in the automotive field. Currently, diagnostic testing is generally performed using diagnostic test sequences based on OTX (ISO-13209 Open test sequence exchange format) and ODX (ISO-22901-1 Open diagnostic data exchange). Since both OTX and ODX are standard open description formats, the diagnostic test sequences built can be used uniformly among automotive system suppliers, manufacturers, service dealers, and repair shops, and can even be used across companies. The introduction of these two specifications greatly reduces the development of upper-level application tools and speeds up the iterative development of vehicle models, thereby saving a lot of economic and labor costs.
[0003] The execution of existing diagnostic test sequences requires developers to write complex codes to parse the ODX files referenced in the diagnostic test sequences, and to write complex codes to achieve communication with the ECU, which results in excessive workload for developers. Summary of the invention
[0004] In view of this, an embodiment of the present invention provides a method and apparatus for executing a diagnostic test sequence, so as to reduce the workload of developers and improve development efficiency.
[0005] To achieve the above objectives, the embodiments of the present invention provide the following technical solutions:
[0006] A first aspect of an embodiment of the present invention discloses a method for executing a diagnostic test sequence, which is applied to a diagnostic device. The method includes:
[0007] Calling an external API interface to load an ODX file referenced by a diagnostic test sequence; the diagnostic test sequence is established based on the OTX standard and the ODX standard;
[0008] Parse the Get Communication Channel node in the diagnostic test sequence to obtain the Get Communication Channel node value;
[0009] Calling the external API interface to obtain the communication channel data identified by the communication channel node value from the ODX file, and establishing a communication connection between the diagnostic device and the ECU to be diagnosed based on the communication channel data;
[0010] Parsing the diagnostic service node in the diagnostic test sequence to obtain a diagnostic service node value;
[0011] The external API interface is called to obtain diagnostic service data corresponding to the diagnostic service node value from the ODX file, a diagnostic service request is generated based on the diagnostic service data and the external API interface, the diagnostic service request is sent to the ECU to be diagnosed, and the diagnostic service response returned by the ECU to be diagnosed is received and parsed to obtain a response parameter value.
[0012] Preferably, the communication channel data includes: logical link information and data source information, and the step of establishing a communication connection between the diagnostic device and the ECU to be diagnosed based on the communication data to obtain a logical link between the diagnostic device and the ECU to be diagnosed includes:
[0013] Creating a communication channel between the diagnostic device and the ECU to be diagnosed based on the external API interface and the logical link information;
[0014] Based on the external API interface and the data source information, the data source of the ECU to be diagnosed is switched to a designated data source, and it is determined that the communication connection between the diagnostic device and the designated data source in the ECU to be diagnosed is established.
[0015] Preferably, after determining that the communication connection between the diagnostic device and the designated data source in the ECU to be diagnosed is established, the method further includes:
[0016] Parsing the communication node setting in the diagnostic test sequence to obtain the communication node setting value; the communication node setting value includes: the name of the target communication parameter and the parameter value to be updated;
[0017] Based on the name of the target communication parameter and the external API interface, the target communication parameter is obtained from the ODX file, and the target communication parameter is updated based on the parameter value to be updated;
[0018] The external API interface is called to set the communication parameters used in the communication process between the diagnostic device and the ECU to be diagnosed to the updated target communication parameters.
[0019] Preferably, the diagnostic service node value includes: creating a diagnostic service node value and executing a diagnostic service node value. Accordingly, the calling of the external API interface obtains diagnostic service data corresponding to the diagnostic service node value from the ODX file, generates a diagnostic service request based on the diagnostic service data and the external API interface, sends the diagnostic service request to the ECU to be diagnosed, receives and parses the diagnostic service response returned by the ECU to be diagnosed to obtain a response parameter value, including:
[0020] Based on the external API interface and the created diagnostic service node value, obtaining the diagnostic service handle corresponding to each diagnostic service from the ODX file;
[0021] Calling the external API interface to obtain the execution data identified by the execution diagnosis service node value from the ODX file;
[0022] A diagnostic service request is generated based on the external API interface, the execution data and each of the diagnostic service handles, the diagnostic service request is sent to the ECU to be diagnosed, and a diagnostic service response returned by the ECU to be diagnosed is received and parsed to obtain a response parameter value.
[0023] Preferably, the execution data includes: the target diagnostic service currently to be executed, the request parameter set and the response parameter set to be set, the generating of the diagnostic service request based on the external API interface, the execution data and each of the diagnostic service handles, sending the diagnostic service request to the ECU to be diagnosed, receiving and parsing the diagnostic service response returned by the ECU to be diagnosed to obtain the response parameter value, including:
[0024] Based on the diagnostic service handle corresponding to the target diagnostic service and the external API interface, obtaining a request data handle and a response data handle of the target diagnostic service from the ODX file;
[0025] Calling the external API interface to obtain the request parameters corresponding to the request data handle from the ODX file, and using the request parameters to set each parameter to be set in the request parameter set to be set, to obtain the request parameter set that has been set;
[0026] Calling the external API interface to encapsulate the request parameter set to obtain a diagnostic service request, and sending the diagnostic service request to the ECU to be diagnosed;
[0027] Receiving a diagnostic service response returned by the ECU to be diagnosed;
[0028] Based on the external API interface and the response data handle, the diagnostic service response is parsed to obtain a response parameter value of each response parameter in the response parameter set.
[0029] Preferably, if the execution data further includes: variables to be assigned corresponding to the response parameters, after obtaining the response parameter value of each response parameter in the response parameter set, the method further includes:
[0030] The external API interface is called to assign the response parameter value of each response parameter in the response parameter set to the variable to be assigned corresponding to the response parameter.
[0031] Preferably, the method further comprises:
[0032] Parsing the custom message diagnostic service node in the diagnostic test sequence to obtain the current ECU to be diagnosed, the custom diagnostic service request and a plurality of variables to be assigned;
[0033] Calling the external API interface, sending the custom diagnostic service request to the current ECU to be diagnosed, and receiving the custom diagnostic service response returned by the current ECU to be diagnosed;
[0034] For each response parameter value in the custom diagnostic service response, a value is assigned to the corresponding variable to be assigned.
[0035] Preferably, after receiving and parsing the diagnostic service response returned by the ECU to be diagnosed to obtain the response parameter value, the method further includes:
[0036] The external API interface is called to uninstall the ODX file.
[0037] Preferably, after receiving and parsing the diagnostic service response returned by the ECU to be diagnosed to obtain the response parameter value, the method further includes:
[0038] The external API interface is called to disconnect the communication connection between the diagnostic device and the diagnosed ECU.
[0039] A second aspect of an embodiment of the present invention discloses a device for executing a diagnostic test sequence, which is applied to a diagnostic device. The device includes:
[0040] A loading unit, used for calling an external API interface to load an ODX file referenced by a diagnostic test sequence; the diagnostic test sequence is established based on the OTX standard and the ODX standard;
[0041] A first parsing unit is used to parse the acquisition communication channel node in the diagnostic test sequence to obtain the acquisition communication channel node value;
[0042] Creating a communication connection unit, used for calling the external API interface to obtain the communication channel data identified by the communication channel node value from the ODX file, and creating a communication connection between the diagnostic device and the ECU to be diagnosed based on the communication channel data;
[0043] A second parsing unit, configured to parse the diagnostic service node in the diagnostic test sequence to obtain a diagnostic service node value;
[0044] The diagnostic service execution unit is used to call the external API interface to obtain the diagnostic service data corresponding to the diagnostic service node value from the ODX file, generate a diagnostic service request based on the diagnostic service data and the external API interface, send the diagnostic service request to the ECU to be diagnosed, receive and parse the diagnostic service response returned by the ECU to be diagnosed to obtain a response parameter value.
[0045] Based on the above-mentioned method and device for executing a diagnostic test sequence provided by the embodiment of the present invention, an external API interface is called to load the ODX file referenced by the diagnostic test sequence; the diagnostic test sequence is established based on the OTX standard and the ODX standard; the communication channel node in the diagnostic test sequence is parsed to obtain the communication channel node value; the external API interface is called to obtain the communication channel data identified by the communication channel node value from the ODX file, and a communication connection between the diagnostic device and the ECU to be diagnosed is established based on the communication channel data; the diagnostic service node in the diagnostic test sequence is parsed to obtain the diagnostic service node value; the external API interface is called to obtain the diagnostic service data corresponding to the diagnostic service node value from the ODX file, a diagnostic service request is generated based on the diagnostic service data and the external API interface, the diagnostic service request is sent to the ECU to be diagnosed, and the diagnostic service response returned by the ECU to be diagnosed is received and parsed to obtain the response parameter value. In this solution, a set of external API interfaces is applied to solve the problem of executing the diagnostic test sequence nodes, so that developers can focus on the implementation of the diagnostic logic without writing too much code to implement the ODX file parsing and the communication between the ECU and the diagnostic device, so as to reduce the workload of developers and improve the development efficiency. BRIEF DESCRIPTION OF THE DRAWINGS
[0046] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying creative work.
[0047] Figure 1 A schematic diagram of an execution scenario of a diagnostic test sequence disclosed in an embodiment of the present invention;
[0048] Figure 2 This is a schematic diagram of the API definition of the ODX data parsing module disclosed in the embodiment of the present invention;
[0049] Figure 3 An example diagram of the inheritance structure of the ODX diagnostic data layer disclosed in an embodiment of the present invention;
[0050] Figure 4 A schematic diagram of API definition of a communication module disclosed in an embodiment of the present invention;
[0051] Figure 5 A flowchart of a method for executing a diagnostic test sequence disclosed in an embodiment of the present invention;
[0052] Figure 6 A logical schematic diagram of obtaining a communication channel node implementation disclosed in an embodiment of the present invention;
[0053] Figure 7 A logical schematic diagram of a communication parameter setting node implementation disclosed in an embodiment of the present invention;
[0054] Figure 8 A logical schematic diagram of creating a diagnostic service node implementation disclosed in an embodiment of the present invention;
[0055] Fig. 9 A logical schematic diagram of an implementation of a diagnosis service node disclosed in an embodiment of the present invention;
[0056] Fig.10 This is an example diagram of the location of request parameters disclosed in an embodiment of the present invention;
[0057] Fig.11 A logical schematic diagram of the implementation of closing a communication channel node value disclosed in an embodiment of the present invention;
[0058] Fig.12 A logical schematic diagram of the implementation of the custom message diagnosis service node disclosed in the embodiment of the present invention;
[0059] Fig.13 A structural diagram of a diagnostic test sequence execution device disclosed in an embodiment of the present invention. DETAILED DESCRIPTION
[0060] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.
[0061] In this application, the terms "comprises", "comprising" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprising a ..." does not exclude the presence of other identical elements in the process, method, article or device comprising the element.
[0062] First, the technical terms appearing in this application are explained as follows:
[0063] 1. OTX (ISO-13209 Open test sequence exchange format) is an open, standardized human- and machine-readable description format for diagnostic test sequences. The format standard is described in XML language and consists of two parts: core and extension.
[0064] The core part describes the basic structure of the OTX document and the specifications of the data model that can be used to form a test sequence. The OTX standard is designed to describe test sequences, and the test sequence itself is a program, so the core part of OTX follows the basic concepts shared by most programming languages, including data types in high-level development languages, process control structures such as loop branch judgment, basic operations on data types, declaration of constant variables, exception handling, and function calls.
[0065] The extension part is a grammatical structure that is extended by derivation based on the core, so as to formulate grammatical specifications that meet the functional requirements of different business scenarios. The extensions currently supported by the standard include vehicle diagnostic communication, vehicle diagnostic flash, vehicle diagnostic data, HMI (Human Machine Interface) human-computer interaction, event processing, time, mathematical operations, string operations, log records, etc. In this way, the extended grammatical specifications of OTX can be used to build test sequences for different business scenarios.
[0066] 2. ODX (ISO-22901-1 Open diagnostic data exchange) is an open and standardized ECU diagnostic specification description format. This format standard is described in XML language and consists of seven parts: diagnostic data, diagnostic communication parameters, vehicle model information, program refresh information, offline configuration information, function group diagnostic information, and multi-ECU service information. ODX can be used to describe the data model of all ECU diagnostic data, such as diagnostic fault codes, diagnostic services, request and response parameter structures of diagnostic services, communication parameter data structures, and ECU variant data.
[0067] It should be noted that when using the OTX diagnostic test sequence to test the diagnostic function of the automotive electronic control unit (ECU), it is necessary to rely on the current ECU diagnostic specifications and communicate with the ECU. During the test execution, the diagnostic specifications can be used to parse the data sent and received during the communication process, determine the correctness of the test sequence execution, and analyze the problems in the execution process. Since different controllers follow different diagnostic specifications, the diagnostic specifications of each controller need to be recorded in a separate file, so it is very necessary to define the above ODX format.
[0068] Currently, diagnostic engineers will create corresponding ODX files according to the diagnostic specifications of each ECU, which contain all the diagnostic information supported by the ECU: diagnostic services, diagnostic data structures, offline configuration information, diagnostic communication parameter information, and program refresh information. The number of ODX files required for a vehicle model is proportional to the number of ECUs it supports. Based on the ODX file, diagnostic engineers will reference some diagnostic services in the ODX file according to the specific test scenarios of some controllers, set the correct data and judgment conditions for their parameters, and arrange them in a specific order to build a reasonable diagnostic test sequence. After the application loads the OTX and ODX files for parsing, it can execute the corresponding test sequence to perform diagnostic tests on the vehicle or ECU.
[0069] like Figure 1 , which is a schematic diagram of an execution scenario of a diagnostic test sequence disclosed in an embodiment of the present invention, includes: an ODX data parsing module, a communication module, a diagnostic test sequence module and an ECU to be diagnosed.
[0070] Among them, the ODX data analysis module, communication module and diagnostic test sequence module are applied in the diagnostic equipment.
[0071] The ODX data parsing module calls the external API interface to parse the ODX file referenced in the diagnostic test sequence and obtain the ODX data in the ODX file.
[0072] The diagnostic test sequence module parses each node in the diagnostic test sequence, obtains the node value corresponding to each node, and obtains the ODX data corresponding to the node value from the ODX file. For each node, it performs the operation corresponding to the node based on the ODX data corresponding to the node, and finally generates a diagnostic service request.
[0073] It should be noted that the nodes in the OTX diagnostic communication extension standard are used to represent an execution step node. These nodes form the basis of the diagnostic test sequence and define the specific operations and expected results of each step. Through these nodes, the process of diagnostic testing can be accurately controlled to ensure the accuracy and consistency of execution.
[0074] The communication module establishes a communication connection with the ECU to be diagnosed by calling an external API interface, sends a diagnostic service request to the ECU to be diagnosed, and receives a diagnostic service response returned by the ECU to be diagnosed.
[0075] Specifically, the communication module sends a diagnostic service request to the ECU to be diagnosed based on an external API interface and a PDU (Protocol Data Unit), and simultaneously receives a diagnostic service response returned by the ECU to be diagnosed through the PDU.
[0076] It should be noted that PDU is the basic unit used in the field of computer networks and communications to describe data transmitted in protocols at different levels.
[0077] The ODX data parsing module obtains a response parameter set, that is, the diagnostic data of the ECU to be diagnosed, based on the external API interface and the ODX data parsing diagnostic service response.
[0078] The ODX data parsing module and the communication module both provide functional services through external API interfaces. The ODX data parsing module and the communication module respectively call multiple different external API interfaces to provide different functional services.
[0079] like Figure 2 As shown, it is a schematic diagram of the API definition of the ODX data parsing module disclosed in the embodiment of the present invention, wherein the ODX data parsing module provides an external API interface for functional services, and the functional services corresponding to the external API interface are detailed as follows:
[0080] The external API interfaces called by the ODX data parsing module are divided into four categories of interfaces, including system-related APIs, ECU-related APIs, diagnostic service-related APIs, and diagnostic service parameter-related APIs.
[0081] System-related APIs include:
[0082] a. Load ODX file (LoadODXProject): used to load ODX file, parse and process it so that the program can use the ODX data in it.
[0083] b. Unload ODX file (UnLoadODXProject): used to unload the loaded ODX file and release related resources.
[0084] ECU related APIs include:
[0085] a. Get Vehicle Information (GetVehicleInfo): used to obtain the ECU list defined in the ODX file. The ECU list includes the number of ECUs to be diagnosed and their corresponding names.
[0086] b. Create ECU logical link (CreateLogicalLink): In the ODX standard, LOGICAL-LINK is a node element that identifies an ECU. This API is used to obtain the LOGICAL-LINK corresponding to the specified ECU to be diagnosed, so as to establish a communication connection with the ECU to be diagnosed.
[0087] c. Switch ECU data source (ChangeLogicalLinkECU): In the ODX standard, the nodes describing ECU data are divided into five layers.
[0088] like Figure 3 As shown, it is an example diagram of the inheritance structure of the ODX diagnostic data layer disclosed in the embodiment of the present invention. There is an inheritance relationship between the levels of these nodes describing ECU data, namely PROTOCOL, FUNCTIONAL-GROUP, ECU-SHARED-DATA, BASE-VARIANT, and ECU-VARIANT.
[0089] Among them, BASE-VARIANT represents a basic ECU, while ECU-VARIANT represents different versions of ECU. After using the Create ECU Logical Connection API interface to obtain LOGICAL-LINK, you must explicitly specify the data source to be used, that is, BASE-VARIANT or ECU-VARIANT. This API is used to switch between BASE-VARIANT and ECU-VARIANT to meet the flexible switching of different versions of ECU data.
[0090] d. Get Diagnostic Service Collection (GetDiagComName): used to obtain the diagnostic service data collection related to the ECU to be diagnosed from the ODX file.
[0091] e. Get communication parameter information (GetCommParamVal): used to obtain the communication parameters related to the ECU to be diagnosed from the ODX file. These communication parameters are crucial for communicating with the ECU to be diagnosed, including communication protocol type, baud rate and other parameters. When calling this API, the caller needs to specify the number of communication parameters to be obtained and the ID of each parameter in order to accurately obtain the required communication parameter information.
[0092] f. Remove ECU logical link (RemoveLogicalLink): used to destroy the created ECU logical link and release related resources. It is used to disconnect the communication connection with the diagnosed ECU.
[0093] Diagnostic service related APIs include:
[0094] a. Create Diagnostic Service (CreateDiagCom): used to create a diagnostic service in order to obtain the diagnostic service handle, request data handle, and response data handle corresponding to the created diagnostic service.
[0095] Among them, the diagnostic service handle is a pointer to a diagnostic service reference or identifier for reference by the diagnostic test sequence.
[0096] Request data handle: is a reference or identifier pointing to the diagnostic service request data. When calling a diagnostic service, it is usually necessary to provide some input parameters or data to perform the corresponding operation. The request data handle allows the program or system to access or manipulate these request data in order to pass the necessary information to the diagnostic service.
[0097] Response data handle: is a reference or identifier pointing to the response data of the diagnostic service. When the diagnostic service is executed and generates the corresponding results or data, these data will be returned to the caller. The response data handle allows the program or system to access or operate these response data in order to process or analyze the results of the diagnostic service.
[0098] b. Remove Diagnostic Service (RemoveDiagCom): used to destroy the created diagnostic service and release related resources.
[0099] Diagnostic service parameter related APIs include:
[0100] a. Get request or response data for diagnostic services (GetDiagComReqRespHandle): used to obtain request data and response data for a specific diagnostic service.
[0101] Specifically, it is used to obtain the request data handle and the response data handle, and the request data and response data pointed to by the request data handle and the response data handle can be obtained.
[0102] b. Set the diagnostic service request or response PDU and automatically match the parameters: used to set the PDU content and automatically match the parameters when sending a diagnostic service request or receiving a diagnostic service response, simplify the calling process, and improve the accuracy and efficiency of diagnosis.
[0103] c. Get diagnostic service request or response PDU (GetReqRespPDU): After setting the physical value for each parameter in the request parameter set or response parameter set, the corresponding PDU can be generated by calling this API. This encapsulates the parameter set into PDU format for communication with the ECU.
[0104] d. Get the data referenced by the parameter (GetParamRefData): In the ODX standard, the request and response of the diagnostic service and the structure of some complex parameters are usually composed of multiple PARAM definitions. For PARAM of type VALUE, they will reference other data. This API is used to get the data referenced by PARAM of type VALUE.
[0105] e. Get the number of child parameters (GetChildParamCount): used to obtain the number of PARAMs of diagnostic service requests and responses and some complex parameters.
[0106] f. GetChildParamByIndex: used to get the PARAM of the specified index of the diagnostic service request and response and some complex parameters.
[0107] g. Get basic parameter information (GetParamBaseInfo): used to obtain basic information of PARAM or its referenced data, including parameter name, Byte start bit, Bit start bit, Bit length, data type, physical value and other information.
[0108] Set parameter physical value (SetParamPhyValue): used to set the physical value of PARAM or its referenced data.
[0109] like Figure 4 FIG. 1 is a schematic diagram of an API definition of a communication module disclosed in an embodiment of the present invention, wherein the communication module provides an external API interface for a functional service, and the functional service details corresponding to the external API interface are as follows:
[0110] a. Update system parameter values (UpdateConfig): used to update parameter values in communication.
[0111] b. Initialize the communication module (InitCommunication): Before starting communication, the communication module needs to be initialized to ensure the normal operation of the module.
[0112] c. Get the hardware communication device collection (GetModuleList): Get the hardware communication device collection identified by the system for subsequent communication operations.
[0113] d. Get channel information of hardware communication device (GetResourceByModuleID): Get channel information of specified hardware communication device, including channel type, channel status, etc.
[0114] e. Create a communication logic link (CreateCommInstance): Establish a communication connection with the ECU to realize data transmission and interaction.
[0115] f. Destroy the communication logic link (DestoryCommInstance): After the communication ends, the established communication connection needs to be destroyed to release resources.
[0116] g. Destroy the communication library (ReleaseCommunication): After the entire communication process is completed, the communication library used needs to be destroyed to release memory space.
[0117] h. Set the communication ECU address table (SetURIDTable): Set the address table for communication with the ECU to ensure accurate data transmission.
[0118] i. Set communication parameters (SetCommParam): Set corresponding communication parameters according to different communication protocols and device types to ensure the stability and reliability of communication.
[0119] j. Send Diagnostic Service (SendDiagService): Send a diagnostic service request PDU to the ECU, triggering the ECU to perform the corresponding diagnostic operation.
[0120] k. Get diagnostic service execution results and response PDU (GetServiceStatus): Receive the diagnostic service response PDU from the ECU and obtain the diagnostic results and related information.
[0121] l. Destroy diagnostic service (RemoveService): After the diagnosis is completed, the related diagnostic service needs to be destroyed to release resources.
[0122] like Figure 5 FIG. 1 is a flowchart of a method for executing a diagnostic test sequence disclosed in an embodiment of the present invention. The method is applied to a diagnostic device and mainly includes the following steps:
[0123] Step S101: calling an external API interface to load an ODX file referenced by a diagnostic test sequence.
[0124] Among them, the diagnostic test sequence is established based on the OTX standard and the ODX standard.
[0125] In the specific implementation process of step S101, the "load ODX file" API interface in the ODX data parsing module is called to load the ODX file referenced by the diagnostic test sequence.
[0126] Step S102: parsing the communication channel acquisition node in the diagnostic test sequence to obtain the communication channel acquisition node value.
[0127] It should be noted that the GetComChannel node belongs to the communication node in the parsing diagnostic test sequence, and the communication node also includes: a CloseComChannel node for disconnecting the communication connection between the diagnostic device and the ECU to be diagnosed, and a SetCommunicationParameters node for setting the communication parameters between the diagnostic device and the ECU to be diagnosed.
[0128] It can be understood that the node for closing the communication channel is executed when the ECU to be diagnosed completes the diagnosis, and the node for setting the communication parameters is executed after the diagnostic device establishes a communication connection with the ECU to be diagnosed, which is specifically described in the following embodiment.
[0129] Step S103: calling an external API interface to obtain communication channel data identified by a communication node value from the ODX file, and establishing a communication connection between the diagnostic device and the ECU to be diagnosed based on the communication channel data.
[0130] In step S103, the communication channel data includes: logical link information and data source information.
[0131] In the specific implementation, based on the external API interface and logical link information, a communication channel is created between the diagnostic device and the ECU to be diagnosed; based on the external API interface and data source information, the data source of the ECU to be diagnosed is switched to the specified data source, and it is determined that the communication connection between the diagnostic device and the specified data source in the ECU to be diagnosed is established.
[0132] See also Figure 6 , which is a logical diagram of obtaining a communication channel node implementation disclosed in an embodiment of the present invention, and the specific implementation logic is as follows:
[0133] a. Parse the communication channel node and obtain the values of the child nodes diag:identifier and diag:ecuVariantName. diag:identifier identifies the LOGICAL-LINK in the ODX file it references, and diag:ecuVariantName identifies the data source specified by the LOGICAL-LINK, which can be BASE-VARIANT or ECU-VARIANT.
[0134] b. Call the "Create ECU Logical Connection" API interface of the ODX data parsing module and create the specified LOGICAL-LINK according to the obtained diag:identifier value.
[0135] c. Call the "Switch ECU Data Source" API interface of the ODX data parsing module, and switch the data source of the ECU to be diagnosed to the specified data source according to the obtained diag:ecuVariantName value.
[0136] In one embodiment, after it is determined that the communication connection between the diagnostic device and the specified data source in the ECU to be diagnosed is established, it is also necessary to set the communication parameters between the diagnostic device and the ECU to be diagnosed, including communication protocol type, baud rate and other parameters. The details are as follows:
[0137] The communication parameter setting node in the diagnostic test sequence is parsed to obtain the communication parameter setting node value; the communication parameter setting node value includes: the name of the target communication parameter and the parameter value to be updated.
[0138] Based on the name of the target communication parameter and the external API interface, the target communication parameter is obtained from the ODX file, and the target communication parameter is updated based on the parameter value to be updated.
[0139] The external API interface is called to set the communication parameters used in the communication process between the diagnostic device and the ECU to be diagnosed as the updated target communication parameters.
[0140] See also Figure 7 , is a logical diagram of setting the communication parameter node implementation disclosed in an embodiment of the present invention, and the specific implementation logic is as follows:
[0141] a. Parse the Set Communication Parameters node and obtain the values of the subnodes diag:comChannel, diag:name, and diag:value. diag:comChannel identifies the ECU to be diagnosed, diag:name identifies the name of the target communication parameter to be updated, and diag:value identifies the parameter value to be updated.
[0142] b. Call the "Get Communication Parameter Information" API of the ODX data parsing module to obtain the corresponding ECU information and target communication parameters from the ODX file based on the obtained diag:comChannel and diag:name.
[0143] c. Update the parameter value of the target communication parameter according to the obtained diag:value.
[0144] d. Call the "Set Communication Parameters" API of the communication module to set the communication parameters used during the communication between the diagnostic device and the ECU to be diagnosed to the updated target communication parameters.
[0145] Step S104: parsing the diagnostic service node in the diagnostic test sequence to obtain a diagnostic service node value.
[0146] In step S104 , the diagnostic service node is used to execute the diagnostic service, including creating a diagnostic service (CreateDiagServiceByName) node, executing a diagnostic service (ExecuteDiagService) node, and executing a custom message diagnostic service (ExecuteHexDiagService) node.
[0147] Among them, creating a diagnostic service node is used to obtain the specified diagnostic service related data, executing the diagnostic service is used to generate and send a diagnostic service request and receive a diagnostic service response, and executing the custom message diagnostic service is used to send a custom message and receive a response.
[0148] Step S105: Call the external API interface to obtain the diagnostic service data corresponding to the diagnostic service node value from the ODX file, generate a diagnostic service request based on the diagnostic service data and the external API interface, send the diagnostic service request to the ECU to be diagnosed, receive and parse the diagnostic service response returned by the ECU to be diagnosed to obtain the response parameter value.
[0149] It can be understood that the diagnosis service node value includes: creating a diagnosis service node value and executing a diagnosis service node value.
[0150] The specific implementation process of step S104 is divided into the following two steps:
[0151] The first step is to obtain the diagnostic service handle corresponding to each diagnostic service from the ODX file based on the external API interface and the creation of the diagnostic service node value.
[0152] See also Figure 8 , which is a logical diagram of creating a diagnostic service node according to an embodiment of the present invention. The specific actual logic is as follows:
[0153] a. Parse and create the diagnostic service node, and obtain the values of the subnodes diag:comChannel and diag:name. diag:comChannel identifies the ECU to be diagnosed, and diag:name identifies the name of the diagnostic service.
[0154] b. Call the "Create Diagnostic Service" API of the ODX data parsing module, and obtain the specified diagnostic service handle from the ODX file based on the diag:comChannel and diag:name obtained in a.
[0155] It is understandable that the ECU to be diagnosed can execute multiple diagnostic services at the same time. Accordingly, diag:name identifies multiple diagnostic service names, and the diagnostic service handles corresponding to the multiple diagnostic services are obtained from the ODX file.
[0156] The second step is to call the external API interface and obtain the execution data of the diagnostic service node value identifier from the ODX file. Generate a diagnostic service request based on the external API interface, execution data and each diagnostic service handle, send the diagnostic service request to the ECU to be diagnosed, receive and parse the diagnostic service response returned by the ECU to be diagnosed to obtain the response parameter value.
[0157] More specifically, the execution data includes: the target diagnostic service that needs to be executed currently, the request parameter set and the response parameter set to be set.
[0158] Based on the diagnostic service handle and external API interface corresponding to the target diagnostic service, the request data handle and response data handle of the target diagnostic service are obtained from the ODX file.
[0159] An external API interface is called to obtain request parameters corresponding to the request data handle from the ODX file, and the request parameters are used to set each parameter to be set in the request parameter set to be set, so as to obtain a request parameter set that has been set.
[0160] The external API interface is called to encapsulate the request parameter set to obtain a diagnostic service request, and the diagnostic service request is sent to the ECU to be diagnosed, and the diagnostic service response returned by the ECU to be diagnosed is received.
[0161] Based on the external API interface and the response data handle, the diagnostic service response is parsed to obtain the response parameter value of each response parameter in the response parameter set.
[0162] In one embodiment, the execution data includes: variables to be assigned corresponding to each response parameter. After obtaining the response parameter value of each response parameter, an external API interface is called to assign the response parameter value of each response parameter in the response parameter set to the variables to be assigned corresponding to the response parameter.
[0163] See also Fig. 9 , is a logical diagram of the implementation of the diagnostic service node disclosed in the embodiment of the present invention. The specific real logic is as follows:
[0164] a. Parse the execution diagnostic service node and obtain the child nodes of the execution diagnostic service node, including: child node diag:executeAsync, child node diag:suppressPositiveResponse, child node diag:diagService, child node diag:requestParameters, and child node diag:responseParameters.
[0165] Among them, diag:executeAsync indicates whether the current multiple target diagnostic services are executed synchronously, diag:suppressPositiveResponse indicates whether a reply response is required when the response is positive, diag:diagService indicates the target diagnostic service that needs to be executed currently, and multiple diagnostic services can be identified, diag:requestParameters indicates the request parameter set to be set for the target diagnostic service, and diag:responseParameters indicates the response parameter set for the target diagnostic service.
[0166] b. Parse the diag:requestParameters node and loop to get the child node diag:requestParam. Parse each diag:requestParam node and get its child nodes diag:value and diag:path. diag:path includes two types: stepByIndex and stepByName.
[0167] Among them, diag:requestParam identifies the parameter in the request parameter set to be set, diag:value identifies the physical value of the parameter, and diag:path identifies the position of the parameter in the request parameter set to be set, which can be identified by the sequence index stepByIndex and the name index stepByName.
[0168] See also Fig.10 , which is an example diagram of the location of request parameters disclosed in an embodiment of the present invention, wherein DiagService represents a diagnostic service, Request represents request data, and the diagnostic service includes request data.
[0169] The request data consists of multiple request parameters, including ReqParam1, ReqParam_Struct, and ReqParam_Array.
[0170] The request parameter ReqParam_Struct is composed of other parameters, including StructParam1 and StrctParam2. The parameter ReqParam_Array is also composed of other parameters, such as Fig.10 Multiple Params listed in, each Param has its corresponding serial number such as Fig.10 0 or 1 in .
[0171] Fig.10 The arrows corresponding to the codes on the right indicate how the parameters are positioned in this hierarchical relationship, that is, the positioning of these parameter names or serial numbers.
[0172] For example:
[0173] <diag:path>
[0174] <stepbyname xsi:type="StringLiteral" value="ReqParam1">
[0175] < / stepbyname> < / diag:path>
[0176] Here is an example of a code snippet in XML format.
[0177] <diag:path>The element is a path node that describes the path to locate.
[0178] The stepByName tag is used to indicate indexing by name. xsi:type="StringLiteral" is an attribute that specifies that the type of the node value is a string literal.
[0179] value="ReqParam1" is the value of this node, that is, the name of the request parameter to be queried is ReqParam1.
[0180] c. Parse the diag:responseParameters node, get the child node diag:name, and loop to get the child node diag:responseParam. Parse each diag:responseParam node, get its child nodes diag:target and diag:path, and diag:path includes two types: stepByIndex and stepByName.
[0181] Among them, diag:name identifies the target response name in the current diagnostic service response set, diag:target identifies the variable to be assigned that receives the current response parameter value, and diag:path identifies the position of the parameter in the response parameter set, which can be identified by the sequence index stepByIndex and the name index stepByName.
[0182] It can be understood that the response parameter set can be obtained from the ODX file according to the target response name.
[0183] d. Call the "Get request or response data of diagnostic service" API of the ODX parsing module, and obtain the request data handle and response data handle of the specified diagnostic service according to the obtained diag:diagService.
[0184] e. Based on the request data handle obtained in d and the physical value and position information of each request parameter in the request parameter set obtained in b, call the "Get parameter referenced data", "Get sub-parameter number", "Get sub-parameter by index", "Get parameter basic information" and "Set parameter physical value" APIs of the ODX parsing module to set the physical value of each request parameter in the request parameter set.
[0185] f. Call the "Get Diagnostic Service Request or Response PDU" API of the ODX parsing module to obtain the request PDU based on the request data handle obtained in d.
[0186] g. Call the "Send Diagnostic Service" API of the communication module, and send the request PDU obtained in f to the target ECU according to diag:executeAsync and diag:suppressPositiveResponse obtained in a, and receive the response PDU from the ECU.
[0187] h. Call the "Set diagnostic service request or response PDU and automatically match parameters" API of the ODX parsing module, obtain the response parameter set corresponding to the response data handle according to the response data handle obtained in d and the response PDU obtained in g, parse the response PDU based on the response parameter set to obtain each response parameter value, and automatically match the response parameter value of each response parameter in the response parameter set.
[0188] i. According to the position information of each parameter in the response parameter set obtained in c and the name of the variable that receives its physical value, call the "Get parameter referenced data", "Get sub-parameter number", "Get sub-parameter by index" and "Get parameter basic information" APIs of the ODX parsing module to obtain the response parameter value of each response parameter and assign it to the corresponding variable to be assigned.
[0189] In one embodiment, after step S104 is executed, the communication channel node is closed and the communication channel node value is closed, and based on the communication channel node value and the external API interface, the communication connection between the diagnostic device and the diagnosed ECU is disconnected.
[0190] See also Fig.11 , which is a logical diagram of the implementation of closing the communication channel node value disclosed in the embodiment of the present invention, and the specific implementation logic is as follows:
[0191] a. Parse the Close Communication Channel node and obtain the value of the child node diag:comChannel. diag:comChannel identifies the communication channel that needs to be closed, that is, the communication channel between the diagnostic device and the diagnosed ECU.
[0192] b. Call the "Remove ECU Logical Connection" API of the ODX data parsing module and destroy the specified LOGICAL-LINK according to the obtained diag:comChannel.
[0193] In one embodiment, a custom message diagnostic service node in a diagnostic test sequence is parsed to obtain a current ECU to be diagnosed, a custom diagnostic service request, and a plurality of variables to be assigned, an external API interface is called, a custom diagnostic service request is sent to the current ECU to be diagnosed, and a custom diagnostic service response returned by the current ECU to be diagnosed is received, and each response parameter value in the custom diagnostic service response is assigned to the corresponding variable to be assigned.
[0194] See also Fig.12 , is a logical diagram of the implementation of the custom message diagnosis service node disclosed in the embodiment of the present invention, and the specific implementation logic is as follows:
[0195] a. Parse the custom message diagnostic service node and obtain the values of the child nodes diag:comChannel, diag:hexRequest, and diag:hexResponse.
[0196] Among them, diag:comChannel identifies the current ECU to be diagnosed, diag:hexRequest identifies the custom diagnostic service request PDU, and diag:hexResponse identifies the variable name that receives the current diagnostic service response PDU, that is, it identifies multiple variables to be assigned.
[0197] b. Call the "Send Diagnostic Service" API of the communication module, and send a custom diagnostic service request PDU to the current ECU to be diagnosed based on the diag:comChannel and diag:hexRequest obtained in a, and receive the custom diagnostic service response PDU of the current ECU to be diagnosed.
[0198] c. Assign the response PDU obtained in b to the variable to be assigned with the diag:hexResponse identifier obtained in a.
[0199] Based on the execution method of a diagnostic test sequence disclosed in the above embodiment of the present invention, an external API interface is called to load the ODX file referenced by the diagnostic test sequence; the diagnostic test sequence is established based on the OTX standard and the ODX standard; the communication channel node in the diagnostic test sequence is parsed to obtain the communication channel node value; the external API interface is called to obtain the communication channel data identified by the communication channel node value from the ODX file, and a communication connection between the diagnostic device and the ECU to be diagnosed is established based on the communication channel data; the diagnostic service node in the diagnostic test sequence is parsed to obtain the diagnostic service node value; the external API interface is called to obtain the diagnostic service data corresponding to the diagnostic service node value from the ODX file, a diagnostic service request is generated based on the diagnostic service data and the external API interface, a diagnostic service request is sent to the ECU to be diagnosed, and the diagnostic service response returned by the ECU to be diagnosed is received and parsed to obtain the response parameter value. In this solution, a set of external API interfaces is applied to solve the problem of diagnostic test sequence node execution, so that developers can focus on the implementation of diagnostic logic without writing too much code to implement ODX file parsing and communication with ECU, so as to reduce the workload of developers and improve development efficiency.
[0200] Corresponding to the method for executing a diagnostic test sequence disclosed in the above embodiment of the present invention, as Fig.13 FIG. 1 is a structural diagram of a diagnostic test sequence execution device disclosed in an embodiment of the present invention. The device is applied to a diagnostic device and specifically includes:
[0201] The loading unit 1301 is used to call an external API interface to load an ODX file referenced by a diagnostic test sequence; the diagnostic test sequence is established based on the OTX standard and the ODX standard.
[0202] The first parsing unit 1302 is used to parse the acquired communication channel node in the diagnostic test sequence to obtain the acquired communication channel node value.
[0203] The communication connection creation unit 1303 is used to call an external API interface to obtain the communication channel data identified by the communication channel node value from the ODX file, and to create a communication connection between the diagnostic device and the ECU to be diagnosed based on the communication channel data.
[0204] The second parsing unit 1304 is used to parse the diagnostic service node in the diagnostic test sequence to obtain the diagnostic service node value.
[0205] The execution diagnostic service unit 1305 is used to call the external API interface to obtain the diagnostic service data corresponding to the diagnostic service node value from the ODX file, generate a diagnostic service request based on the diagnostic service data and the external API interface, send the diagnostic service request to the ECU to be diagnosed, receive and parse the diagnostic service response returned by the ECU to be diagnosed to obtain the response parameter value.
[0206] The specific implementation process has been described in the above-mentioned embodiment of the method for executing the diagnostic test sequence, and will not be repeated here.
[0207] Based on the execution device of a diagnostic test sequence disclosed in the above embodiment of the present invention, an external API interface is called to load the ODX file referenced by the diagnostic test sequence; the diagnostic test sequence is established based on the OTX standard and the ODX standard; the communication channel node in the diagnostic test sequence is parsed to obtain the communication channel node value; the external API interface is called to obtain the communication channel data identified by the communication channel node value from the ODX file, and a communication connection between the diagnostic device and the ECU to be diagnosed is established based on the communication channel data; the diagnostic service node in the diagnostic test sequence is parsed to obtain the diagnostic service node value; the external API interface is called to obtain the diagnostic service data corresponding to the diagnostic service node value from the ODX file, a diagnostic service request is generated based on the diagnostic service data and the external API interface, a diagnostic service request is sent to the ECU to be diagnosed, and the diagnostic service response returned by the ECU to be diagnosed is received and parsed to obtain the response parameter value. In this solution, a set of external API interfaces is applied to solve the problem of diagnostic test sequence node execution, so that developers can focus on the implementation of diagnostic logic without writing too much code to implement ODX file parsing and communication with ECU, so as to reduce the workload of developers and improve development efficiency.
[0208] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can refer to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system or system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can refer to the partial description of the method embodiment. The system and system embodiments described above are merely schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without creative work.
[0209] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.
[0210] The above description of the disclosed embodiments enables one skilled in the art to implement or use the present invention. Various modifications to these embodiments will be apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but rather to the widest scope consistent with the principles and novel features disclosed herein.< / diag:path>
Claims
1. A method for executing a diagnostic test sequence, characterized in that: Applied to diagnostic equipment, the method comprises: Calling an external API interface to load an ODX file referenced by a diagnostic test sequence; the diagnostic test sequence is established based on the OTX standard and the ODX standard; Parse the Get Communication Channel node in the diagnostic test sequence to obtain the Get Communication Channel node value; Calling the external API interface to obtain the communication channel data identified by the communication channel node value from the ODX file, and establishing a communication connection between the diagnostic device and the ECU to be diagnosed based on the communication channel data; Parsing the diagnostic service node in the diagnostic test sequence to obtain a diagnostic service node value; The external API interface is called to obtain diagnostic service data corresponding to the diagnostic service node value from the ODX file, a diagnostic service request is generated based on the diagnostic service data and the external API interface, the diagnostic service request is sent to the ECU to be diagnosed, and the diagnostic service response returned by the ECU to be diagnosed is received and parsed to obtain a response parameter value.
2. The method according to claim 1, characterized in that The communication channel data includes: logical link information and data source information. The communication connection between the diagnostic device and the ECU to be diagnosed is established based on the communication data to obtain the logical link between the diagnostic device and the ECU to be diagnosed, including: Creating a communication channel between the diagnostic device and the ECU to be diagnosed based on the external API interface and the logical link information; Based on the external API interface and the data source information, the data source of the ECU to be diagnosed is switched to a designated data source, and it is determined that the communication connection between the diagnostic device and the designated data source in the ECU to be diagnosed is established.
3. The method according to claim 2, characterized in that After determining that the communication connection between the diagnostic device and the designated data source in the ECU to be diagnosed is established, the method further includes: Parsing the communication node setting in the diagnostic test sequence to obtain the communication node setting value; the communication node setting value includes: the name of the target communication parameter and the parameter value to be updated; Based on the name of the target communication parameter and the external API interface, the target communication parameter is obtained from the ODX file, and the target communication parameter is updated based on the parameter value to be updated; The external API interface is called to set the communication parameters used in the communication process between the diagnostic device and the ECU to be diagnosed to the updated target communication parameters.
4. The method according to claim 1, characterized in that: The diagnostic service node value includes: creating a diagnostic service node value and executing a diagnostic service node value. Accordingly, the calling of the external API interface obtains diagnostic service data corresponding to the diagnostic service node value from the ODX file, generates a diagnostic service request based on the diagnostic service data and the external API interface, sends the diagnostic service request to the ECU to be diagnosed, receives and parses the diagnostic service response returned by the ECU to be diagnosed to obtain a response parameter value, including: Based on the external API interface and the created diagnostic service node value, obtaining the diagnostic service handle corresponding to each diagnostic service from the ODX file; Calling the external API interface to obtain the execution data identified by the execution diagnosis service node value from the ODX file; A diagnostic service request is generated based on the external API interface, the execution data and each of the diagnostic service handles, the diagnostic service request is sent to the ECU to be diagnosed, and a diagnostic service response returned by the ECU to be diagnosed is received and parsed to obtain a response parameter value.
5. The method according to claim 4, characterized in that The execution data includes: a target diagnostic service that needs to be executed currently, a request parameter set and a response parameter set to be set, generating a diagnostic service request based on the external API interface, the execution data and each of the diagnostic service handles, sending the diagnostic service request to the ECU to be diagnosed, receiving and parsing the diagnostic service response returned by the ECU to be diagnosed to obtain a response parameter value, including: Based on the diagnostic service handle corresponding to the target diagnostic service and the external API interface, obtaining a request data handle and a response data handle of the target diagnostic service from the ODX file; Calling the external API interface to obtain the request parameters corresponding to the request data handle from the ODX file, and using the request parameters to set each parameter to be set in the request parameter set to be set, to obtain the request parameter set that has been set; Calling the external API interface to encapsulate the request parameter set to obtain a diagnostic service request, and sending the diagnostic service request to the ECU to be diagnosed; Receiving a diagnostic service response returned by the ECU to be diagnosed; Based on the external API interface and the response data handle, the diagnostic service response is parsed to obtain a response parameter value of each response parameter in the response parameter set.
6. The method according to claim 5, characterized in that If the execution data further includes: variables to be assigned corresponding to the response parameters, then after obtaining the response parameter values of each response parameter in the response parameter set, the method further includes: The external API interface is called to assign the response parameter value of each response parameter in the response parameter set to the variable to be assigned corresponding to the response parameter.
7. The method according to any one of claims 1 to 6, characterized in that: The method further comprises: Parsing the custom message diagnostic service node in the diagnostic test sequence to obtain the current ECU to be diagnosed, the custom diagnostic service request and a plurality of variables to be assigned; Calling the external API interface, sending the custom diagnostic service request to the current ECU to be diagnosed, and receiving the custom diagnostic service response returned by the current ECU to be diagnosed; For each response parameter value in the custom diagnostic service response, a value is assigned to the corresponding variable to be assigned.
8. The method according to any one of claims 1 to 6, characterized in that: After receiving and parsing the diagnostic service response returned by the ECU to be diagnosed to obtain a response parameter value, the method further includes: The external API interface is called to uninstall the ODX file.
9. The method according to any one of claims 1 to 6, characterized in that: After receiving and parsing the diagnostic service response returned by the ECU to be diagnosed to obtain a response parameter value, the method further includes: The external API interface is called to disconnect the communication connection between the diagnostic device and the diagnosed ECU.
10. A device for executing a diagnostic test sequence, characterized in that: Applied to diagnostic equipment, the device comprises: A loading unit, used for calling an external API interface to load an ODX file referenced by a diagnostic test sequence; the diagnostic test sequence is established based on the OTX standard and the ODX standard; A first parsing unit is used to parse the acquisition communication channel node in the diagnostic test sequence to obtain the acquisition communication channel node value; Creating a communication connection unit, used for calling the external API interface to obtain the communication channel data identified by the communication channel node value from the ODX file, and creating a communication connection between the diagnostic device and the ECU to be diagnosed based on the communication channel data; A second parsing unit, configured to parse the diagnostic service node in the diagnostic test sequence to obtain a diagnostic service node value; The diagnostic service execution unit is used to call the external API interface to obtain the diagnostic service data corresponding to the diagnostic service node value from the ODX file, generate a diagnostic service request based on the diagnostic service data and the external API interface, send the diagnostic service request to the ECU to be diagnosed, receive and parse the diagnostic service response returned by the ECU to be diagnosed to obtain a response parameter value.