CN117194718A - Processing method and device of open type diagnosis data exchange file and related equipment - Google Patents

Abstract

The application discloses a processing method and device of an open type diagnosis data exchange file and related equipment, and relates to the technical field of automobiles. The method comprises the following steps: acquiring an open type diagnosis data exchange ODX file set of a vehicle and acquiring a target ODX file, wherein the ODX file set comprises at least one ODX file, each ODX file is used for describing diagnosis specifications of a corresponding Electronic Control Unit (ECU), and each ODX file comprises diagnosis service information and diagnosis data structure information of the corresponding ECU; according to the ODX file set, obtaining diagnostic data of each ODX file, and obtaining diagnostic service information, diagnostic data structure information and diagnostic service inheritance relation information of each ECU; and integrating the diagnosis service information and the diagnosis data structure information of each ECU into a target ODX file according to the inheritance relation information of each diagnosis service to obtain an integrated target ODX file, wherein the integrated target ODX file is used for diagnosis test.

Description

Processing method and device of open type diagnosis data exchange file and related equipment

Technical Field

The application belongs to the technical field of automobiles, and particularly relates to a processing method and device of an open type diagnosis data exchange file and related equipment.

Background

In the automotive field, diagnostic tests are an important ring in the development of whole vehicle diagnostics, and diagnostic test sequences can be made based on the open test sequence exchange format (Open test sequence exchange format, OTX) protocol, by using which diagnostic tests on vehicles can be realized. When the diagnostic test sequence is used for testing, an electronic control unit (Electronic Control Unit, ECU) diagnostic specification is also needed to judge the accuracy of the execution of the diagnostic test sequence and analyze the problems in the execution process.

Currently, a diagnostic test engineer creates a corresponding open diagnostic data exchange format (Open diagnostic data exchange, ODX) file according to the diagnostic specifications of each ECU, which contains all the diagnostic specification information supported by the ECU. However, redundant information exists in the ODX file, which occupies unnecessary central processing unit (Central Processing Unit, CPU) and memory resources when performing the diagnostic test, resulting in lower diagnostic test efficiency.

Disclosure of Invention

The embodiment of the application provides a processing method and device of an open type diagnosis data exchange file, related equipment and storage medium, which can not occupy unnecessary central processing unit and memory resources, thereby improving diagnosis test efficiency.

In a first aspect, an embodiment of the present application provides a method for processing an open diagnostic data exchange file, where the method includes:

acquiring an open type diagnosis data exchange ODX file set of a vehicle, and acquiring a target ODX file, wherein the ODX file set comprises at least one ODX file, each ODX file is used for describing diagnosis specifications of a corresponding Electronic Control Unit (ECU), and each ODX file comprises diagnosis service information and diagnosis data structure information corresponding to the ECU;

according to the ODX file set, obtaining diagnosis data of each ODX file, and obtaining diagnosis service information, diagnosis data structure information and diagnosis service inheritance relation information of each ECU;

integrating the diagnosis service information and the diagnosis data structure information of each ECU into the target ODX file according to the diagnosis service inheritance relation information to obtain an integrated target ODX file, wherein the integrated target ODX file is used for diagnosis test.

In a second aspect, an embodiment of the present application provides a processing apparatus for an open type diagnostic data exchange file, where the apparatus includes:

the system comprises a first acquisition module, a second acquisition module and a third acquisition module, wherein the first acquisition module is used for acquiring an open type diagnosis data exchange ODX file set of a vehicle and acquiring a target ODX file, the ODX file set comprises at least one ODX file, each ODX file is used for describing a diagnosis specification of a corresponding Electronic Control Unit (ECU), and each ODX file comprises diagnosis service information and diagnosis data structure information corresponding to the ECU;

The second acquisition module is used for acquiring the diagnosis data of each ODX file according to the ODX file set, and acquiring the diagnosis service information, the diagnosis data structure information and the diagnosis service inheritance relation information of each ECU;

the integration module is used for integrating the diagnosis service information and the diagnosis data structure information of each ECU into the target ODX file according to the diagnosis service inheritance relation information to obtain an integrated target ODX file, and the integrated target ODX file is used for diagnosis test.

In a third aspect, an embodiment of the present application provides an electronic device, including: a processor and a memory storing computer program instructions; the processor, when executing the computer program instructions, implements a method for processing an open diagnostic data exchange file as described in any one of the above.

In a fourth aspect, embodiments of the present application provide a computer readable storage medium having stored thereon computer program instructions which, when executed by a processor, implement a method of processing an open diagnostic data exchange file as described in any one of the above.

The processing method, the processing device and the related equipment of the open type diagnosis data exchange file can integrate the diagnosis service information and the diagnosis data structure information of each ECU in the open type diagnosis data exchange ODX file set of the vehicle into the target ODX file according to the diagnosis service inheritance relation information, and the integrated target ODX file can be used for diagnosis test. In this way, in this embodiment, the diagnostic service information and the diagnostic data structure information of the ECU for the diagnostic test are integrated into the target ODX file, and redundant information is not included any more, so that unnecessary central processing unit and memory resources are not occupied when the vehicle performs the diagnostic test, thereby improving the diagnostic test efficiency.

Drawings

In order to more clearly illustrate the technical solution of the embodiments of the present application, the drawings that are needed to be used in the embodiments of the present application will be briefly described, and it is possible for a person skilled in the art to obtain other drawings according to these drawings without inventive effort.

FIG. 1 is a flow chart of a method for processing an open diagnostic data exchange file according to one embodiment of the present application;

fig. 2 is a flowchart illustrating a process of extracting a mapping relationship between name information of a target ECU and a name of a diagnostic service according to an embodiment of the present application;

FIG. 3 is a schematic diagram of a search by ID according to an embodiment of the present application;

fig. 4 is a schematic flow chart of searching through SHORT-NAME according to an embodiment of the present application;

FIG. 5 is a schematic diagram of inheritance relationships of a diagnostic hierarchy provided by an embodiment of the present application;

FIG. 6 is a schematic flow chart of cutting out diagnostic data in a reorganized ODX file set according to an embodiment of the present application;

FIG. 7 is a schematic diagram of a processing device for an open diagnostic data exchange file according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

Features and exemplary embodiments of various aspects of the present application will be described in detail below, and in order to make the objects, technical solutions and advantages of the present application more apparent, the present application will be described in further detail below with reference to the accompanying drawings and the detailed embodiments. It should be understood that the particular embodiments described herein are meant to be illustrative of the application only and not limiting. It will be apparent to one skilled in the art that the present application may be practiced without some of these specific details. The following description of the embodiments is merely intended to provide a better understanding of the application by showing examples of the application.

It is noted that relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.

