Methods, apparatus and related equipment for processing open diagnostic data exchange files

Abstract

This application discloses a method, apparatus, and related equipment for processing Open Diagnostic Data Exchange (ODX) files, relating to the field of automotive technology. The method includes: acquiring an Open Diagnostic Data Exchange (ODX) file set for a vehicle, and acquiring a target ODX file. The ODX file set includes at least one ODX file, each ODX file describing the diagnostic specifications of a corresponding Electronic Control Unit (ECU), and each ODX file including diagnostic service information and diagnostic data structure information for the corresponding ECU; acquiring diagnostic data from each ODX file based on the ODX file set, and acquiring the diagnostic service information, diagnostic data structure information, and diagnostic service inheritance relationship information for each ECU; integrating the diagnostic service information and diagnostic data structure information of each ECU into the target ODX file according to the diagnostic service inheritance relationship information to obtain an integrated target ODX file, which is used for diagnostic testing.

Description

Technical Field

[0001] This application belongs to the field of automotive technology, and in particular relates to a method, apparatus and related equipment for processing open diagnostic data exchange files. Background Technology

[0002] In the automotive industry, diagnostic testing is a crucial part of vehicle diagnostic development. Diagnostic test sequences can be created based on the Open Test Sequence Exchange Format (OTX) protocol, enabling vehicle diagnostic testing. However, when using these sequences, it is also necessary to rely on Electronic Control Unit (ECU) diagnostic specifications to determine the correctness of the test sequence execution and analyze any problems encountered during execution.

[0003] Currently, diagnostic test engineers create corresponding Open Diagnostic Data Exchange (ODX) files based on the diagnostic specifications for each ECU, which contain all the diagnostic specification information supported by the ECU. However, ODX files contain redundant information, which consumes unnecessary Central Processing Unit (CPU) and memory resources during diagnostic testing, resulting in low diagnostic testing efficiency. Summary of the Invention

[0004] This application provides a method, apparatus, and related equipment and storage medium for processing open diagnostic data exchange files, which can improve diagnostic testing efficiency without occupying unnecessary central processing unit and memory resources.

[0005] In a first aspect, embodiments of this application provide a method for processing open diagnostic data exchange files, the method comprising:

[0006] The system acquires the Open Diagnostic Data Exchange (ODX) file set of the vehicle and acquires the target ODX file. The ODX file set includes at least one ODX file, each ODX file is used to describe the diagnostic specifications of the corresponding electronic control unit (ECU), and each ODX file includes diagnostic service information and diagnostic data structure information corresponding to the ECU.

[0007] Based on the ODX file set, obtain the diagnostic data of each ODX file, and obtain the diagnostic service information, diagnostic data structure information and diagnostic service inheritance relationship information of each ECU;

[0008] The diagnostic service information and diagnostic data structure information of each ECU are integrated into the target ODX file according to the inheritance relationship information of each diagnostic service to obtain the integrated target ODX file, which is used for diagnostic testing.

[0009] Secondly, embodiments of this application provide an apparatus for processing open diagnostic data exchange files, the apparatus comprising:

[0010] The first acquisition module is used to acquire the Open Diagnostic Data Exchange (ODX) file set of the vehicle and to acquire the target ODX file. The ODX file set includes at least one ODX file, each ODX file is used to describe the diagnostic specifications of the corresponding electronic control unit (ECU), and each ODX file includes diagnostic service information and diagnostic data structure information corresponding to the ECU.

[0011] The second acquisition module is used to acquire diagnostic data of each ODX file according to the ODX file set, and to acquire diagnostic service information, diagnostic data structure information and diagnostic service inheritance relationship information of each ECU.

[0012] An integration module is used to integrate the diagnostic service information and diagnostic data structure information of each ECU into the target ODX file according to the inheritance relationship information of each diagnostic service, so as to obtain an integrated target ODX file, which is used for diagnostic testing.

[0013] Thirdly, embodiments of this application provide an electronic device, the device including: a processor and a memory storing computer program instructions; the processor, when executing the computer program instructions, implements the open diagnostic data exchange file processing method as described above.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the open diagnostic data exchange file processing method described in any of the above claims.

[0015] The method, apparatus, and related equipment for processing Open Diagnostic Data Exchange (ODX) files according to embodiments of this application can integrate the diagnostic service information and diagnostic data structure information of each ECU in the vehicle's Open Diagnostic Data Exchange (ODX) file set into the target ODX file according to the inheritance relationship information of each diagnostic service. The integrated target ODX file can be used for diagnostic testing. Thus, in this embodiment, by integrating the diagnostic service information and diagnostic data structure information of the ECU used for diagnostic testing into the target ODX file, redundant information is eliminated. Therefore, unnecessary central processing unit and memory resources are not occupied during vehicle diagnostic testing, thereby improving diagnostic testing efficiency. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating a method for processing open diagnostic data exchange files according to an embodiment of this application;

[0018] Figure 2 This is a schematic diagram of the process for extracting the mapping relationship between the name information of the target ECU and the name of the diagnostic service, provided in an embodiment of this application.

[0019] Figure 3 This is a schematic diagram of the process of searching by ID provided in an embodiment of this application;

[0020] Figure 4 This is a schematic diagram of the process of searching by SHORT-NAME provided in an embodiment of this application;

[0021] Figure 5 This is a schematic diagram illustrating the inheritance relationship of diagnostic levels provided in the embodiments of this application;

[0022] Figure 6 This is a flowchart illustrating the process of trimming and recombining diagnostic data in an ODX file set provided in an embodiment of this application;

[0023] Figure 7 This is a schematic diagram of the structure of the open diagnostic data exchange file processing device provided in the embodiments of this application;

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

[0025] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0026] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0027] The Open Test Sequence Exchange Format (ISO-13209) is an open, standardized, human-machine-readable description format for diagnostic test sequences. This standard uses Extensible Markup Language (XML) and consists of a core and extensions. The core describes the basic structure of the OTX document and the specifications for the data model used to compose the test sequence. Designed to describe test sequences, which are themselves programs, the OTX core adheres to the fundamental concepts common to most programming languages, including data types, flow control structures such as loops and branching statements, basic data type operations, constant variable declarations, exception handling, and function calls. The extensions build upon the core, expanding the syntax to meet the functional requirements of different business scenarios. Currently, the standard supports extensions such as automotive diagnostic communication, automotive diagnostic flashing, automotive diagnostic data, Human Machine Interface (HMI), event handling, time, mathematical operations, string manipulation, and log recording. This allows you to use the extended syntax specification of OTX to build test sequences for different business scenarios.

[0028] Diagnostic testing is a crucial part of vehicle diagnostic development in the automotive industry. The OTX protocol allows for the creation of universal diagnostic test sequences applicable to the automotive sector. When testing the diagnostic functions of an ECU using OTX diagnostic test sequences, it is also necessary to rely on the diagnostic specification data source of the current Electronic Control Unit (ECU). This data source contains information such as the diagnostic services and communication protocols supported by the current ECU. During test execution, the transmitted and received data in the communication process can be parsed through the diagnostic data source to determine the correctness of the test sequence execution and analyze any problems encountered. Since different ECUs follow different diagnostic specifications, each ECU's diagnostic specifications need to be recorded in a separate file. Therefore, defining a standardized, easily interactive format for describing ECU diagnostic specifications is essential.