The open test sequence interchange format (ISO-13209Open test sequence exchange format,OTX) is a man-machine readable description format of an open, standardized diagnostic test sequence, which is described in extensible markup language (Extensible Markup Language, XML) format, consisting of a core and an extension. The core content describes the basic structure of the OTX document and the specifications of the data model that can be used to compose the test sequence. The OTX standard is designed to describe a test sequence, which is a program, so that the core part of OTX follows basic concepts common to most programming languages, including specifications of data types, flow control structures such as loop branch judgment, basic operations of data types, declarations of constant variables, exception handling, and call of functions in high-level development languages. The expansion part is a grammar structure which is expanded by a derivative mode on the basis of the core, so that grammar specifications meeting the functional requirements of different service scenes are made. The extensions supported by the current standards are automotive diagnostic communications, automotive diagnostic flashing, automotive diagnostic data, human-machine interaction (Human Machine Interface, HMI), event handling, time, mathematical operations, string operations, log records, and the like. In this way, the test sequences for different service scenarios can be built using the extended grammar specification of OTX.

The diagnostic test is an important ring in the whole vehicle diagnostic development in the automobile field, and a universal diagnostic test sequence suitable for the automobile industry can be manufactured by using an OTX protocol. When testing the diagnostic function of the ECU using the OTX diagnostic test sequence, it is also necessary to rely on the diagnostic specification data source of the current electronic control unit (Electronic Control Unit, ECU), which contains information such as diagnostic services, communication protocols, etc. supported by the current ECU. In the process of executing the test, the correctness of the test sequence execution can be judged by analyzing the receiving and transmitting data in the communication process through the diagnosis data source, and the problems in the execution process are analyzed. Since the diagnostic specifications to which the different electronic control units are subjected may differ, the diagnostic specifications of each electronic control unit need to be recorded by separate files, so that it is necessary to define a standardized, easily interactable format for describing the ECU diagnostic specifications.

The open diagnostic data exchange format (ISO-22901-1Open diagnostic data exchange,ODX) is an open, standardized ECU diagnostic specification description format, which is described using xml language form, and is composed of seven parts, diagnostic data, diagnostic communication parameters, vehicle type information, program refresh information, off-line configuration information, functional group diagnostic information, and multi-ECU service information. The data model of all the diagnosis data of the ECU can be described through ODX, such as diagnosis fault codes, diagnosis services, request and response parameter structures of the diagnosis services, communication parameter data, ECU variant data and other information.

Currently, in the automotive industry, a diagnostic test engineer may make a corresponding ODX file according to a diagnostic specification of each ECU, where the ODX file includes all diagnostic information supported by the ECU: diagnostic services, diagnostic data structures, offline configuration information, diagnostic communication parameter information, program refresh information, and the like. The number of ODX files required for one vehicle model is proportional to the number of ECUs it supports. Based on the ODX file, a diagnosis engineer refers to some diagnosis services in the ODX file according to specific test scenes of some ECUs, sets correct data and information such as judgment conditions for parameters of the diagnosis services, and arranges and builds a reasonable diagnosis test sequence according to a specific sequence. After the OTX file and the ODX file are loaded by the application program and analyzed, a corresponding test sequence can be executed, and further, diagnosis test is carried out on the vehicle or the ECU.

Because OTX and ODX are both standard open description formats, the diagnostic test sequences built can be used uniformly between automotive system suppliers, manufacturers and service distributors and repair shops, and even can be used in inter-company communication. The introduction of the two specifications greatly reduces the development work of upper application tools, accelerates the iterative development speed of vehicle types, and saves a great deal of economic cost and labor cost.

Although the diagnostic test sequence established by using the OTX and ODX standard specifications has high universality, can be uniformly communicated and used among different departments and even across companies, but has certain defects when the ODX file is applied. Because the ODX file set is a data set describing all diagnostic specification information of the ECU, and the diagnostic test sequence built by OTX is specific to a specific functional scenario of the ECU, only part of diagnostic service information, diagnostic data structure information and other contents in the ODX file set are generally used, for the diagnostic test sequence, the data information which is not used in the ODX file set is identical to redundant information, and in the diagnostic test sequence of the whole vehicle level, if all ODX files of the ECU are introduced, the whole redundant data volume becomes larger along with the increase of the number of the ECU.

After the OTX file and the ODX file are loaded by the application program running the diagnostic test sequence, the diagnostic test sequence can be analyzed and executed, and then the functional test of the ECU can be completed. However, because redundant data information exists in the ODX file, when an application program loads a resource to perform a diagnostic test, a central processing unit (Central Processing Unit, abbreviated as CPU) and memory resources are occupied, and the waste of the resources is more obvious when the diagnostic test of the ECU at the whole vehicle level is performed, so that the diagnostic test efficiency is lower.

In order to solve the problems in the prior art, the embodiment of the application provides a processing method, a processing device and related equipment for an open type diagnosis data exchange file. The following first describes a method for processing an open diagnostic data exchange file according to an embodiment of the present application.

Fig. 1 is a flow chart illustrating a method for processing an open diagnostic data exchange file according to an embodiment of the present application. As shown in fig. 1, a processing method of an open type diagnostic data exchange file may include the following steps S101 to S103.

S101, acquiring an open type diagnosis data exchange ODX file set of a vehicle and a target ODX file, wherein the ODX file set comprises at least one ODX file, each ODX file is used for describing diagnosis specifications of a corresponding Electronic Control Unit (ECU), and each ODX file comprises diagnosis service information and diagnosis data structure information of the corresponding ECU.

S102, according to the ODX file set, obtaining diagnosis data of each ODX file, and obtaining diagnosis service information, diagnosis data structure information and diagnosis service inheritance relation information of each ECU.

S103, integrating the diagnosis service information and the diagnosis data structure information of each ECU into a target ODX file according to the diagnosis service inheritance relation information to obtain an integrated target ODX file, wherein the integrated target ODX file is used for diagnosis test.

According to the processing method of the open type diagnosis data exchange file, diagnosis service information and diagnosis data structure information of each ECU in the open type diagnosis data exchange ODX file set of the vehicle can be integrated into the target ODX file according to the diagnosis service inheritance relation information, and the integrated target ODX file can be used for diagnosis test. In this way, in this embodiment, the diagnostic service information and the diagnostic data structure information of the ECU for the diagnostic test are integrated into the target ODX file, and redundant information is not included any more, so that unnecessary central processing unit and memory resources are not occupied when the vehicle performs the diagnostic test, thereby improving the diagnostic test efficiency.

In S101, the above ODX file set is a data set of diagnostic specification information describing all ECU' S of the vehicle, and may include at least one ODX file, where each ODX file is used to describe diagnostic specifications of a corresponding ECU. Each ODX file includes diagnostic service information corresponding to the ECU, which can be used to build a reasonable diagnostic test sequence in a specific order for performing a diagnostic test, and diagnostic data structure information, which can be used to interpret type information defined by the diagnostic data, that is, to convert the automotive diagnostic data from a bus value to a physical value through its operational rule.

The obtaining the ODX file set of the open type diagnostic data exchange of the vehicle may be obtaining the ODX file set of the vehicle to be diagnosed (i.e. the integrated set of all ODX files of the vehicle to be diagnosed) by using a standard architecture diagnostic apparatus.

The target ODX file may be a blank ODX file, and is used for storing diagnostic data (including diagnostic service information and diagnostic data structure information) extracted later.

The obtaining the target ODX file may be creating a new ODX empty file.