[0029] The Open Diagnostic Data Exchange (ODX) format (ISO-22901-1) is an open, standardized format for describing ECU diagnostic specifications. This standard uses XML and consists of seven parts: diagnostic data, diagnostic communication parameters, vehicle model information, program update information, off-line configuration information, functional group diagnostic information, and multi-ECU service information. ODX can describe the data model of all ECU diagnostic data, such as diagnostic fault codes, diagnostic services, the request and response parameter structure of diagnostic services, communication parameter data, and ECU variant data.

[0030] Currently in the automotive industry, diagnostic test engineers create corresponding ODX files based on the diagnostic specifications of each ECU. These files contain all the diagnostic information supported by the ECU, including diagnostic services, diagnostic data structures, offline configuration information, diagnostic communication parameters, and program update information. The number of ODX files required for a vehicle model is directly proportional to the number of ECUs it supports. Based on the ODX files, diagnostic engineers, according to specific test scenarios for certain ECUs, reference diagnostic services within the ODX files, setting the correct data and judgment conditions, and arranging them in a specific order to construct a reasonable diagnostic test sequence. After the application loads and parses the ODX and ODX files, it can execute the corresponding test sequence to perform diagnostic tests on the vehicle or ECU.

[0031] Because both OTX and ODX are standard open description formats, the diagnostic test sequences built upon them 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 significantly reduces the development work of upper-level application tools, accelerates vehicle model iteration development, and thus saves substantial economic and human resource costs.

[0032] While diagnostic test sequences built using OTX and ODX standards are highly versatile and can be used across different departments and even companies, there are certain limitations when applying ODX files. Because the ODX file set is a data collection describing all diagnostic specification information for an ECU, while the diagnostic test sequence built using OTX is designed for specific ECU functionalities, it typically only uses a portion of the diagnostic service information and diagnostic data structure information from the ODX file set. For the diagnostic test sequence, the unused data in the ODX file set is equivalent to redundant information. In a vehicle-level diagnostic test sequence, if the ODX files of all ECUs are introduced, the overall amount of redundant data will increase significantly with the number of ECUs.

[0033] After the application running the diagnostic test sequence loads the OTX and ODX files, it can parse and execute the diagnostic test sequence to complete the functional test of the ECU. However, because the ODX file contains redundant data, the application will consume central processing unit (CPU) and memory resources when loading resources for diagnostic testing. This waste of resources is more obvious when performing whole-vehicle level ECU diagnostic testing, resulting in low diagnostic testing efficiency.

[0034] To address the problems of the prior art, embodiments of this application provide a method, apparatus, and related equipment for processing open diagnostic data exchange files. The method for processing open diagnostic data exchange files provided in this application embodiment will be described first below.

[0035] Figure 1 A flowchart illustrating a method for processing open diagnostic data exchange files according to an embodiment of this application is shown. Figure 1 As shown, a method for processing open diagnostic data exchange files may include the following steps S101 to S103.

[0036] S101. Obtain the vehicle's Open Diagnostic Data Exchange (ODX) file set and obtain the target ODX file. The ODX file set includes at least one ODX file. Each ODX file is used to describe the diagnostic specifications of the corresponding Electronic Control Unit (ECU). Each ODX file includes the diagnostic service information and diagnostic data structure information of the corresponding ECU.

[0037] S102. Based on the ODX file set, obtain the diagnostic data of each ODX file, as well as the diagnostic service information, diagnostic data structure information, and diagnostic service inheritance relationship information of each ECU.

[0038] S103. The diagnostic service information and diagnostic data structure information of each ECU are integrated into the target ODX file according to the inheritance relationship information of each diagnostic service to obtain the integrated target ODX file. The integrated target ODX file is used for diagnostic testing.

[0039] The open diagnostic data exchange (ODX) file processing method of this application embodiment can integrate the diagnostic service information and diagnostic data structure information of each ECU in the vehicle's open diagnostic data exchange (ODX) file set into a target ODX file according to the inheritance relationship information of each diagnostic service. The integrated target ODX file can be used for diagnostic testing. Thus, in this embodiment, by integrating the diagnostic service information and diagnostic data structure information of the ECU used for diagnostic testing into the target ODX file, redundant information is eliminated. Therefore, unnecessary central processing unit and memory resources are not occupied during vehicle diagnostic testing, thereby improving diagnostic testing efficiency.

[0040] In S101, the aforementioned ODX file set is a data collection describing diagnostic specification information for all ECUs in the vehicle. It may include at least one ODX file, where each ODX file describes the diagnostic specifications for its corresponding ECU. Each ODX file includes diagnostic service information and diagnostic data structure information for the corresponding ECU. The diagnostic service information can be used to arrange and build a reasonable diagnostic test sequence in a specific order for diagnostic testing. The diagnostic data structure information can be used to interpret the type information of the diagnostic data definition, that is, through its operation rules, the vehicle diagnostic data can be converted from bus values ​​to physical values.

[0041] The aforementioned acquisition of the vehicle's Open Diagnostic Data Exchange (ODX) file set can be achieved by obtaining the ODX file set of the vehicle to be diagnosed (i.e., the collection of all ODX files of the vehicle to be diagnosed) through a standard architecture diagnostic instrument.

[0042] The target ODX file mentioned above can be a blank ODX file, used to store the diagnostic data extracted later (including diagnostic service information and diagnostic data structure information).

[0043] To obtain the target ODX file, you can create a new empty ODX file.

[0044] In S102, the diagnostic data of the ODX file may include diagnostic service information, diagnostic data structure information and diagnostic service inheritance relationship information of the ECU described by the ODX file. In addition, it may also include diagnostic layer name information, diagnostic service request information, diagnostic service response information and diagnostic service negative response information of the ECU described by the ODX file.

[0045] The above-mentioned method of obtaining diagnostic data from each ODX file based on the ODX file set can, for example, involve loading the ODX file set, traversing the information of the diagnostic data layer in each ODX file, and obtaining the diagnostic data of each ODX file. The diagnostic data layer can include five different types of layers: the common data layer ECU-SHARED-DATA, the protocol data layer PROTOCOL, the FUNCTIONAL-GROUP functional group data layer, the basic data layer BASE-VARIANT, and the ECU derived data layer ECU-VARIANT. Data reuse can be achieved between each layer according to the data inheritance and import relationships required by the specifications.

[0046] The above-mentioned acquisition of diagnostic service information, diagnostic data structure information and diagnostic service inheritance relationship information of each ECU can be achieved by extracting and integrating the diagnostic service information, diagnostic data structure information and diagnostic service inheritance relationship information from the diagnostic data of each ODX file on an ECU-by-ECU basis.

[0047] In S103, the aforementioned diagnostic service inheritance relationship information is used to describe the diagnostic service inheritance relationship between each ECU.

[0048] The above-described method integrates the diagnostic service information and diagnostic data structure information of each ECU into the target ODX file according to the diagnostic service inheritance relationship information, resulting in an integrated target ODX file. For example, it can be constructed in the target ODX file according to the diagnostic service inheritance relationship information indicated by the diagnostic service inheritance relationship information between each ECU in the ODX file set, and then integrate the diagnostic service information and diagnostic data structure information of each ECU into the target ODX file. The hierarchy of each ECU in the integrated target ODX file is consistent with the hierarchy of each ECU in the ODX file set, and can be used for diagnostic testing.