In S102, the diagnostic data of the ODX file may include, not only the diagnostic service information, the diagnostic data structure information, and the diagnostic service inheritance relationship information of the ECU described in the ODX file, but also the diagnostic layer name information, the diagnostic service request information, the diagnostic service response information, and the diagnostic service negative response information of the ECU described in the ODX file.

The above-mentioned obtaining the diagnostic data of each ODX file according to the ODX file set may be, for example, 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 comprise five different types of layers, namely a public DATA layer ECU-SHARED-DATA, a protocol DATA layer PROTOCOL, FUNCTIONAL-GROUP functional GROUP DATA layer, a BASE DATA layer BASE-VARIANT and an ECU derived DATA layer ECU-VARIANT, and multiplexing of DATA can be realized among each layer according to DATA inheritance and import relations required by specifications.

The obtaining the diagnostic service information, the diagnostic data structure information, and the diagnostic service inheritance relationship information of each ECU may be extracting and integrating the diagnostic service information, the diagnostic data structure information, and the diagnostic service inheritance relationship information in the diagnostic data of each ODX file in the unit of ECU to obtain the diagnostic service information, the diagnostic data structure information, and the diagnostic service inheritance relationship information of each ECU.

In S103, the above-described diagnostic service inheritance relationship information is used to describe the diagnostic service inheritance relationship between the ECUs.

The above-mentioned diagnostic service information and diagnostic data structure information of each ECU are integrated into the target ODX file according to the diagnostic service inheritance relationship information to obtain an integrated target ODX file, for example, according to the diagnostic service inheritance relationship indicated by the diagnostic service inheritance relationship information among the ECUs in the ODX file set, the same hierarchical structure may be constructed in the target ODX file, then the diagnostic service information and diagnostic data structure information of each ECU are integrated into the target ODX file, and the hierarchy of each ECU in the integrated target ODX file is identical to the hierarchy of each ECU in the ODX file set, which may be used for diagnostic test.

In order to further improve the diagnostic test efficiency, as an implementation manner of the present application, the clipping optimization process may be further performed on the data in the ODX file set that is not used by the diagnostic test, and before S102, the method may further include:

Acquiring an open test sequence exchange OTX file set of a vehicle, wherein the OTX file set comprises at least one OTX file, each OTX file is used for describing a test sequence corresponding to an ECU, and the OTX files are in one-to-one correspondence with ODX files;

based on the OTX file set, acquiring a mapping relation, wherein the mapping relation is the relation between a target ECU and a corresponding diagnosis service, and the target ECU is the ECU for actually executing the diagnosis service;

the step S102 may specifically include:

based on the mapping relation, according to the ODX file set, obtaining the diagnosis data of the ODX file set, and obtaining the diagnosis service information, the diagnosis data structure information and the diagnosis service inheritance relation information of each target ECU.

The OTX file set described above may be a set of diagnostic test sequences that the vehicle describes for all ECUs. The OTX file set may include at least one OTX file, where each OTX file is used to describe a test sequence corresponding to the ECU, and the OTX file corresponds to the ODX file one-to-one. In general, a diagnostic test sequence of one ECU needs to be described using at least one OTX file, and a plurality of ECU diagnostic test sequences of one vehicle must be composed of a plurality of OTX files. The application extracts data according to a mode of a plurality of OTX files, so that the scene of a single OTX file can be covered.

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

acquiring the 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;

under the condition of accessing the entry node of the main function in the OTX file, traversing all the child nodes under the execution statement in the main function;

under the condition that the child node is an executing action child node and the node type of the executing action child node is a target type, generating and obtaining a mapping relation based on a first node attribute and a second node attribute of the executing action child node, wherein the first node attribute is a diagnosis service name, and the second node attribute is an ECU name.

The encoding information of the OTX file is unique. Since the test sequence is executed with each function node (procedure node) as a starting point, a "procedure" sub-node (procedure node) in the file needs to be traversed, and a mapping relationship is established between the "procedure" node and the file ID in the file and stored in the memory. The storage relation structure is map, the key value is ID of OTX file, the value is in array structure, and each element of array stores the content of procedure node.

According to the specification of the OTX standard, the main function with the initial function name of "main" executed by the test sequence traverses the map file ID index and sequentially accesses each element of the corresponding "procedure" node array: if the name attribute of the node is 'main', the node is an entry point of a main function, then sub-nodes (execution step information of the function) under the 'flow' node of the function are traversed, and then the mapping relation of the name information of the target ECU and the diagnosis service name is extracted for each sub-node; otherwise, the current node is skipped.

In some embodiments, when the child node is an executing action child node and the node type of the executing action child node is a target type, generating the obtained mapping relationship according to the first node attribute and the second node attribute of the executing action child node may specifically include:

under the condition that the child node is an executing action child node, acquiring the node type of the executing action child node;

under the condition that the node type is a target type, acquiring a first node attribute and a second node attribute of the sub-node for executing the action, wherein the target type is the node type for executing the operation of the diagnostic service step;

and generating and obtaining a mapping relation based on the first node attribute and the second node attribute.

The action executing sub-node is a node executing an action, and may be associated with the ODX file, so further judgment is required.

The node types of the execution action sub-node can include Assignment of Assignment node types, execution of diagnosis service diag, execution diagserviceservice node types and call procedure call node types. Wherein the type of the executing diagnostic service node is the target type for executing the diagnostic service step operation.

In the case that the node type is the target type, the first node attribute and the second node attribute of the action sub node are obtained, the target type is the node type for executing the diagnostic service step operation, which may be exemplified by that the node type is the diag: execuediagservice step operation, which means that the node is accessed to the diagservicenode for executing the diagnostic service step operation, if the node attribute is the diag: createDiagServiceByName, it is explained that the node maps the diagnostic service with the same name in the ODX file, the diag: name node attribute (diagnostic service name) and the diag: channel node attribute (variable name for currently storing ECU information) are obtained, and the ECU name can be obtained by querying the currently stored variable name and ECU name correspondence table through the variable name.

The generating a mapping relationship based on the first node attribute and the second node attribute may be, for example, creating a map mapping relationship between the name of the diagnostic service and the name of the ECU (the key value is the name of the ECU, and the value is an array of diagnostic service names): if the mapping table has the ECU name, the diagnostic service name is added to the value, and if the mapping table does not have the ECU name, the key is added to the table as the ECU name, and the value is an array containing the diagnostic service name.

In this embodiment, the mapping relationship between the target ECU and the corresponding diagnostic service is extracted in the OTX file set by exchanging the OTX files in the open test sequence of the vehicle, based on the mapping relationship, the data in the ODX file set, which is not used by the diagnostic test, is cut and optimized, and only the diagnostic service information and the diagnostic data structure information of the target ECU in the ODX file set are integrated into the target ODX file, so that the integrated target ODX file does not contain redundant information, and thus, unnecessary central processor and memory resources are not occupied when the vehicle performs the diagnostic test, and the diagnostic test efficiency is further improved.

In some embodiments, the obtaining, based on the mapping relationship, diagnostic data of the ODX file set according to the ODX file set, and obtaining diagnostic service information, diagnostic data structure information, and diagnostic service inheritance relationship information of each target ECU may specifically include:

Scanning an ODX file set to obtain diagnosis data of each ODX file, wherein the diagnosis data comprises diagnosis layer name information, diagnosis service information, diagnosis data structure information and diagnosis service inheritance relation information;

when the diagnostic layer name information of the ODX file is consistent with the ECU name in the mapping relation, the diagnostic service information, the diagnostic data structure information and the diagnostic service inheritance relation information of the ODX file are determined as the diagnostic service information, the diagnostic data structure information and the diagnostic service inheritance relation information of the target ECU.

The diagnostic DATA may include diagnostic NAME information SHORT-NAME, diagnostic service information DIAG-comm, diagnostic DATA structure information DIAG-DATA-diagnostic-SPEC, and diagnostic service inheritance relationship information part-REFS, but not limited thereto, and may include diagnostic service request information request, diagnostic service response information POS-RESPONSES, and diagnostic service negative response information NEG-RESPONSES.

The above-mentioned determining, when 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 as the diagnostic service information, the diagnostic data structure information, and the diagnostic service inheritance relationship information of the target ECU may be determining, when the diagnostic layer name information of the ODX file is consistent with the ECU name in the mapping relationship, the diagnostic service information and the diagnostic service inheritance relationship information of the ODX file as the diagnostic service information and the diagnostic service inheritance relationship information of the target ECU, and determining 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, when the diagnostic layer name information of the ODX file is consistent with the ECU name in the mapping relationship, determining the diagnostic service information, the diagnostic service request information, the diagnostic service response information, the diagnostic service negative response information, and the diagnostic service inheritance relationship information of the ODX file as the diagnostic service information, the diagnostic service request information, the diagnostic service response information, the diagnostic service negative response information, and the diagnostic service inheritance relationship information of the target ECU, and determining 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 as the diagnostic data structure information of the target ECU.

In this embodiment, the ODX file set is scanned, and the target ECU can be accurately found when the diagnostic layer name information of the ODX file is consistent with the ECU name in the mapping relationship, so as to extract the diagnostic service information, the diagnostic data structure information and the diagnostic service inheritance relationship information of the target ECU.

In some embodiments, the diagnostic data further includes diagnostic service request information, diagnostic service response information, and diagnostic service negative response information, and determining the diagnostic service information, the diagnostic data structure information, and the diagnostic service inheritance relationship information of the ODX file as the diagnostic service information, the diagnostic data structure information, and the 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 may specifically include:

under the condition that the name information of the diagnosis layer of the ODX file is consistent with the ECU name in the mapping relation, determining diagnosis service information, diagnosis service request information, diagnosis service response information, diagnosis service negative response information and diagnosis service inheritance relation information of the ODX file as diagnosis service information, diagnosis service request information, diagnosis service response information, diagnosis service negative response information and diagnosis service inheritance relation information of a 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.

The fact that the NAME information SHORT-NAME of the diagnostic layer of the ODX file is consistent with the ECU NAME in the mapping relation shows that the diagnostic data of the ODX file is applied by the diagnostic test sequence, the diagnostic data of the ODX file can be positioned to the level of the diagnostic data of the ODX file, and then the subsequent target ECU diagnostic data extraction work is carried out.

Since the diagnostic service executed by the test sequence needs to be initialized by the diagnostic data structure information in the ODX file, the diagnostic data structure information associated with the diagnostic service information needs to be extracted together when the diagnostic service information is extracted. However, the diagnostic service information and the diagnostic data structure information are not directly related, but the diagnostic data structure information of the target ECU may be determined by data structure information associated with the diagnostic service request information, the diagnostic service response information, and the diagnostic service negative response information in the ODX file corresponding to the diagnostic service information.

In some embodiments, the determining 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 as the diagnostic data structure information of the target ECU may specifically include:

Traversing target nodes in the diagnosis service request information, the diagnosis service response information and the diagnosis service negative response information of the target ECU, and identifying the data reference type of each target node;

determining a target data reference strategy matched with the data reference type of the target node in a plurality of preset data reference strategies;

determining diagnostic data structure information of the target node in data structure information associated with diagnostic service request information, diagnostic service response information and diagnostic service negative response information of the target ECU based on the target data reference policy;

the diagnostic data structure information of each target node is determined as the diagnostic data structure information of the target ECU.

The data reference types may include an ID reference type and a SHORT-NAME reference type.

The above-mentioned traversing target ECU's diagnosis service request information, diagnosis service response information, and diagnosis service negative response information identify the data reference type of each target node, and may be, for example, traversing the "PARAMS" node (i.e., target node) under each of the diagnosis service request information, diagnosis service response information, and diagnosis service negative response information of the target ECU, and identifying the data reference type of each "PARAM" sub-node.

The above multiple data reference policies include an ID search policy and a SHORT-NAME search policy, where the ID search policy is a data reference policy corresponding to an ID reference type, and the SHORT-NAME search policy is a data reference policy corresponding to a SHORT-NAME reference type, so that extracting diagnostic data structure information is performed on each "PARAM" child node.

In this embodiment, since each piece of data structure information in the ODX file defines an ID and a SHORT-NAME attribute, these two attributes are also the basis for establishing a data connection relationship, and the positioning data structure information is searched by combining the data reference type of the ID and the SHORT-NAME with the inheritance relationship between diagnostic layers, so as to accurately determine the diagnostic data structure information of the target ECU.

As another implementation manner of the present application, in order to correctly load the OTX file and the ODX file to execute the corresponding diagnostic test sequence, after S103 above, the method may further include:

and updating the link information of the integrated target ODX file based on the mapping relation.

The updating of the link information for the integrated target ODX file based on the mapping relationship may be, for example, traversing a subnode under the model information "logic-LINKS" of the ODX file, querying whether the ECU referenced by the BASE-variable-REF of the subnode is in the name information of the target ECU in the mapping relationship, and deleting the link information if the ECU is not. In addition, the ODX-d file describing the ECU information under the node of the ODX file directory information "abock" may be deleted, and the link information of the target ODX file may be added.

In this embodiment, based on the mapping relationship, the link information is updated on the integrated target ODX file, so that correct link information of the target ODX file can be provided, and therefore, when the diagnostic test is performed on the vehicle, the OTX file and the ODX file can be correctly loaded to execute a corresponding diagnostic test sequence.

In order to facilitate understanding of the processing method of the open diagnostic data exchange file in the embodiment of the present application, a practical application process of the processing method of the open diagnostic data exchange file is described as follows:

the application extracts the diagnosis service information and the diagnosis data structure information of the target ECU in the ODX file set, and integrates the extracted diagnosis service information and the diagnosis data structure information according to the inheritance relation of the diagnosis service. Firstly, scanning an OTX file set, and extracting name information of a target ECU actually using diagnostic services in the execution process of a diagnostic test sequence; and then, the diagnostic data in the relied ODX file set is scanned, the index relation is established for the content of each layer, and the used diagnostic service information and diagnostic data structure information are extracted and integrated by taking the ECU as a unit according to the name information of the target ECU acquired in the OTX file set. In the process of extracting the diagnostic data (including diagnostic service information, diagnostic data structure information and diagnostic service inheritance relationship information), the diagnostic data of the ECU which is not used by the diagnostic service is cut off according to the diagnostic layer inheritance level (namely the diagnostic service inheritance relationship information) specified by the ODX standard; in the process of integrating the diagnostic service, referring to the inheritance hierarchy of the ODX file set, creating the same inheritance hierarchy in the target ODX file, and then placing the extracted diagnostic data of the target ECU into the target ODX file according to the hierarchy in the ODX file set. Through optimizing and cutting of the integrity, a new ODX diagnosis database (namely a target ODX file) matched with an original OTX diagnosis test sequence data source (namely an ODX file set) can be generated, the physical memory of a read-only memory occupied by the new ODX diagnosis database is greatly reduced, when an application program uses the cut target ODX file to carry out diagnosis test, the physical memory of a CPU and a random access memory occupied by the application program is correspondingly reduced, and the execution effect of a diagnosis test sequence is ensured to be consistent with that before cutting.

In order to achieve the above object, the present application is implemented by: extracting the mapping relation between the name information of the target ECU and the name of the diagnosis service in OTX, defining a data structure searching strategy, and cutting the diagnosis data in the recombinant ODX file set.

1) Extracting the mapping relationship between the name information of the target ECU and the diagnostic service name in OTX as shown in FIG. 2

Diagnostic service information to which the diagnostic test sequence of each ECU is actually applied is extracted through the OTX file.

In general, a diagnostic test sequence of one ECU needs to be described using at least one OTX file, and a plurality of ECU diagnostic test sequences of one vehicle type must be composed of a plurality of OTX files. The scheme extracts data according to the mode of a plurality of OTX files, so that the scene of a single OTX file can be covered.

The starting function name for the sequence execution is "main" according to the specification of the OTX standard, and the extraction steps are as follows:

step one: load all OTX files (i.e., OTX data sets):

and loading all OTX files and obtaining ID information of each OTX file. Because the test sequence is executed by taking a function node (procedure node) as a starting point, a 'procedure' sub-node (procedure node) in the file needs to be traversed, and a mapping relation is established between the 'procedure' node in the OTX file and the OTX file ID and stored in a memory.

The storage relation structure is map, the key value is ID of OTX file, the value is in array structure, and each element of array stores the content of procedure node.

Step two: searching a function entry of the diagnostic test sequence:

traversing the stored file ID index Key of the map in the step one, and sequentially accessing each element of the 'procedure' node array corresponding to each Key: if the name attribute of the node is main, the node is an entry point of a main function, then sub-nodes (execution step information of the function) under the function flow node are traversed, and then step three is executed for each sub-node to extract effective diagnosis service information; otherwise, the current node is skipped.

Step three: extracting the mapping relation between the name information of the target ECU and the name of the diagnosis service:

when accessing the child node of the main function, if an "Action" node is encountered, this step is a node that performs an Action, and possibly the generation of an association with ODX requires performing the following branches to further determine:

if the node type is Assignment, the node type is a step operation of Assignment, then judging whether the assigned variable type is diag, if yes, the step indicates that the current variable stores the name of the ECU in the ODX file, the name of the variable is obtained through a name attribute, then the name of the ECU is obtained through diag: ecaVariant name, and a corresponding relation is established between the name of the ECU and the name of the variable and is stored (the key value of the relation is the name of the variable, and the value is the name of the ECU);

If the node type is diag, executeDiagService, the operation is that the diagnostic service is executed, then the diagnostic service node is accessed, if the node attribute is diag, createDiagServiceByName, the diagnostic service with the same name in the ODX file is mapped by the node, the diagnostic name node attribute (diagnostic service name) and the diagnostic name node attribute (variable name for storing the current ECU information) are obtained, the name of the ECU can be obtained by inquiring the currently stored variable name and ECU name correspondence table through the variable name, then the map mapping relation (namely, the mapping relation between the name of the target ECU and the diagnostic service name) is established between the name of the diagnostic service and the ECU name, the key value is the name of the ECU, and the value is an array of the diagnostic service name. If the mapping table has the ECU name, the diagnostic service name is added to the value of the mapping table, if the mapping table does not have the ECU name, the key is added to the mapping table as the ECU name, and the value is an array containing the diagnostic service name;

if the node type is ProceduceCall (which means that the node can call other functions, and other functions can possibly have diagnostic service step information related to the ODX file), accessing the Procedure attribute of the node type, wherein the value of the attribute is the name of the called other functions, searching the corresponding "Procedure" node in the file ID and the Procedure mapping table stored before, and then starting to execute the step III by taking the node as a starting point;

If the current function is the other node, the analysis is not performed, the current node is skipped to continue searching the subsequent nodes until the current function is finished and no subsequent node exists;

through the three steps, the mapping relation between the name information of the target ECU and the name of the diagnosis service in the OTX diagnosis test sequence can be obtained.

2) Defining data structure search policies

The diagnostic data structure information in the ODX file is type information for interpreting the definition of diagnostic data, and the diagnostic data of the automobile can be converted from a bus value to a physical value and vice versa through its operation rule.

The diagnostic service executed by the test sequence needs to be initialized by the diagnostic data structure information of the ODX file, so that the diagnostic data structure information associated with the diagnostic service information needs to be extracted together when the diagnostic service information is extracted. The diagnostic DATA structure information in the ODX file may be scattered under DIAG-DATA-diagnostic-SPEC nodes of different diagnostic levels, and the diagnostic DATA structure information of the same name may exist in the low diagnostic level to cover the diagnostic DATA structure information of the high diagnostic level, so that a search strategy needs to be defined to accurately locate the position of each diagnostic DATA structure information in the ODX file. The DATA structure types defined in the ODX file are DTC-DOP, DATA-OBJECT-PROP, STRUCTURE, STATIC-FIELD, DYNAMIC-LENGTH-FIELD, DYNAMIC-ENDMARKER-FIELD, END-OF-PDU-FIELDS, MUX, TABLE, ENV-DATA, ENV-DATA-DESC. Wherein DATA-OBJECT-pro is the base DATA type, no other DATA is referenced, DTC-DOP is the fixed DATA type, and the remaining other types are complex types referencing a varying number of other subparameters.

Each piece of defined data structure information in the ODX file defines an ID and a SHORT-NAME attribute, which are also the basis for establishing a data connection relationship. It is necessary to build a mapping table for each piece of data structure information in advance, the key value is ID information of the data structure information, the value is data structure information, and the mapping relationship is obtained by step 3). The scheme searches for accurate positioning diagnosis data structure information by combining the ID and the SHORT-NAME with diagnosis service inheritance relation information between diagnosis layers.

1. As shown in fig. 3, search is performed by ID:

a. locating a specific diagnostic DATA structure DIAG-DATA-diagnostic-SPEC according to the mapping relation of the stored diagnostic DATA structure;

b. copying all information of the diagnostic data structure to a new ODX file;

c. judging the type of the diagnostic data structure:

if the type is STRUCTURE, traversing the child node of the PARAMS, and searching and positioning each child data STRUCTURE through an ID or a SHORT-NAME according to the reference type of the child node; if the type is STATIC-FIELD, DYNAMIC-LENGTH-FIELD, DYNAMIC-ENDMARKER-FIELD or END-OF-PDU-FIELDS, searching a node OF "BASIC-STRUCTURE-REF", and searching a positioning sub-data STRUCTURE through ID or SHORT-NAME according to the reference type OF the node; if the type is MUX, traversing the 'structure' subnodes under 'CASE', and searching and positioning each subdata structure through ID or SHORT-NAME according to the reference type of the subnodes; then, performing the same DATA search operation on the DATA-OBJECT-PROP-REF node under the SWITCH-KEY and the STRUCTURE-REF node under the DEFAULT-CASE; if the type is TABLE, traversing the child nodes under TABLE-ROW, TABLE-ROW-REF and KEY-DOP-REF nodes to search the sub-data structure for positioning reference; if the type is ENV-DATA or ENV-DATA-DESC, directly copying the information, traversing the used PARAM node, and searching for a positioning sub-DATA structure through ID or SHORT-NAME according to the reference type of the node; if the type is DATA-OBJECT-PROP, the search ends.

2. As shown in fig. 4, the search is performed by SHORT-NAME:

a. first locating the SHORT-NAME identical data structure in the current diagnostic layer, if step b in "search by ID" is found to be performed using this data; otherwise, continuing to execute downwards;

b. traversing the parent diagnostic layer of the current diagnostic layer, searching the same data structure of SHORT-NAME, if step b in "search by ID" is found to be performed using this data; otherwise, taking the father diagnosis layer as the latest diagnosis layer, and executing the step b again.

3) Cutting out diagnostic data in a reorganized ODX file set

Typically, the whole vehicle diagnostic test sequence will contain multiple ODX files for multiple ECUs, and a single ECU diagnostic test sequence will have at least one ODX file. In this embodiment, the data is extracted and cut according to the manner of multiple ODX files, so that the scene of a single ODX file can be covered.

As shown in fig. 5, according to the rules of the ODX standard, the diagnostic DATA may be stored in five different diagnostic layers (common DATA layer ECU-SHARED-DATA, PROTOCOL DATA layer procol, FUNCTIONAL GROUP DATA layer function-GROUP, BASE DATA layer BASE-VARIANT and ECU-VARIANT), and each layer may implement multiplexing of DATA according to the DATA inheritance and import relation required by the rules. According to the embodiment, the actual inheritance route of the data is analyzed according to the standard requirement, and the data is extracted and recombined after being accurately positioned to the actually referenced data structure.

Since different diagnostic data layers may be stored in different files, a large number of open and load data operations are required when an application program imports an ODX data source, which may reduce the operation efficiency to some extent. According to the scheme, the extracted data are stored in a newly-built ODX file layer by layer according to the specification requirements, so that the problem of loading the file for multiple times is solved.

As shown in fig. 6, the steps for cutting out the diagnostic data in the reorganized ODX file set are as follows:

step one: loading an ODX file set:

a new ODX null file is created for storing diagnostic data of the target ECU to be subsequently extracted.

Loading all ODX files in a diagnosis test sequence, traversing diagnosis data of each diagnosis level (ECU-SHARED-DATA, PROTOCOL, FUNCTIONAL-GROUP, BASE-VARIANT and ECU-VARIANT) in each file, and establishing a mapping relation between an ID attribute of each ODX file as a key value and internal diagnosis data, wherein the internal diagnosis data comprises the following information:

diagnostic layer NAME information SHORT-NAME;

diagnostic DATA structure information DIAG-DATA-diagnostic-SPEC, an index relation needs to be established according to ID;

diagnostic service information DIAG-COMMS;

diagnostic service request information request;

Diagnostic service response information POS-RESPONSES;

diagnostic service negative response information NEG-RESPONSES;

the diagnostic service inherits the relationship information part-REFS.

Step two: diagnostic layer of positioning target ECU:

and traversing the mapping relation between the ECU NAMEs and the diagnostic service NAMEs extracted in the OTX file set, searching in the extracted diagnostic data, if the ECU NAMEs and the diagnostic layer NAME information SHORT-NAME of the diagnostic data are the same, indicating that the diagnostic data are applied to a diagnostic test sequence in the diagnostic layer, and then extracting the effective diagnostic data (namely the diagnostic data of the target ECU) in the next step.

Step three: extracting effective diagnostic data:

a. confirming whether a current diagnosis layer exists in the newly-built ODX file (namely, the target ODX file); if not, the remaining information listed in the step one needs to be copied to a new file in the original ODX file, and the remaining information needs to be stored in the order of ECU-SHARED-DATA > PROTOCOL > FUNCTIONAL-GROUP > BASE-VARIANT > ECU-VARIANT.

Traversing the name information of the target ECU extracted in the OTX file set, performing the following steps on the diagnostic data of each target ECU:

b. the diagnostic service information of the target ECU is copied under the DIAG-COMMS node in the new file.

c. Inquiring the REQUEST-REF, POS-RESPONSE-REFS and NEG-RESPONSE-REFS information of the target ECU, searching through the ID, and finding the information of the REQUEST, the RESPONSE and the negative RESPONSE in the corresponding diagnosis layer: if the diagnosis layer where the information is located does not exist in the new file, the step a is required to be executed firstly, and then the corresponding information is put into the corresponding diagnosis layer; if the diagnostic layer at which the information is located already exists in the new file, it is necessary to determine whether the information is already present, and if not, store a copy thereof in the new file.

d. Extracting data structure information associated with the request, the response and the negative response:

traversing the PARAMS node under each piece of information in the step c, and sequentially executing the following operations on each PARAM sub-node:

(i) If the data reference type of the PARAM node is an ID reference type, executing a searching step through ID in an ODX data structure searching strategy;

(ii) If the data reference type of the "PARAM" node is a SHORT-NAME type, then the "search by SHORT-NAME" step in the ODX data structure search policy is performed.

Step four: updating ODX link information:

e. according to the actually used ECU, traversing the lower sub-node of the model information 'LOGICAL-LINKS' of the ODX file, inquiring whether the ECU referenced by the BASE-VARIANT-REF of the sub-node is in the result extracted in the step (1), and deleting the link information if the ECU referenced by the BASE-VARIANT-REF of the sub-node is not in the result extracted in the step (1);

f. Deleting the ODX-d file describing the ECU information under the node of directory information "ABLOCK" of the ODX file, and adding the link information of the new file.

According to the embodiment, ECU name information of an actually used diagnosis service is extracted according to an OTX diagnosis test sequence, an ODX diagnosis database is cut and optimized, and a function result executed by the diagnosis test sequence of an ODX file set after optimization is consistent with an execution result before cutting. Based on the OTX diagnosis test sequence, after the ODX diagnosis database is cut and optimized, the size of the occupation of the physical memory of the ROM by the diagnosis test sequence data can be effectively reduced, when an application program uses the cut diagnosis test sequence data source to execute a test function, the resource waste of the CPU of the operating system can be avoided on identifying and analyzing redundant data, so that the operation efficiency of the application can be effectively improved, the task response performance can be improved, the occupation of the physical memory of the RAM can be reduced, and the space of the operating system can be saved.