[0049] As one implementation of this application, to further improve the efficiency of diagnostic testing, the data in the ODX file set that is not used in diagnostic testing can be pruned and optimized. Before S102 above, the following may also be included:

[0050] Obtain the open test sequence exchange OTX file set of the vehicle. The OTX file set includes at least one OTX file. Each OTX file is used to describe the test sequence of the corresponding ECU. There is a one-to-one correspondence between the OTX file and the ODX file.

[0051] Based on the OTX file set, the mapping relationship is obtained. The mapping relationship is the relationship between the target ECU and the corresponding diagnostic service. The target ECU is the ECU that actually performs the diagnostic service.

[0052] Specifically, S102 mentioned above may include:

[0053] Based on the mapping relationship, the diagnostic data of the ODX file set is obtained, as well as the diagnostic service information, diagnostic data structure information, and diagnostic service inheritance relationship information of each target ECU.

[0054] The aforementioned OTX file set can be a collection of diagnostic test sequences describing all ECUs in a vehicle. Each OTX file set may include at least one OTX file, and each OTX file describes the test sequence for its corresponding ECU. There is a one-to-one correspondence between OTX files and ODX files. Generally, a diagnostic test sequence for one ECU requires at least one OTX file for description, and multiple diagnostic test sequences for multiple ECUs in a vehicle will necessarily consist of multiple OTX files. This application extracts data using multiple OTX files, which also covers scenarios involving a single OTX file.

[0055] In some embodiments, obtaining the mapping relationship based on the OTX file set may specifically include:

[0056] Obtain the encoding information of each OTX file; the encoding information of each OTX file is unique.

[0057] Access each OTX file sequentially according to its encoding information;

[0058] If the main function entry node in the OTX file is accessed, traverse each child node under the executed statement in the main function;

[0059] When the child node is an action child node and the node type of the action child node is a target type, a mapping relationship is generated based on the first node attribute and the second node attribute of the action child node. The first node attribute is the diagnostic service name and the second node attribute is the ECU name.

[0060] The encoding information of the aforementioned OTX files is unique. Since the execution of the test sequence starts from individual function nodes (procedure nodes), it is necessary to traverse the "procedures" child nodes (procedure nodes) in the file, establish a mapping relationship between the "procedure" nodes and the file IDs, and store this mapping in memory. The storage structure is a map, where the key is the OTX file ID, and the value is an array structure, with each element of the array storing the content of the procedure node.

[0061] According to the OTX standard, the test sequence executes a main function named "main" as the starting function. It then traverses the ID index stored in the map file and visits each element of the corresponding "procedure" node array in turn. If the name attribute of the node is "main", it is the entry point of the main function. Then, it traverses the child nodes (execution step information of the function) under the "flow" node of the function and extracts the mapping relationship between the target ECU's name information and the diagnostic service name for each child node. Otherwise, it skips the current node.

[0062] In some embodiments, when the child node is an action child node and the node type of the action child node is a target type, generating a mapping relationship based on the first node attribute and the second node attribute of the action child node may specifically include:

[0063] If the child node is a child node of an action, obtain the node type of the child node of the action.

[0064] When the node type is the target type, obtain the first node attribute and the second node attribute of the child node of the execution action, where the target type is the node type of the execution diagnostic service step operation;

[0065] A mapping relationship is generated based on the attributes of the first node and the attributes of the second node.

[0066] The aforementioned action sub-nodes are nodes that execute an action and may be associated with an ODX file, so further judgment is required.

[0067] The node types of the aforementioned execution action sub-nodes can include the Assignment node type, the execute diagnostic service diag:ExecuteDiagService node type, and the procedureCall node type. Among these, the execute diagnostic service node type is the target type for the execution diagnostic service step operation.

[0068] In the case where the node type is the target type, the first and second node attributes of the execution action child node are obtained. The target type is the node type that executes the diagnostic service step operation. For example, the node type can be diag:ExecuteDiagService, which means that it is an execution diagnostic service step operation. Access its "diag:diagService" node. If the node attribute is diag:CreateDiagServiceByName, it means that the node maps to the diagnostic service with the same name in the ODX file. Then, the node attribute "diag:name" (diagnostic service name) and the node attribute "diag:comChannel" (name of the variable currently storing ECU information) are obtained. The name of the ECU can be obtained by querying the currently stored variable name and ECU name correspondence table through the variable name.

[0069] The above-mentioned mapping relationship is generated based on the first node attribute and the second node attribute. For example, it can be to establish a map mapping relationship between the name of the diagnostic service and the ECU name (the key value is the name of the ECU and the value value is an array of diagnostic service names): if the ECU name already exists in the mapping table, the diagnostic service name is appended to its value; if the ECU name does not exist in the mapping table, the table is added with the key being the ECU name and the value being an array containing this diagnostic service name.

[0070] In this embodiment, the mapping relationship between the target ECU and the corresponding diagnostic service is extracted from the ODX file set of the vehicle's open test sequence exchange. Based on this mapping relationship, the data in the ODX file set that is not used for diagnostic testing is pruned and optimized. Only the diagnostic service information and diagnostic data structure information of the target ECU in the ODX file set are integrated into the target ODX file. This ensures that the integrated target ODX file does not contain redundant information, so that unnecessary central processing unit and memory resources are not occupied when the vehicle is being diagnosed, thereby further improving the efficiency of diagnostic testing.

[0071] In some embodiments, the above-mentioned acquisition of diagnostic data of the ODX file set based on the mapping relationship and the acquisition of diagnostic service information, diagnostic data structure information and diagnostic service inheritance relationship information of each target ECU may specifically include:

[0072] Scan the ODX file set to obtain diagnostic data for each ODX file. The diagnostic data includes diagnostic layer name information, diagnostic service information, diagnostic data structure information, and diagnostic service inheritance relationship information.

[0073] If the diagnostic layer name information in the ODX file matches the ECU name in the mapping relationship, the diagnostic service information, diagnostic data structure information, and diagnostic service inheritance relationship information in the ODX file will be identified as the diagnostic service information, diagnostic data structure information, and diagnostic service inheritance relationship information of the target ECU.

[0074] The aforementioned diagnostic data may include diagnostic layer name information SHORT-NAME, diagnostic service information DIAG-COMMS, diagnostic data structure information DIAG-DATA-DICTIONARY-SPEC, and diagnostic service inheritance relationship information PARENT-REFS. It is not limited to these, and may also include diagnostic service request information REQUESTS, diagnostic service response information POS-RESPONSES, and diagnostic service negative response information NEG-RESPONSES.

[0075] When the diagnostic layer name information in the ODX file matches the ECU name in the mapping relationship, the diagnostic service information, diagnostic data structure information, and diagnostic service inheritance relationship information of the ODX file are identified as the diagnostic service information, diagnostic data structure information, and diagnostic service inheritance relationship information of the target ECU. This can be achieved by identifying the diagnostic service information and diagnostic service inheritance relationship information of the ODX file as the diagnostic service information and diagnostic service inheritance relationship information of the target ECU, and identifying the data structure information associated with the diagnostic service information of the ODX file as the diagnostic data structure information of the target ECU; or by identifying the diagnostic service information, diagnostic service request information, diagnostic service response information, diagnostic service negative response information, and diagnostic service inheritance relationship information of the ODX file as the diagnostic service information, diagnostic service request information, diagnostic service response information, diagnostic service negative response information, and diagnostic service inheritance relationship information of the target ECU, and identifying the data structure information associated with the diagnostic service request information, diagnostic service response information, and diagnostic service negative response information of the target ECU as the diagnostic data structure information of the target ECU.

[0076] In this embodiment, by scanning the ODX file set, if the diagnostic layer name information of the ODX file matches the ECU name in the mapping relationship, the target ECU can be accurately located, thereby extracting the diagnostic service information, diagnostic data structure information, and diagnostic service inheritance relationship information of the target ECU.

[0077] In some embodiments, the diagnostic data further includes diagnostic service request information, diagnostic service response information, and diagnostic service negative response information. When the diagnostic layer name information in the ODX file matches the ECU name in the mapping relationship, the diagnostic service information, diagnostic data structure information, and diagnostic service inheritance relationship information of the ODX file are determined as the diagnostic service information, diagnostic data structure information, and diagnostic service inheritance relationship information of the target ECU. Specifically, this may include:

[0078] If the diagnostic layer name information in the ODX file matches the ECU name in the mapping relationship, the diagnostic service information, diagnostic service request information, diagnostic service response information, diagnostic service negative response information, and diagnostic service inheritance relationship information in the ODX file will be identified as the diagnostic service information, diagnostic service request information, diagnostic service response information, diagnostic service negative response information, and diagnostic service inheritance relationship information of the target ECU.

[0079] The data structure information associated with the diagnostic service request information, diagnostic service response information, and diagnostic service negative response information of the target ECU is determined as the diagnostic data structure information of the target ECU.

[0080] If the diagnostic layer name information SHORT-NAME of the ODX file matches the ECU name in the mapping relationship, it indicates that the diagnostic data of the ODX file is being used by the diagnostic test sequence. This allows us to locate the layer where the diagnostic data of the ODX file is located, and then perform the subsequent diagnostic data extraction work for the target ECU.

[0081] Since the diagnostic services executed in the test sequence require initialization using diagnostic data structure information in the ODX file, the associated diagnostic data structure information must also be extracted when extracting the diagnostic service information. However, the diagnostic service information and the diagnostic data structure information are not directly related. But by mapping the diagnostic service information to the ODX file, the data structure information associated with the diagnostic service request information, diagnostic service response information, and diagnostic service negative response information can be identified as the diagnostic data structure information of the target ECU.

[0082] In some embodiments, the data structure information associated with the diagnostic service request information, diagnostic service response information, and diagnostic service negative response information of the target ECU is determined as the diagnostic data structure information of the target ECU, which may specifically include:

[0083] Traverse the target nodes in the diagnostic service request information, diagnostic service response information, and diagnostic service negative response information of the target ECU, and identify the data reference type of each target node;

[0084] Among the various preset data referencing strategies, determine the target data referencing strategy that matches the data referencing type of the target node;

[0085] Based on the target data referencing strategy, the diagnostic data structure information of the target node is determined from the data structure information associated with the diagnostic service request information, diagnostic service response information, and diagnostic service negative response information of the target ECU.

[0086] The diagnostic data structure information of each target node is determined as the diagnostic data structure information of the target ECU.

[0087] The data reference types mentioned above can include ID reference types and SHORT-NAME reference types.

[0088] The above-mentioned process involves traversing the target nodes in the diagnostic service request information, diagnostic service response information, and diagnostic service negative response information of the target ECU, and identifying the data reference type of each target node. For example, this can be done by traversing the "PARAMS" node (i.e., the target node) under each piece of information in the diagnostic service request information, diagnostic service response information, and diagnostic service negative response information of the target ECU, and identifying the data reference type of each "PARAM" sub-node.

[0089] The aforementioned data referencing strategies include ID search strategy and SHORT-NAME search strategy. The ID search strategy is the data referencing strategy corresponding to the ID reference type, and the SHORT-NAME search strategy is the data referencing strategy corresponding to the SHORT-NAME reference type. This allows for the extraction of diagnostic data structure information for each "PARAM" child node.

[0090] In this embodiment, since each data structure information in the ODX file defines ID and SHORT-NAME attributes, these two attributes are also the basis for establishing data connection relationships. By combining the data reference types of ID and SHORT-NAME with the inheritance relationship between diagnostic levels, the data structure information is searched and located, thereby accurately determining the diagnostic data structure information of the target ECU.

[0091] As another implementation of this application, in order to correctly load the OTX file and ODX file to execute the corresponding diagnostic test sequence, after S103 above, the following may also be included:

[0092] Based on the mapping relationship, the link information of the integrated target ODX file is updated.

[0093] The above-mentioned updating of link information for the integrated target ODX file based on the mapping relationship can, for example, involve traversing the child nodes under the "LOGICAL-LINKS" section of the ODX file's vehicle model information, querying whether the ECU referenced by the BASE-VARIANT-REF of that child node is in the target ECU's name information in the mapping relationship, and deleting the link information if it does not exist. Alternatively, the odx.-d file describing the ECU information under the "ABLOCK" node of the ODX file directory information can be deleted, and the link information of the target ODX file can be added.

[0094] In this embodiment, based on the mapping relationship, the link information of the integrated target ODX file is updated, which can provide the correct link information of the target ODX file. Therefore, when performing diagnostic tests on the vehicle, the OTX file and ODX file can be loaded correctly to execute the corresponding diagnostic test sequence.

[0095] To facilitate understanding of the open diagnostic data exchange file processing method in the embodiments of this application, the actual application process of this open diagnostic data exchange file processing method is described as follows:

[0096] This application extracts diagnostic service information and diagnostic data structure information from target ECUs in an ODX file set and integrates the extracted diagnostic service information and diagnostic data structure information according to the diagnostic service inheritance relationship. First, the ODX file set is scanned to extract the name information of the target ECUs that actually use diagnostic services during the execution of the diagnostic test sequence. Then, the diagnostic data in the dependent ODX file set is scanned, and an index relationship is established for its various levels. Based on the name information of the target ECUs previously obtained from the ODX file set, the diagnostic service information and diagnostic data structure information used are extracted and integrated on an ECU-by-ECU basis. During the extraction of diagnostic data (including diagnostic service information, diagnostic data structure information, and diagnostic service inheritance relationship information), the diagnostic data of ECUs not used by the diagnostic services is removed according to the diagnostic layer inheritance hierarchy (i.e., diagnostic service inheritance relationship information) specified in the ODX standard. During the integration of diagnostic services, the same inheritance hierarchy is created in the target ODX file, referring to the inheritance hierarchy of the ODX file set. Then, the extracted diagnostic data of the target ECUs is placed into the target ODX file according to the hierarchy in the ODX file set. After overall optimization and trimming, a new ODX diagnostic database (i.e., target ODX file) can be generated that matches the original OTX diagnostic test sequence data source (i.e., ODX file set). The physical memory occupied by the target ODX file will be greatly reduced. When the application uses the trimmed target ODX file for diagnostic testing, the CPU and random access memory occupied will also be reduced accordingly, and the execution effect of the diagnostic test sequence can be guaranteed to be consistent with that before trimming.