Based on the processing method of the open type diagnostic data exchange file provided by the embodiment, correspondingly, the application further provides a specific implementation mode of the processing device of the open type diagnostic data exchange file. Please refer to the following examples.

Referring to fig. 7, a processing device 700 for an open diagnostic data exchange file according to an embodiment of the present application may include the following modules: a first acquisition module 701, a second acquisition module 702, and an integration module 703.

The first obtaining module 701 is configured to obtain an open diagnostic data exchange ODX file set of the vehicle, and obtain a target ODX file, where the ODX file set includes at least one ODX file, each ODX file is configured to describe a diagnostic specification of a corresponding ECU, and each ODX file includes diagnostic service information and diagnostic data structure information of the corresponding ECU.

The second obtaining module 702 is configured to obtain, according to the ODX file set, diagnostic data of each ODX file, and obtain diagnostic service information, diagnostic data structure information, and diagnostic service inheritance relationship information of each ECU.

The integrating module 703 is configured to integrate the diagnostic service information and the diagnostic data structure information of each ECU into a target ODX file according to the diagnostic service inheritance relationship information, so as to obtain an integrated target ODX file, where the integrated target ODX file is used for diagnostic testing.

As an implementation manner of the present application, in order to further improve the diagnostic test efficiency, clipping optimization may be performed on data in the ODX file set that is not used by the diagnostic test, where the apparatus 700 may further include:

The third acquisition module is used for acquiring an open test sequence exchange OTX file set of the vehicle, wherein the OTX file set comprises at least one OTX file, each OTX file is used for describing a test sequence corresponding to the ECU, and the OTX files are in one-to-one correspondence with the ODX files;

the fourth acquisition module is used for acquiring a mapping relation based on the OTX file set, wherein the mapping relation is the relation between a target ECU and a corresponding diagnosis service, and the target ECU is the ECU for actually executing the diagnosis service;

the second obtaining module 702 is specifically configured to obtain, based on the mapping relationship, diagnostic data of the ODX file set according to the ODX file set, and obtain diagnostic service information, diagnostic data structure information, and diagnostic service inheritance relationship information of each target ECU.

In some embodiments, the fourth obtaining module may specifically include:

the first acquisition sub-module is used for acquiring the coding information of each OTX file, and the coding information of each OTX file is unique;

the access sub-module is used for sequentially accessing each OTX file according to the coding information of each OTX file;

a traversing sub-module, configured to traverse each sub-node under the execution statement in the main function under the condition that the main function entry node in the OTX file is accessed;

the generating sub-module is used for generating and obtaining a mapping relation based on a first node attribute and a second node attribute of the executing action sub-node when the sub-node is the executing action sub-node and the node type of the executing action sub-node is the target type, wherein the first node attribute is a diagnosis service name, and the second node attribute is an ECU name.

In some embodiments, the generating sub-module may specifically include:

the first acquisition unit is used for acquiring the node type of the action executing sub-node under the condition that the sub-node is the action executing sub-node;

the second obtaining unit is used for obtaining the first node attribute and the second node attribute of the action sub-node under the condition that the node type is a target type, wherein the target type is the node type for executing the diagnostic service step operation;

and the generating unit is used for generating and obtaining the mapping relation based on the first node attribute and the second node attribute.

In some embodiments, the second obtaining module 702 may specifically include:

the second acquisition sub-module is used for scanning the ODX file set and acquiring diagnosis data of each ODX file, wherein the diagnosis data comprises diagnosis layer name information, diagnosis service information, diagnosis data structure information and diagnosis service inheritance relation information;

and the determining submodule is used for determining the diagnosis service information, the diagnosis data structure information and the diagnosis service inheritance relation information of the ODX file as the diagnosis service information, the diagnosis data structure information and the diagnosis service inheritance relation information of the target ECU under the condition that the diagnosis layer name information of the ODX file is consistent with the ECU name in the mapping relation.

In some embodiments, the diagnostic data further includes diagnostic service request information, diagnostic service response information, and diagnostic service negative response information;

the determining submodule may specifically include:

a first determining unit configured to determine, when the diagnostic layer name information of the ODX file is consistent with the ECU name in the mapping relationship, 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 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 a second determination unit configured to determine 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 as diagnostic data structure information of the target ECU.

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

an identification subunit, configured to traverse the target nodes in the diagnostic service request information, the diagnostic service response information, and the diagnostic service negative response information of the target ECU, and identify a data reference type of each target node;

The first determining subunit is used for determining a target data reference strategy matched with the data reference type of the target node in a plurality of preset data reference strategies;

a second determination subunit configured to determine, based on the target data reference policy, diagnostic data structure information of the target node among 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;

and a third determination subunit configured to determine the diagnostic data structure information of each target node as the diagnostic data structure information of the target ECU.

As another implementation of the present application, in order to correctly load the OTX file and the ODX file to execute the corresponding diagnostic test sequence, the apparatus 700 may further include:

and the updating module is used for updating the link information of the integrated target ODX file based on the mapping relation.

Fig. 8 shows a schematic hardware structure of an electronic device according to an embodiment of the present application.

A processor 801 and a memory 802 storing computer program instructions may be included in an electronic device.

In particular, the processor 801 may include a Central Processing Unit (CPU), or an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), or may be configured as one or more integrated circuits that implement embodiments of the present application.

Memory 802 may include mass storage for data or instructions.

In particular embodiments, memory 802 may include Read Only Memory (ROM), random Access Memory (RAM), magnetic disk storage media devices, optical storage media devices, flash memory devices, electrical, optical, or other physical/tangible memory storage devices.

The processor 801 implements the processing method of any of the open diagnostic data exchange files of the above embodiments by reading and executing the computer program instructions stored in the memory 802.

In one example, the electronic device may also include a communication interface 803 and a bus 810. As shown in fig. 8, the processor 801, the memory 802, and the communication interface 803 are connected to each other via a bus 810 and perform communication with each other.

Communication interface 803 is primarily used to implement communication between modules, devices, units, and/or apparatuses in an embodiment of the present application.

Bus 810 includes hardware, software, or both, that couple components of an electronic device to each other. Bus 810 may include one or more buses, where appropriate. Although embodiments of the application have been described and illustrated with respect to a particular bus, the application contemplates any suitable bus or interconnect.

The electronic device can execute the processing method of the open type diagnosis data exchange file in the embodiment of the application, thereby realizing the processing method and the device of the open type diagnosis data exchange file described in connection with fig. 1 and 7.

It should be understood that the application is not limited to the particular arrangements and instrumentality described above and shown in the drawings. For the sake of brevity, a detailed description of known methods is omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method processes of the present application are not limited to the specific steps described and shown, and those skilled in the art can make various changes, modifications and additions, or change the order between steps, after appreciating the spirit of the present application.