[0097] To achieve the above objectives, the implementation process of this application includes: extracting the mapping relationship between the name information of the target ECU and the name of the diagnostic service in the OTX, defining the data structure search strategy, and trimming and recombining the diagnostic data in the ODX file set.

[0098] 1) such as Figure 2 As shown, the mapping relationship between the name information of the target ECU and the name of the diagnostic service in OTX is extracted.

[0099] The diagnostic service information actually applied to each ECU's diagnostic test sequence is extracted from the OTX file.

[0100] Generally, a diagnostic test sequence for an ECU requires at least one OTX file for description, and multiple ECU diagnostic test sequences for a vehicle model will necessarily consist of multiple OTX files. This solution extracts data using multiple OTX files, thus also covering scenarios with a single OTX file.

[0101] According to the OTX standard, the starting function name for the sequence execution is "main", and the extraction steps are as follows:

[0102] Step 1: Load all OTX files (i.e., OTX datasets):

[0103] Load all OTX files and obtain the ID information for each OTX file. Since the execution of the test sequence starts from a series of function nodes (procedure nodes), it is necessary to traverse the "procedures" child nodes (procedure nodes) in the file, establish a mapping relationship between the "procedure" nodes in the OTX file and the OTX file ID, and store it in memory.

[0104] The storage relationship structure is a map, where the key is the ID of the OTX file and the value is an array structure, with each element of the array storing the content of the procedure node.

[0105] Step 2: Search for the function entry point for the diagnostic test sequence:

[0106] Iterate through the file ID index Key of the map in step one of the storage, and access each element of the "procedure" node array corresponding to each Key in turn: if the name attribute of the node is "main", then it is the entry point of the main function, and then iterate through the child nodes under the "flow" node of the function (the execution step information of the function), and then perform step three for each child node to extract the valid diagnostic service information; otherwise, skip the current node.

[0107] Step 3: Extract the mapping relationship between the target ECU's name information and the diagnostic service name:

[0108] When accessing a child node of the main function, if an "Action" node is encountered, this step involves executing an action, which may be associated with ODX and requires further judgment via the following branch:

[0109] If the node type is Assignment, it is an assignment step operation. Then, it checks whether the type of the variable being assigned is diag:GetComChannel. If it is, this step means that the current variable stores the name of the ECU in the ODX file. The name of the variable is obtained through the name attribute, and then the name of the ECU is obtained through diag:ecuVariantName. The correspondence between the variable name and the ECU name is established and saved (the key of the relationship is the variable name, and the value is the name of the ECU).

[0110] If the node type is `diag:ExecuteDiagService`, it represents the steps for executing a diagnostic service. Accessing its `diag:diagService` node, if the node attribute is `diag:CreateDiagServiceByName`, indicates that this node maps to a diagnostic service with the same name in the ODX file. Then, obtain the `diag:name` node attribute (diagnostic service name) and the `diag:comChannel` node attribute (variable name storing current ECU information). By querying the currently stored variable name and ECU name mapping table using the variable name, the ECU name can be obtained. Then, a map mapping relationship is established between the diagnostic service name and the ECU name (i.e., the mapping relationship between the target ECU name information and the diagnostic service name). The key is the ECU name, and the value is an array of diagnostic service names. If the ECU name already exists in the mapping table, the diagnostic service name is appended to its value; if the ECU name does not exist in the mapping table, an array containing this diagnostic service name is added to the table with the key being the ECU name and the value being an array.

[0111] If the node type is ProcedureCall (meaning this node will call other functions, and other functions may also have diagnostic service step information associated with the ODX file), then access its procedure attribute. The value of this attribute is the name of the other function being called. Look up the corresponding "procedure" node in the previously stored file ID and procedure mapping table, and then start executing step three from this node.

[0112] If it is another node, it will not be analyzed, the current node will be skipped and the search for subsequent nodes will continue until the current function ends and there are no subsequent nodes;

[0113] The above three steps can be used to obtain the mapping relationship between the name information of the target ECU and the name of the diagnostic service in the OTX diagnostic test sequence.

[0114] 2) Define the data structure search strategy

[0115] The diagnostic data structure information in the ODX file is used to interpret the type information of the diagnostic data definition. Through its operation rules, the vehicle diagnostic data can be converted from bus values ​​to physical values, and vice versa.

[0116] The diagnostic services executed in the test sequence require initialization using the diagnostic data structure information in the ODX file. Therefore, when extracting the diagnostic service information, it is also necessary to extract the associated diagnostic data structure information. The diagnostic data structure information in the ODX file may be scattered across different diagnostic levels under the DIAG-DATA-DICTIONARY-SPEC node, and lower diagnostic levels may have diagnostic data structures with the same name that overwrite higher-level diagnostic data structures. Therefore, a search strategy needs to be defined to accurately locate the position of each diagnostic data structure in the ODX file. The data structure types defined in the ODX file include DTC-DOP, DATA-OBJECT-PROP, STRUCTURE, STATIC-FIELD, DYNAMIC-LENGTH-FIELD, DYNAMIC-ENDMARKER-FIELD, END-OF-PDU-FIELDS, MUX, TABLE, ENV-DATA, and ENV-DATA-DESC. Among them, DATA-OBJECT-PROP is a basic data type that does not reference other data, DTC-DOP is a fixed data type, and the remaining types are all complex types that reference an indefinite number of other sub-parameters.

[0117] Each defined data structure in the ODX file has ID and SHORT-NAME attributes, which form the basis for establishing data connections. A mapping table needs to be created beforehand for each data structure, with the key being the ID and the value being the data structure itself. This mapping is obtained through step one of 3). This solution uses the ID and SHORT-NAME combined with the diagnostic service inheritance relationship information between diagnostic levels to search for and locate accurate diagnostic data structure information.

[0118] I. For example Figure 3 As shown, search by ID:

[0119] a. Locate the specific diagnostic data structure DIAG-DATA-DICTIONARY-SPEC based on the mapping relationship of the stored diagnostic data structure;

[0120] b. Copy all information from this diagnostic data structure to a new ODX file;

[0121] c. Determine the type of diagnostic data structure:

[0122] If the type is STRUCTURE, iterate through its "PARAMS" child nodes, searching for and locating each sub-data structure by ID or SHORT-NAME based on the reference type of the child nodes; if the type is STATIC-FIELD, DYNAMIC-LENGTH-FIELD, DYNAMIC-ENDMARKER-FIELD, or END-OF-PDU-FIELDS, search the "BASIC-STRUCTURE-REF" node, searching for and locating the sub-data structure by ID or SHORT-NAME based on the reference type of that node; if the type is MUX, iterate through the "STRUCTUR" child nodes under "CASE," searching for and locating each sub-data structure by ID or SHORT-NAME based on the reference type of the child nodes. The data structure is then searched. The same data search operation is performed on the "DATA-OBJECT-PROP-REF" node under "SWITCH-KEY" and the "STRUCTURE-REF" node under "DEFAULT-CASE". If the type is TABLE, the child nodes under "TABLE-ROW" and "TABLE-ROW-REF" and the "KEY-DOP-REF" node are searched to locate the referenced sub-data structure. If the type is ENV-DATA or ENV-DATA-DESC, the information is copied directly, and the used "PARAM" nodes are searched for and located using the ID or SHORT-NAME based on the reference type of the node. If the type is DATA-OBJECT-PROP, the search ends.

[0123] II. Figure 4 As shown, searching by SHORT-NAME:

[0124] a. First, locate the data structure with the same SHORT-NAME in the current diagnostic layer. If found, use this data to execute step b in "Search by ID"; otherwise, continue to the next step.

[0125] b. Traverse the parent diagnostic layers of the current diagnostic layer and search for data structures with the same SHORT-NAME. If found, use this data to perform step b in "Search by ID"; otherwise, use this parent diagnostic layer as the latest diagnostic layer and perform step b again.

[0126] 3) Trim and reassemble diagnostic data from the ODX file set.

[0127] Typically, a vehicle diagnostic test sequence will contain multiple ODX files from multiple ECUs, while a single ECU diagnostic test sequence will have at least one ODX file. This embodiment extracts and trims data according to multiple ODX files, thus also covering scenarios with a single ODX file.

[0128] like Figure 5 As shown, according to the ODX standard, diagnostic data can be stored in five different types of diagnostic layers (ECU-SHARED-DATA, PROTOCOL, FUNCTIONAL-GROUP, BASE-VARIANT, and ECU-VARIANT). Data can be reused between each layer according to the data inheritance and import relationships required by the standard. This embodiment analyzes the actual data inheritance path according to the standard requirements, accurately locates the actual referenced data structure, and then extracts and reassembles it.

[0129] Since different levels of diagnostic data may be stored in different files, importing ODX data sources requires numerous data opening and loading operations, which can reduce operational efficiency to some extent. This solution stores the extracted data in a newly created ODX file according to specifications and hierarchically, thus avoiding the problem of loading files multiple times.

[0130] like Figure 6 As shown, the diagnostic data in the reconstructed ODX file set is trimmed and reassembled using the following steps:

[0131] Step 1: Load the ODX file set:

[0132] Create a new empty ODX file to store the diagnostic data of the target ECU that will be extracted later.

[0133] Load all ODX files in the diagnostic test sequence, iterate through the diagnostic data of each diagnostic level (ECU-SHARED-DATA, PROTOCOL, FUNCTIONAL-GROUP, BASE-VARIANT, and ECU-VARIANT) in each file, and establish a mapping relationship between the ID attribute of each ODX file and the internal diagnostic data. The internal diagnostic data contains the following information:

[0134] Diagnostic layer name information: SHORT-NAME;

[0135] The diagnostic data structure information DIAG-DATA-DICTIONARY-SPEC needs to be indexed according to ID;

[0136] Diagnostic service information DIAG-COMMS;

[0137] Diagnostic service request information REQUESTS;

[0138] Diagnostic service response information POS-RESPONSES;

[0139] Negative response information for diagnostic services (NEG-RESPONSES);

[0140] Diagnostic service inheritance relationship information PARENT-REFS.

[0141] Step 2: Locate the diagnostic layer of the target ECU:

[0142] Traverse the mapping relationship between ECU names and diagnostic service names extracted from the OTX file set, search in the extracted diagnostic data, if the ECU name and the diagnostic layer name information SHORT-NAME of the diagnostic data are the same, it means that the diagnostic layer of the diagnostic data is applied by the diagnostic test sequence, and then proceed to the next step of extracting effective diagnostic data (i.e., diagnostic data of the target ECU).

[0143] Step 3: Extract valid diagnostic data:

[0144] a. Confirm that the current diagnostic layer exists in the newly created ODX file (i.e., the target ODX file); if it does not exist, copy the remaining information except for that listed in step one from the original ODX file to the new file, and store them in the order of ECU-SHARED-DATA>PROTOCOL>FUNCTIONAL-GROUP>BASE-VARIANT>ECU-VARIANT.

[0145] Iterate through the name information of the target ECUs extracted from the OTX file set, and perform the following steps for each target ECU's diagnostic data:

[0146] b. Copy the diagnostic service information of the target ECU to the DIAG-COMMS node in the new file.

[0147] c. Query the REQUEST-REF, POS-RESPONSE-REFS, and NEG-RESPONSE-REFS information of the target ECU, and search by ID to find the request, response, and negative response information in the corresponding diagnostic layer: If the diagnostic layer containing the information does not exist in the new file, step a needs to be performed first, and then the corresponding information is placed in its corresponding diagnostic layer; if the diagnostic layer containing the information already exists in the new file, it needs to be determined whether the information already exists, and if it does not exist, it is copied and stored in the new file.

[0148] d. Extract the data structure information associated with the request, response, and negative response:

[0149] Iterate through the "PARAMS" nodes under each piece of information in step c, and perform the following operations on each "PARAM" child node in turn:

[0150] (i) If the data reference type of the “PARAM” node is an ID reference type, then execute the “Search by ID” step in the ODX data structure search strategy;

[0151] (ii) If the data reference type of the “PARAM” node is of type SHORT-NAME, then execute the “Search by SHORT-NAME” step in the ODX data structure search strategy.

[0152] Step 4: Update ODX link information:

[0153] e. Based on the actual ECU used, traverse the child nodes under “LOGICAL-LINKS” of the vehicle information in the ODX file, and query whether the ECU referenced by BASE-VARIANT-REF of the child node is in the results extracted in (1). If it does not exist, delete the link information.

[0154] f. Delete the odx.-d file describing ECU information under the "ABLOCK" node in the ODX file's directory information, and add the link information for the new file.

[0155] This embodiment extracts the ECU name information that actually uses the diagnostic service based on the OTX diagnostic test sequence. By trimming and optimizing the ODX diagnostic database, the functional results executed using the diagnostic test sequence of the optimized ODX file set are consistent with the execution results before trimming. After trimming and optimizing the ODX diagnostic database based on the OTX diagnostic test sequence, the size of the diagnostic test sequence data occupied by the ROM physical memory can be effectively reduced. When the application uses the trimmed diagnostic test sequence data source to execute test functions, it can avoid wasting the operating system's CPU resources on identifying and analyzing redundant data. Therefore, it can effectively improve the application's computing efficiency and task response performance, while also reducing RAM physical memory usage and saving operating system space.

[0156] Based on the open diagnostic data exchange file processing method provided in the above embodiments, this application also provides specific implementations of an open diagnostic data exchange file processing apparatus. Please refer to the following embodiments.

[0157] Please see Figure 7 The open diagnostic data exchange file processing device 700 provided in this application embodiment may include the following modules: a first acquisition module 701, a second acquisition module 702, and an integration module 703.

[0158] The first acquisition module 701 is used to acquire the vehicle's Open Diagnostic Data Exchange (ODX) file set and to acquire the target ODX file. The ODX file set includes at least one ODX file, each ODX file is used to describe the diagnostic specifications of the corresponding electronic control unit (ECU), and each ODX file includes diagnostic service information and diagnostic data structure information of the corresponding ECU.

[0159] The second acquisition module 702 is used to acquire diagnostic data of each ODX file according to the ODX file set, and to acquire diagnostic service information, diagnostic data structure information and diagnostic service inheritance relationship information of each ECU.

[0160] The integration module 703 is used to integrate the diagnostic service information and diagnostic data structure information of each ECU into the target ODX file according to the inheritance relationship information of each diagnostic service, so as to obtain the integrated target ODX file, which is used for diagnostic testing.

[0161] As one implementation of this application, in order to further improve the efficiency of diagnostic testing, the data in the ODX file set that is not used in diagnostic testing can also be trimmed and optimized. The aforementioned apparatus 700 may further include:

[0162] The third acquisition module is used to acquire the open test sequence exchange OTX file set of the vehicle. The OTX file set includes at least one OTX file, and each OTX file is used to describe the test sequence of the corresponding ECU. The OTX file and the ODX file correspond one-to-one.

[0163] The fourth acquisition module is used to acquire the mapping relationship based on the OTX file set. The mapping relationship is the relationship between the target ECU and the corresponding diagnostic service. The target ECU is the ECU that actually performs the diagnostic service.

[0164] The second acquisition module 702 mentioned above is specifically used to acquire diagnostic data of the ODX file set based on the mapping relationship and the ODX file set, as well as acquire diagnostic service information, diagnostic data structure information and diagnostic service inheritance relationship information of each target ECU.

[0165] In some embodiments, the fourth acquisition module described above may specifically include:

[0166] The first acquisition submodule is used to obtain the encoding information of each OTX file, and the encoding information of each OTX file is unique.

[0167] The access submodule is used to access each OTX file sequentially according to its encoding information.

[0168] Traverse submodules, used to traverse each child node under the executed statement in the main function when the main function entry node in the OTX file is accessed;

[0169] The generation submodule is used to generate a mapping relationship based on the first node attribute and the second node attribute of the execution action subnode when the subnode is an execution action subnode and the node type of the execution action subnode is a target type. The first node attribute is the diagnostic service name and the second node attribute is the ECU name.

[0170] In some embodiments, the above-mentioned generation submodule may specifically include:

[0171] The first acquisition unit is used to acquire the node type of the child node that performs the action when the child node is the child node that performs the action.

[0172] The second acquisition unit is used to acquire the first node attribute and the second node attribute of the child node performing the action when the node type is the target type, where the target type is the node type performing the diagnostic service step operation;

[0173] The generation unit is used to generate a mapping relationship based on the attributes of the first node and the attributes of the second node.

[0174] In some embodiments, the second acquisition module 702 described above may specifically include:

[0175] The second acquisition submodule is used to scan the ODX file set and obtain the diagnostic data of each ODX file. The diagnostic data includes diagnostic layer name information, diagnostic service information, diagnostic data structure information, and diagnostic service inheritance relationship information.

[0176] The determination submodule is used to determine the diagnostic service information, diagnostic data structure information, and diagnostic service inheritance relationship information of the ODX file as the diagnostic service information, diagnostic data structure information, and diagnostic service inheritance relationship information of the target ECU, provided that the diagnostic layer name information of the ODX file matches the ECU name in the mapping relationship.

[0177] In some embodiments, the diagnostic data above also includes diagnostic service request information, diagnostic service response information, and diagnostic service negative response information;

[0178] The aforementioned sub-modules can specifically include:

[0179] The first determining unit is used to determine the diagnostic service information, diagnostic service request information, diagnostic service response information, diagnostic service negative response information, and diagnostic service inheritance relationship information of the ODX file as the diagnostic service information, diagnostic service request information, diagnostic service response information, diagnostic service negative response information, and diagnostic service inheritance relationship information of the target ECU when the diagnostic layer name information of the ODX file is consistent with the ECU name in the mapping relationship.

[0180] The second determining unit is used to determine the data structure information associated with the diagnostic service request information, diagnostic service response information and diagnostic service negative response information of the target ECU as the diagnostic data structure information of the target ECU.

[0181] In some embodiments, the second determining unit may specifically include:

[0182] The identification subunit is used to traverse the target nodes in the diagnostic service request information, diagnostic service response information, and diagnostic service negative response information of the target ECU, and identify the data reference type of each target node;

[0183] The first determining subunit is used to determine, among a variety of preset data referencing strategies, the target data referencing strategy that matches the data referencing type of the target node;

[0184] The second determining subunit is used to determine the diagnostic data structure information of the target node based on the target data referencing strategy, from the data structure information associated with the diagnostic service request information, diagnostic service response information and diagnostic service negative response information of the target ECU.

[0185] The third determining subunit is used to determine the diagnostic data structure information of each target node as the diagnostic data structure information of the target ECU.

[0186] As another implementation of this application, in order to correctly load the OTX file and ODX file to execute the corresponding diagnostic test sequence, the above-mentioned device 700 may further include:

[0187] The update module is used to update the link information of the integrated target ODX file based on the mapping relationship.

[0188] Figure 8 A schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application is shown.

[0189] An electronic device may include a processor 801 and a memory 802 storing computer program instructions.

[0190] Specifically, the processor 801 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0191] The memory 802 may include a large-capacity memory for data or instructions.

[0192] In a particular embodiment, memory 802 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical or other physical / tangible memory storage device.

[0193] The processor 801 reads and executes computer program instructions stored in the memory 802 to implement any of the open diagnostic data exchange file processing methods in the above embodiments.

[0194] In one example, the electronic device may also include a communication interface 803 and a bus 810. For example, Figure 8 As shown, the processor 801, memory 802, and communication interface 803 are connected through bus 810 and complete communication with each other.

[0195] The communication interface 803 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0196] Bus 810 includes hardware, software, or both, that couples components of an electronic device together. Where appropriate, bus 810 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnection.

[0197] The electronic device can execute the open diagnostic data exchange file processing method in the embodiments of this application, thereby achieving a combination Figure 1 and Figure 7 The described method and apparatus for processing open diagnostic data exchange files.

[0198] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0199] The functional blocks shown in the above structural diagram can be implemented as hardware, software, firmware, or a combination thereof.

[0200] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams.