The functional blocks shown in the above-described structural block diagrams may be implemented in hardware, software, firmware, or a combination thereof.

Aspects of the present disclosure are described above with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the disclosure. It will be understood that each block of 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 may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions/acts specified in the flowchart and/or block diagram block or blocks.

In the foregoing, only the specific embodiments of the present application are described, and it will be clearly understood by those skilled in the art that, for convenience and brevity of description, the specific working processes of the systems, modules and units described above may refer to the corresponding processes in the foregoing method embodiments, which are not repeated herein. It should be understood that the scope of the present application is not limited thereto, and any equivalent modifications or substitutions can be easily made by those skilled in the art within the technical scope of the present application, and they should be included in the scope of the present application.

Claims (10)

1. A method of processing an open diagnostic data exchange file, comprising:

acquiring an open type diagnosis data exchange ODX file set of a vehicle, and acquiring a target ODX file, wherein the ODX file set comprises at least one ODX file, each ODX file is used for describing diagnosis specifications of a corresponding Electronic Control Unit (ECU), and each ODX file comprises diagnosis service information and diagnosis data structure information corresponding to the ECU;

according to the ODX file set, obtaining diagnosis data of each ODX file, and obtaining diagnosis service information, diagnosis data structure information and diagnosis service inheritance relation information of each ECU;

Integrating the diagnosis service information and the diagnosis data structure information of each ECU into the target ODX file according to the diagnosis service inheritance relation information to obtain an integrated target ODX file, wherein the integrated target ODX file is used for diagnosis test.

2. The method according to claim 1, further comprising, before the obtaining diagnostic data of each of the ODX files, and obtaining diagnostic service information, diagnostic data structure information, and diagnostic service inheritance relationship information of each of the ECUs, according to the ODX file set:

acquiring an open test sequence exchange OTX file set of the vehicle, wherein the OTX file set comprises at least one OTX file, each OTX file is used for describing a test sequence of a corresponding ECU, and the OTX files are in one-to-one correspondence with the ODX files;

based on the OTX file set, a mapping relation is obtained, wherein the mapping relation is the relation between a target ECU and a corresponding diagnosis service, and the target ECU is the ECU for actually executing the diagnosis service;

the obtaining the diagnostic data of each ODX file, and obtaining the diagnostic service information, the diagnostic data structure information and the diagnostic service inheritance relationship information of each ECU according to the ODX file set includes:

Based on the mapping relation, according to the ODX file set, obtaining diagnostic data of the ODX file set, and obtaining diagnostic service information, diagnostic data structure information and diagnostic service inheritance relation information of each target ECU.

3. The method according to claim 2, wherein the obtaining a mapping relationship based on the OTX file set includes:

acquiring the 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;

under the condition of accessing a main function entry node in the OTX file, traversing all child nodes under an execution statement in the main function;

and under the condition that the child node is an executing action child node and the node type of the executing action child node is a target type, generating and obtaining a mapping relation based on a first node attribute and a second node attribute of the executing action child node, wherein the first node attribute is a diagnosis service name, and the second node attribute is an ECU name.

4. The method of claim 3, wherein, in the case that the child node is an execution action child node and the node type of the execution action child node is a target type, generating the mapping relationship according to the first node attribute and the second node attribute of the execution action child node comprises:

Under the condition that the child node is an executing action child node, acquiring the node type of the executing action child node;

under the condition that the node type is a target type, acquiring a first node attribute and a second node attribute of the sub-node for executing the action, wherein the target type is the node type for executing the operation of the diagnostic service step;

and generating a mapping relation based on the first node attribute and the second node attribute.

5. The method according to claim 2, wherein the 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 of the target ECUs based on the mapping relationship according to the ODX file set, includes:

scanning the ODX file set to obtain diagnosis data of each ODX file, wherein the diagnosis data comprises diagnosis layer name information, diagnosis service information, diagnosis data structure information and diagnosis service inheritance relation information;

and under the condition that the name information of the diagnosis layer of the ODX file is consistent with the ECU name in the mapping relation, determining the diagnosis service information, the diagnosis data structure information and the diagnosis service inheritance relation information of the ODX file as the diagnosis service information, the diagnosis data structure information and the diagnosis service inheritance relation information of the target ECU.

6. The method of claim 5, wherein the diagnostic data further comprises diagnostic service request information, diagnostic service response information, and diagnostic service negative response information;

and determining the diagnostic service information, the diagnostic data structure information and the diagnostic service inheritance relation information of the ODX file as the diagnostic service information, the diagnostic data structure information and the diagnostic service inheritance relation information of the target ECU when the diagnostic layer name information of the ODX file is consistent with the ECU name in the mapping relation, including:

determining diagnostic service information, diagnostic service request information, diagnostic service response information, diagnostic service negative response information and diagnostic service inheritance relation information of the ODX file as the diagnostic service information, the diagnostic service request information, the diagnostic service response information, the diagnostic service negative response information and the diagnostic service inheritance relation information of the target ECU under the condition that the diagnostic layer name information of the ODX file is consistent with the ECU name in the mapping relation;

and determining data structure information associated with the diagnosis service request information, the diagnosis service response information and the diagnosis service negative response information of the target ECU as diagnosis data structure information of the target ECU.

7. The method according to claim 6, wherein the determining 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 as the diagnostic data structure information of the target ECU includes:

traversing target nodes in the diagnosis service request information, the diagnosis service response information and the diagnosis service negative response information of the target ECU, and identifying the data reference type of each target node;

determining a target data reference strategy matched with the data reference type of the target node in a plurality of preset data reference strategies;

determining diagnostic data structure information of the target node in data structure information associated with diagnostic service request information, diagnostic service response information and diagnostic service negative response information of the target ECU based on the target data reference policy;

and determining the diagnosis data structure information of each target node as the diagnosis data structure information of the target ECU.

8. The method according to claim 2, wherein after 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, the integrated target ODX file further comprises:

And updating link information for the integrated target ODX file based on the mapping relation.

9. An open diagnostic data exchange file processing apparatus, the apparatus comprising:

the system comprises a first acquisition module, a second acquisition module and a third acquisition module, wherein the first acquisition module is used for acquiring an open type diagnosis data exchange ODX file set of a vehicle and acquiring a target ODX file, the ODX file set comprises at least one ODX file, each ODX file is used for describing a diagnosis specification of a corresponding Electronic Control Unit (ECU), and each ODX file comprises diagnosis service information and diagnosis data structure information corresponding to the ECU;

the second acquisition module is used for acquiring the diagnosis data of each ODX file according to the ODX file set, and acquiring the diagnosis service information, the diagnosis data structure information and the diagnosis service inheritance relation information of each ECU;

the integration module is used for integrating the diagnosis service information and the diagnosis data structure information of each ECU into the target ODX file according to the diagnosis service inheritance relation information to obtain an integrated target ODX file, and the integrated target ODX file is used for diagnosis test.

10. An electronic device, the device comprising: a processor and a memory storing computer program instructions; the processor, when executing the computer program instructions, implements a method for processing an open diagnostic data exchange file as claimed in any one of claims 1 to 8.