[0201] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A processing method of an open diagnostic data exchange file, characterized by, The method comprises the following steps: obtaining an open diagnostic data exchange (ODX) file set of a vehicle, wherein the ODX file set comprises at least one ODX file, and each ODX file is used for describing a diagnostic specification of a corresponding electronic control unit (ECU), and each ODX file comprises diagnostic service information and diagnostic data structure information of the corresponding ECU; obtaining diagnostic data of each ODX file according to the ODX file set, and obtaining diagnostic service information, diagnostic data structure information and diagnostic service inheritance relationship information of each ECU; integrating the diagnostic service information and the diagnostic data structure information of each ECU into the target ODX file according to each diagnostic service inheritance relationship information to obtain an integrated target ODX file, wherein the integrated target ODX file is used for diagnostic testing; before the step of obtaining diagnostic data of each ODX file according to the ODX file set, and obtaining diagnostic service information, diagnostic data structure information and diagnostic service inheritance relationship information of each ECU, the method further comprises the following steps: obtaining an open test sequence exchange (OTX) file set of the vehicle, wherein the OTX file set comprises at least one OTX file, and each OTX file is used for describing a test sequence of a corresponding ECU, and the OTX file corresponds to the ODX file in one-to-one manner; obtaining a mapping relationship based on the OTX file set, wherein the mapping relationship is a relationship between a target ECU and a corresponding diagnostic service, and the target ECU is an ECU actually performing the diagnostic service; the step of obtaining diagnostic data of each ODX file according to the ODX file set, and obtaining diagnostic service information, diagnostic data structure information and diagnostic service inheritance relationship information of each ECU comprises the following steps: obtaining diagnostic data of the ODX file set, and obtaining diagnostic service information, diagnostic data structure information and diagnostic service inheritance relationship information of each target ECU according to the ODX file set based on the mapping relationship; the step of obtaining a mapping relationship based on the OTX file set comprises the following steps: obtaining coding information of each OTX file, wherein the coding information of each OTX file is unique; sequentially accessing each OTX file according to the coding information of each OTX file; in a case where a main function entry node in the OTX file is accessed, traversing each sub-node under an execution statement in the main function; in a case where the sub-node is an execution action sub-node, and a node type of the execution action sub-node is a target type, generating a mapping relationship based on a first node attribute and a second node attribute of the execution action sub-node, wherein the first node attribute is a diagnostic service name, and the second node attribute is an ECU name; the step of generating a mapping relationship based on the first node attribute and the second node attribute of the execution action sub-node in a case where the sub-node is an execution action sub-node, and a node type of the execution action sub-node is a target type comprises the following steps: obtaining the node type of the execution action sub-node in a case where the sub-node is an execution action sub-node. In a case where the node type is a target type, a first node attribute and a second node attribute of the execution action sub-node are obtained, the target type being a node type of performing a diagnostic service step operation; A mapping relationship is generated based on the first node attribute and the second node attribute; The diagnostic data of the ODX file set is obtained based on the mapping relationship and the ODX file set, and the diagnostic service information, the diagnostic data structure information and the diagnostic service inheritance relationship information of each target ECU are obtained, including: The diagnostic data of each ODX file is obtained by scanning the ODX file set, and the diagnostic data includes diagnostic layer name information, the diagnostic service information, the diagnostic data structure information and the diagnostic service inheritance relationship information; In a case where the diagnostic layer name information of the ODX file is consistent with the ECU name in the mapping relationship, the diagnostic service information, the diagnostic data structure information and the diagnostic service inheritance relationship information of the ODX file are determined as the diagnostic service information, the diagnostic data structure information and the diagnostic service inheritance relationship information of the target ECU.

2. The method of claim 1, wherein, The diagnostic data further includes diagnostic service request information, diagnostic service response information and diagnostic service negative response information; In a case where the diagnostic layer name information of the ODX file is consistent with the ECU name in the mapping relationship, the diagnostic service information, the diagnostic data structure information and the diagnostic service inheritance relationship information of the ODX file are determined as the diagnostic service information, the diagnostic data structure information and the diagnostic service inheritance relationship information of the target ECU. In a case where the diagnostic layer name information of the ODX file is consistent with the ECU name in the mapping relationship, the diagnostic service information, the diagnostic data structure information and the diagnostic service inheritance relationship information of the ODX file are determined as the diagnostic service information, the diagnostic data structure information and the diagnostic service inheritance relationship information of the target ECU. The data structure information associated with the diagnostic service request information, the diagnostic service response information and the diagnostic service negative response information of the target ECU is determined as the diagnostic data structure information of the target ECU.

3. The method of claim 2, wherein, The data structure information associated with the diagnostic service request information, the diagnostic service response information and the diagnostic service negative response information of the target ECU is determined as the diagnostic data structure information of the target ECU, including: Target nodes in the diagnostic service request information, the diagnostic service response information and the diagnostic service negative response information of the target ECU are traversed to identify the data reference types of each target node; In a case where the node type is a target type, a first node attribute and a second node attribute of the execution action sub-node are obtained, the target type being a node type of performing a diagnostic service step operation; A target data reference strategy matching the data reference type of the target node is determined from a plurality of preset data reference strategies; The diagnostic data structure information of the target node is determined from the data structure information associated with the diagnostic service request information, the diagnostic service response information and the diagnostic service negative response information of the target ECU based on the target data reference strategy; The diagnostic data structure information of each target node is determined as the diagnostic data structure information of the target ECU.

4. The method of claim 1, wherein, After the diagnostic service information and the diagnostic data structure information of each ECU are integrated into the target ODX file according to the diagnostic service inheritance relationship information, an integrated target ODX file is obtained, and the method further includes: Based on the mapping relationship, the integrated target ODX file is updated with link information.

5. A processing device of an open diagnostic data exchange file, characterized in that The device includes: A first obtaining module is configured to obtain an open diagnostic data exchange (ODX) file set of a vehicle, and obtain a target ODX file, the ODX file set including at least one ODX file, each ODX file being used to describe a diagnostic specification of a corresponding electronic control unit (ECU), and each ODX file including diagnostic service information and diagnostic data structure information of the corresponding ECU; A second obtaining module is configured to obtain diagnostic data of each ODX file according to the ODX file set, and obtain diagnostic service information, diagnostic data structure information, and diagnostic service inheritance relationship information of each ECU; An integrating module is configured to integrate the diagnostic service information and the diagnostic data structure information of each ECU into the target ODX file according to the diagnostic service inheritance relationship information, to obtain an integrated target ODX file, the integrated target ODX file being used for diagnostic testing; The device further includes: A third obtaining module is configured to obtain an open test sequence exchange (OTX) file set of the vehicle, the OTX file set including at least one OTX file, each OTX file being used to describe a test sequence of a corresponding ECU, and each OTX file corresponding to one ODX file; A fourth obtaining module is configured to obtain a mapping relationship based on the OTX file set, the mapping relationship being a relationship between a target ECU and a corresponding diagnostic service, and the target ECU being an ECU that actually performs the diagnostic service; The second obtaining module is specifically configured to obtain diagnostic data of the ODX file set, and obtain diagnostic service information, diagnostic data structure information, and diagnostic service inheritance relationship information of each target ECU based on the mapping relationship and according to the ODX file set; The fourth obtaining module specifically includes: A first obtaining submodule is configured to obtain coding information of each OTX file, the coding information of each OTX file being unique; An accessing submodule is configured to access each OTX file in sequence according to the coding information of each OTX file; A traversing submodule is configured to traverse each subnode under an execution statement in a main function in the OTX file in a case where a main function entry node in the OTX file is accessed; A generating submodule is configured to generate a mapping relationship based on first node attributes and second node attributes of an execution action subnode in a case where the subnode is an execution action subnode and a node type of the execution action subnode is a target type, the first node attributes being diagnostic service names, and the second node attributes being ECU names; The generating submodule specifically includes: The first obtaining unit is configured to obtain a node type of the execution action sub-node when the sub-node is an execution action sub-node; The second obtaining unit is configured to obtain a first node attribute and a second node attribute of the execution action sub-node when the node type is a target type, the target type being a node type of an execution diagnosis service step operation; The generating unit is configured to generate a mapping relationship based on the first node attribute and the second node attribute; The second obtaining module specifically comprises: The second obtaining sub-module is configured to scan the ODX file set and obtain diagnosis data of each ODX file, the diagnosis data comprising diagnosis layer name information, the diagnosis service information, the diagnosis data structure information and the diagnosis service inheritance relationship information; The determining sub-module is configured to determine the diagnosis service information, the diagnosis data structure information and the diagnosis service inheritance relationship information of the ODX file as the diagnosis service information, the diagnosis data structure information and the diagnosis service inheritance relationship information of the target ECU when the diagnosis layer name information of the ODX file is consistent with the ECU name in the mapping relationship.

6. An electronic device, comprising: The device comprises a processor and a memory storing computer program instructions; the processor executes the computer program instructions to implement the processing method of the open diagnostic data exchange file according to any one of claims 1-4.

Images