Method and device for path parameter searching, electronic equipment and storage medium

Abstract

The application is suitable for the field of automobile electronics, and provides a path parameter searching method and device, electronic equipment and a storage medium. The method comprises the following steps: in response to a parameter searching instruction in an OTX process, determining a target path and the number of layers of the target path according to the parameter searching instruction; determining a target container object from a plurality of first container objects according to the number of layers; each first container object corresponds to a path layer number; the first container object is used for storing a first corresponding relationship, and the first corresponding relationship is a corresponding relationship between a parameter and a path matched with the parameter; and searching by using the target container object according to the target path to obtain a target parameter.

Description

Technical Field

[0001] This application belongs to the field of automotive electronics technology, and in particular relates to a method, apparatus, electronic device and storage medium for pathfinding. Background Technology

[0002] The Open Test Sequence Exchange (OTX) format is a standardized exchange format used to formally describe automated diagnostic sequences for a target vehicle.

[0003] The test sequences are based on Extensible Markup Language (XML) and can be exchanged between process partners with different platforms and diagnostic testers. Diagnostic test sequences are used whenever off-vehicle testing equipment diagnoses, tests, reprograms, or initializes a diagnostically capable automotive component or function.

[0004] When executing OTX test sequences, especially when executing request or response commands, the execution efficiency is low due to the large number and layers of Open Diagnostic eXchange (ODX) files involved and the complex reference relationships within the ODX files. Summary of the Invention

[0005] This application provides a method, apparatus, electronic device, and storage medium for path parameter finding, which can solve the above-mentioned problems.

[0006] In a first aspect, embodiments of this application provide a method for path parameter retrieval, including:

[0007] In response to the parameter query command in the OTX process, the target path and the number of layers of the target path are determined according to the parameter query command;

[0008] Based on the number of layers, a target container object is determined from multiple first container objects; each first container object corresponds to a path layer; the first container object is used to store a first correspondence, which is the correspondence between the parameter and the path that matches the parameter;

[0009] Based on the target path, the target container object is used to perform a retrieval to obtain the target parameters.

[0010] Optionally, determining the target path and the number of layers of the target path according to the parameter search instruction includes:

[0011] The path is determined based on the short name within the layer name element in the parameter search instruction;

[0012] The number of layers is determined based on the number of layer name elements in the parameter search instruction.

[0013] Optionally, before determining the target path and the number of layers of the target path based on the parameter lookup instruction in the OTX process, the method includes:

[0014] Obtain the first container object; the first container object is a key-value pair container object, wherein the key-value pair is a key-value pair consisting of a pointer to the parameter and a path matching the parameter.

[0015] Secondly, embodiments of this application provide a path parameter finding method, including:

[0016] Obtain the target data packet;

[0017] Parse each parameter in the target data packet to obtain the path that matches each parameter and the number of layers in the path;

[0018] For each parameter, based on the number of layers of the path matched by the parameter, the first correspondence is saved to the first container object of the corresponding layer. The first correspondence is the correspondence between the parameter and the path matched by the parameter.

[0019] The first container object is used to determine the target container object based on the number of layers in the target path. The target container object is used to retrieve the target parameters from the target path. The target path and the number of layers are determined based on the parameter search instructions in the OTX process.

[0020] Optionally, the first container object is a key-value pair container object; saving the first correspondence to the first container object of the corresponding level includes:

[0021] Save the pointer to the parameter as the value of the first container object;

[0022] The path that matches the parameter is saved as the key of the first container object of the corresponding layer.

[0023] Optionally, obtaining the path matching each parameter and the number of layers in the path includes:

[0024] The path is determined based on the short name reference relationship of the parameters;

[0025] The number of levels is determined based on the number of jumps referenced by the short name.

[0026] Thirdly, embodiments of this application provide a path parameter finding apparatus, comprising:

[0027] The parameter query instruction response module is used to respond to parameter query instructions in the OTX process and determine the target path and the number of layers of the target path according to the parameter query instructions.

[0028] The target container object determination module is used to determine the target container object from multiple first container objects according to the number of layers; each first container object corresponds to a path layer; the first container object is used to store a first correspondence relationship, which is the correspondence relationship between the parameter and the path that matches the parameter;

[0029] The target parameter acquisition module is used to retrieve target parameters based on the target path using the target container object.

[0030] Optional, the parameter query instruction response module includes:

[0031] The path determination module is used to determine the path based on the short name in the layer name element of the parameter search instruction;

[0032] The path layer number determination module is used to determine the number of layers based on the number of layer name elements in the parameter search instruction.

[0033] Optionally, the device further includes:

[0034] The first container object acquisition module is used to acquire the first container object; the first container object is a key-value pair container object, and the key-value pair is a key-value pair consisting of a pointer to a parameter and a path matching the parameter.

[0035] Fourthly, embodiments of this application provide a path parameter finding apparatus, comprising:

[0036] The target data packet acquisition module is used to acquire target data packets;

[0037] The parameter parsing module is used to parse each parameter in the target data packet, obtain the path matched by each parameter, and the number of layers of the path;

[0038] The matching relationship saving module is used to save a first correspondence to a first container object of the corresponding layer number based on the layer number of the matching path for each parameter. The first correspondence is the correspondence between the parameter and the path matched by the parameter. The first container object is used to determine a target container object based on the layer number of the target path. The target container object is used to retrieve the target parameter from the target path. The target path and the layer number are determined based on the parameter seeking instructions in the OTX process.

[0039] Optionally, the first container object is a key-value pair container object; the matching relationship storage module includes:

[0040] A container object value storage module is used to store the pointer of the parameter as the value of the first container object;

[0041] The container object key saving module is used to save the path that matches the parameter as the key of the first container object of the corresponding layer.

[0042] Optional, the parameter parsing module includes:

[0043] The reference relationship path determination module is used to determine the path based on the short name reference relationship of the parameters;

[0044] The jump count determination module is used to determine the number of levels based on the number of jumps referenced by the short name.

[0045] Fifthly, embodiments of this application provide an electronic device, including:

[0046] A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the method steps of the first aspect and its optional embodiments, and the method steps of the second aspect and its optional embodiments.

[0047] In a sixth aspect, embodiments of this application provide a computer-readable storage medium, comprising: the computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the method steps of the first aspect and its optional embodiments described above, and the method steps of the second aspect and its optional embodiments described above.

[0048] In a seventh aspect, embodiments of this application provide a computer program product that, when run on an electronic device, causes the electronic device to execute the method steps described in the first aspect and its optional embodiments, as well as the method steps described in the second aspect and its optional embodiments.

[0049] It should be understood that by determining the target container based on the path level and retrieving the target parameters from the target container according to the path, each container object corresponds to the path level, and the container object contains the correspondence between parameters and paths. This avoids querying target parameters through reference relationships in ODX files with a large number of files and many levels, thus improving query efficiency. Attached Figure Description

[0050] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0051] Figure 1 This is a schematic flowchart of a path parameter finding method provided in an embodiment of this application;

[0052] Figure 2 This is a flowchart illustrating a path parameter finding method provided in another embodiment of this application;

[0053] Figure 3 This is a schematic flowchart of a data processing method provided in an embodiment of this application;

[0054] Figure 4 This is a schematic flowchart of a path parameter finding method provided in an embodiment of this application;

[0055] Figure 5 This is a schematic diagram of the path parameter finding device provided in the embodiments of this application;

[0056] Figure 6 This is a schematic diagram of the structure of the data processing apparatus provided in the embodiments of this application;

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

[0058] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0059] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0060] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0061] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0062] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0063] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0064] Before explaining the path parameter finding method provided in the embodiments of this application, in order to facilitate the understanding of the embodiments of this application, the principle of the path parameter finding method provided in the embodiments of this application and the related concepts involved in the embodiments of this application will be explained below.

[0065] A container is a class template used to store data. Data structures such as variable-length arrays, linked lists, and balanced binary trees are all implemented as containers in the STL. When a programmer uses a container, that is, when instantiating the container class template into a container class, they specify the type of the elements stored in the container. Containers can store variables of primitive types as well as objects.

[0066] A map, or associative array in computer science, is an abstract data structure that contains unique, ordered pairs (key, value), sorted by key, where each key is unique. For example, a map...<string,int> MyObject2TypeMap, the map stores a series of pairs.<string,int> Object.

[0067] Extensible Markup Language (XML) is a subset of Standard Generalized Markup Language (SGML). XML is a markup language used to structure electronic documents. It can be used to mark up data, define data types, and is a source language that allows users to define their own markup languages. XML is a commonly used data exchange format.

[0068] Open Diagnostic Data Exchange (ODX) is a data file used by standard diagnostic tools (MVCI, Modular Vehicle Communication Interface) defined by the Association for Standardization of Automation and Measuring Systems (ASAM). ODX is a standardized diagnostic file format; when diagnosing different vehicles or different ECUs, only the ODX file adapted to that vehicle model or ECU needs to be loaded, without any changes to the diagnostic tool. ODX unifies the format of diagnostic files, so no format conversion is required when diagnostic files are exchanged between R&D, testing, production, and after-sales departments.

[0069] A short name identifies an ODX object. Its length is limited to 128 characters. A short name consists of letters, numbers, and the underscore ("_") character. The following expression describes the syntax of a short name: [a-zA-Zo-9]+. In all cases where objects can be reused, they are linked to other objects via references (odx links in XML). Because these links should sometimes be created interactively using editor tools, a set of characteristic attributes of an object can be reused via references: the short name (SHORT-NAME) (a unique identifier for this specific object class).

[0070] Open Test sequence exchange (OTX) is a standardized exchange format, standardized in ISO 13209, used to formally describe automated diagnostic sequences, such as system testing or guided debugging.

[0071] Diagnostic sequences are XML-based and can be exchanged between process partners with different platforms and diagnostic testers. Diagnostic test sequences are used whenever off-vehicle testing equipment diagnoses, tests, reprograms, or initializes a diagnostically capable automotive component or function.

[0072] The test sequence in a diagnostic sequence defines the order of interactions between the user (i.e., shop floor or assembly line workers), the diagnostic application (test equipment), and the vehicle communication interface, as well as any calculations and decisions that must be performed. These test sequences are like a series of nodes in a flowchart arranged in a specific order.

[0073] When executing OTX test sequences, especially when executing request or response commands, the number and layers of Open Diagnostic eXchange (ODX) files involved, as well as the complex reference relationships within the ODX files, are significant.

[0074] When executing a request or response command in an OTX test sequence, it is necessary to traverse the ODX file, querying level by level according to the path of the request or response command to obtain the parameters corresponding to that path. These parameters, also known as diagnostic parameters, are used to parse the request command or the data returned by the ECU in the response command. Because this process of querying level by level according to the path of the request or response command is required every time a request or response command is executed, and because of the large number and hierarchy of ODX files and the complex reference relationships within them, execution efficiency is low.

[0075] To address the aforementioned problems, this application provides a method for path parameter finding. Specific embodiments are described below to illustrate the technical solution proposed in this application.

[0076] The path parameter finding method proposed in the embodiments of this application will be described below. This path parameter finding method is applied to electronic devices, which may be vehicle diagnostic equipment, vehicle control equipment, or computing devices such as desktop computers, laptops, handheld computers, smartphones, and cloud servers that have an interface for communication with the vehicle's ECU.

[0077] Figure 1 This application illustrates a pathfinding method provided in an embodiment of the present application, applicable to the aforementioned electronic device, and which can be implemented by the software and / or hardware of the electronic device. For example... Figure 1 As shown, the method includes steps S110 to S130. The specific implementation principle of each step is as follows:

[0078] S110, in response to the parameter lookup instruction in the OTX process, determines the target path and the number of layers of the target path according to the parameter lookup instruction.

[0079] In some embodiments, the parameter search instruction can be a request instruction or a response instruction in an OTX process. When an electronic device executes an OTX process, if the OTX process reaches a node with a request or response instruction, it determines the target path and the layer number of the target path based on the layer name element aggregated in the parameter search instruction node. The layer name element is typically an element named "stepByName".

[0080] In some specific examples, determining the target path and the number of layers of the target path according to the parameter search instruction includes: determining the path according to the short name in the layer name element of the parameter search instruction; and determining the number of layers according to the number of layer name elements in the parameter search instruction.

[0081] For example, see the following code snippet for the OTX response instruction:

[0082] <diag:responseparameters>

[0083] <diag:name value="dummy”xsi:type="StringLiteral” / >

[0084] <diag:responseparam>

[0085] <diag:target name="DIDF187Output”xsi:type="StringVariable”>

[0086] <diag:path>

[0087] <stepByName value=”DataRacord”xsi:type="StringVariable” / >

[0088] <stepByName value=”DIDF187_SparePartNamber_ASCII_80_bits”xsi:type="StringVariable” / >

[0089] < / diag:path>

[0090] < / diag:responseparam>

[0091] < / diag:responseparameters>

[0092] When the OTX process is executed <diag:responseparameters>When processing a node, the parameter lookup instruction corresponding to that node is processed, and the aggregated data is based on the response instruction. <diag:path>Within the node <stepbyname>The number of nodes determines the number of layers. <stepbyname>The "value" in a node corresponds to the short name of the indexed parameter. Combining the "values" in a preset order forms the path of the indexed parameter. The preset order can be the OTX order.

[0093] S120, determine the target container object among the plurality of first container objects according to the number of layers.

[0094] In some embodiments, the electronic device pre-acquires a plurality of first container objects, each of which corresponds to a path layer number; the first container object is used to store a first correspondence, which is the correspondence between a parameter and a path that matches the parameter.

[0095] In some embodiments, the electronic device determines the target container object from multiple first container objects based on the number of path layers. For example, the electronic device pre-obtains three first container objects, where the first first container object corresponds to a parameter with only one path layer, the second first container object corresponds to a parameter with two path layers, and the third first container object corresponds to a parameter with three path layers. Referring to the code snippet above, when the OTX process executes to... <diag:responseparameters>When processing a node, the parameter lookup instruction corresponding to that node is processed, and the aggregated response instruction is used to determine the appropriate response. <diag:path>Within the node <stepbyname>The number of nodes determines the number of layers. If there are two layers, then the second first container object is used as the target container object.

[0096] For example, define three map container objects with different levels:

[0097] map<otxSTRING,otxParameter*> m_SNDirectly2Param is used to store the short name of the request or response command and the corresponding parameter pointer.

[0098] map <otxSTRING,map<otxSTRING,otxParameter*> >m_SNIndirectly2Param is used to store the parameters of request or response commands. The parameters are linked to the last-level parameters through the table key and the pointers to the specific parameters they address. If the table row is not linked to a structure type algorithm, but a DOP (DATA-OBJECT-PROP) type algorithm, then the key of the map is the short name of the DOP.

[0099] map <otxSTRING,map<otxSTRING,map<otxSTRING,otxParameter*> >>m_SNHardly2Param is used to store the connection path of the parameter in the request or response, which is linked to the parameter through the tablerow to the first-level structure algorithm, and the pointer to the specific parameter being addressed, such as the global negative response.

[0100] In the example above, the OTX response command code involves two levels of parameters, therefore the target container object is a map. <otxSTRING,map<otxSTRING,otxParameter*> >m_SNIndirectly2Param object.

[0101] S130, Based on the target path, the target container object is used to perform a retrieval to obtain the target parameters.

[0102] In some embodiments, the electronic device retrieves target parameters using the target container object based on the target path.

[0103] In some embodiments, the first container object is a key-value pair container object, where the key-value pair consists of a pointer to a parameter and a path matching the parameter. Specifically, the path is used as the key, and the pointer to the parameter is used as the value. For example, a map container object: map<otxSTRING,otxParameter*> .

[0104] See the code snippet above. <stepbyname>The "value" in a node corresponds to the short name of the indexed parameter. Combining the "values" in a preset order forms the path of the indexed parameter. This path is used to search within the target container object to obtain a pointer to the target parameter. Furthermore, the target parameter is obtained through the pointer to the target parameter.

[0105] map container object <otxSTRING,map<otxSTRING,otxParameter> Taking `m_SNIndirectly2Param` as an example, when responding to the request command in the code of the above OTX response instruction, it is done through two... <stepbyname>The "value" in the node is indexed level by level to obtain a pointer to the target parameter, and then the target parameter is obtained. Specifically, in the path parameter finding interface called in the OTX process, the find function of the corresponding level of the map container object is called according to the passed parameter path hierarchy to find the correct target parameter object.

[0106] It should be understood that by determining the target container based on the path level and retrieving the target parameters from the target container according to the path, each container object corresponds to the path level, and the container object contains the correspondence between parameters and paths. This avoids querying target parameters through reference relationships in ODX files with a large number of files and many levels, thus improving query efficiency.

[0107] In the above Figure 1 Based on the embodiment of the path parameter finding method shown, before determining the target path and the number of layers of the target path according to the parameter finding instruction in the OTX process, as follows: Figure 2 As shown, it also includes step S010:

[0108] S010, obtain the first container object; the first container object is a key-value pair container object, and the key-value pair is a key-value pair consisting of a pointer to the parameter and a path matching the parameter.

[0109] In some embodiments, the electronic device pre-acquires a plurality of first container objects.

[0110] In some specific examples, the electronic device pre-obtains multiple first container objects by parsing the PDX file package.

[0111] In other specific examples, the car manufacturer provides the server, or a third-party service provider provides the computing device. The server or computing device pre-generates multiple first container objects by parsing the PDX file package. The electronic device obtains the first container objects from the server or computing device via a wired and / or wireless network connection.

[0112] To generate the first container object required in the above embodiments, this application provides a data processing method. This data processing method can be applied to the aforementioned electronic device, as well as to a server provided by an automobile manufacturer, or to a computing device provided by a third party. It can be implemented by the software and / or hardware of the electronic device, server, or computing device.

[0113] Figure 3 This application illustrates a path parameter finding method provided by an embodiment of the present application, which includes steps S310 to S330. The specific implementation principle of each step is as follows:

[0114] S310, acquire the target data packet.

[0115] In some embodiments, the target data packet is an exchange data format data packet, such as an XML data packet. The target data packet may be a diagnostic data packet for a target vehicle. The target vehicle is a vehicle that requires diagnostic testing. The diagnostic data packet may be an ODX protocol-based data file, specifically a PDX file packet.

[0116] In some embodiments, an electronic device, such as a vehicle diagnostic device, obtains the target data packet from a vehicle manufacturer's server. In other embodiments, the vehicle manufacturer's server obtains the target data packet from a memory communicatively coupled thereto. In still other embodiments, a third-party provided computing device obtains the target data packet from the vehicle manufacturer's server.

[0117] S320, parse each parameter in the target data packet, obtain the path matching each parameter, and the number of layers in the path.

[0118] In some embodiments, the parameter lists of request and response commands in the target data packet are traversed to obtain the path that matches each parameter and the number of layers in the path.

[0119] In some specific examples, obtaining the path matched by each parameter and the number of levels of the path includes: determining the path based on the short name reference relationship of the parameters; and determining the number of levels based on the number of jumps of the short name reference.

[0120] It should be understood that short name references for parameters are hierarchical. The number of levels can be determined by referencing short names through request or response commands in the ODX file up to the level pointing to the specific parameter. Short names are then combined hierarchically to form a short name path. This hierarchical combination of short names can be nested or chained.

[0121] S330, for each parameter, based on the number of layers in the path matching the parameter, a first correspondence is saved to a first container object of the corresponding layer number. The first correspondence is the correspondence between the parameter and the path matching the parameter. The first container object is used to determine a target container object based on the number of layers in the target path. The target container object is used to retrieve the target parameter from the target path. The target path and the number of layers are determined based on the parameter seeking instructions in the OTX process.

[0122] In some embodiments, the first container object is a key-value pair container object, such as a map object. Saving the first correspondence to the first container object at the corresponding level includes: saving the pointer to the parameter as the value of the first container object; and saving the path matching the parameter as the key of the first container object at the corresponding level. For example, a map container object...<otxSTRING,otxParameter*> The otxSTRING is used to store the path that matches the parameter, and the otxParameter* is used to store the pointer to the parameter.

[0123] In some embodiments, execute Figure 3 The embodiment shown is executed by the aforementioned electronic device, such as a vehicle diagnostic tool.

[0124] Diagnostic data types for request and response commands can be defined in the code that parses the ODX protocol in an electronic device, and three map container objects can be defined in the diagnostic data types for request and response commands respectively:

[0125] map<otxSTRING,otxParameter*> m_SNDirectly2Param is used to store the short name otxSTRING of the request or response command and the corresponding parameter pointer otxParameter*.

[0126] map <otxSTRING,map<otxSTRING,otxParameter*> >m_SNIndirectly2Param is used to store the parameters of request or response commands. The parameters are linked to the last-level parameters through the table key and the pointers to the specific parameters they address. If the table row is not linked to a structure type algorithm, but a DOP (DATA-OBJECT-PROP) type algorithm, then the key of the map is the short name of the DOP.

[0127] map <otxSTRING,map<otxSTRING,map<otxSTRING,otxParameter*> >>m_SNHardly2Param is used to store the connection path of the parameter in the request or response, which is linked to the parameter through the tablerow to the first-level structure algorithm, and the pointer to the specific parameter being addressed, such as the global negative response.

[0128] When parsing the PDX automotive source files provided by the car manufacturer, the vehicle diagnostic tool stores the parameter lists of the parsed request and response commands into corresponding map containers according to the parameter index hierarchy. When pathfinding is required, the target parameters can be quickly obtained by calling the container object at the corresponding level, without having to repeatedly search in the ODX file, thus improving the operating efficiency of the vehicle diagnostic tool.

[0129] In other embodiments, execution Figure 3 The embodiments shown depict the server or third-party device as the execution entity for each step. In this case, the electronic device obtains the first container object from the server or third-party device. Referring to the above implementation method, the server or third-party device parses the PDX file, stores the parameters in the parsed diagnostic parameter list into the corresponding level of the map container object according to the parameter path hierarchy, and saves them in a form that can be obtained by the electronic device. For example, the map container objects at different levels are saved in the form of a data table.

[0130] It should be noted that this example uses a 3-level path. It should be understood that the actual path can have more or fewer levels, and can be adjusted according to the specific circumstances.

[0131] It is understood that the above examples can be logically combined and added to or subtracted from each other. As examples and not limitations, this application provides, for instance... Figure 4 The specific examples shown are provided to better understand the implementation of the embodiments of this application.

[0132] The processing flow in this example is roughly divided into two stages.

[0133] The first stage is the process of parsing the file package based on the ODX diagnostic protocol to obtain the first container object.

[0134] The first stage can be implemented by electronic devices, servers, or third-party devices. For ease of explanation, the following description will use electronic devices as an example.

[0135] The second stage involves calling the path parameter lookup interface within the OTX process to obtain the target parameters using the first container object. This second stage can be implemented by electronic devices, such as vehicle diagnostic equipment.

[0136] In the first phase, diagnostic data types for request and response commands can be defined in the code parsing the ODX protocol, and three map container objects can be defined in each of these diagnostic data types. In this context, map1, map2, and map3 correspond to the path hierarchy from simple to complex and their mapping relationships to specific parameter objects, respectively.

[0137] Specifically, map1 is a map<otxSTRING,otxParameter*> m_SNDirectly2Param is used to store the short name otxSTRING of the request or response command and the corresponding parameter pointer otxParameter*.

[0138] map2 is a map <otxSTRING,map<otxSTRING,otxParameter*> >m_SNIndirectly2Param is used to store the parameters of request or response commands. The parameters are linked to the last-level parameters through the table key and the pointers to the specific parameters they address. If the table row is not linked to a structure type algorithm, but a DOP (DATA-OBJECT-PROP) type algorithm, then the key of the map is the short name of the DOP.

[0139] map3 is a map <otxSTRING,map<otxSTRING,map<otxSTRING,otxParameter*> >>m_SNHardly2Param is used to store the connection path of the parameter in the request or response, which is linked to the parameter through the tablerow to the first-level structure algorithm, and the pointer to the specific parameter being addressed, such as the global negative response.

[0140] The electronic device retrieves PDX data packets from the car manufacturer's server. The PDX data packets are then parsed. The parsing program of the electronic device provides parsing interfaces for request and response commands, used to traverse the parsed parameter list. During parsing, the parameter path is determined based on the short name reference relationship of the parameters; the number of path levels is determined based on the number of jumps in the short name reference.

[0141] If the parameter path level is 1, then save the parameter pointer and parameter path to map1; if the parameter path level is 2, then save the parameter pointer and parameter path to map2; if the parameter path level is 3, then save the parameter pointer and parameter path to map3.

[0142] In the second stage, when the electronic device executes the OTX process, it encounters parameter-seeking instructions, such as request or response instructions, and needs to obtain parameters based on the parameter path. The electronic device's program can provide a path-seeking interface for OTX process calls. This interface takes the parameter path as input and outputs the target parameter. Within this interface, the layer number of the passed parameter path is determined. If the parameter path layer number is 1, then map1 is used as the target container object; if the parameter path layer number is 2, then map2 is used as the target container object; if the parameter path layer number is 3, then map3 is used as the target container object. The `find` function of the corresponding layer's map container object is called to locate the correct parameter object from the passed parameter path.

[0143] This application, based on the ODX protocol, adds three map container objects to the request and response command types, corresponding to three different levels of diagnostic parameter path mappings from simple to complex to the corresponding diagnostic parameter objects. In the path parameter finding interface of the OTX process call, the `find` function of the corresponding level's map container object is called based on the passed parameter path level to find the correct parameter object. This method is more efficient than directly traversing the parameter list and comparing each parameter for matching.

[0144] This invention stores the parameters from the parsed diagnostic parameter list in advance in the ODX parsing interface of the request and response commands, according to the parameter path hierarchy, into the corresponding map container object. This saves response time and provides a better user experience compared to processing them in the path parameter lookup interface called in the OTX process.

[0145] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0146] Corresponding to the above Figure 1 The path parameter finding method shown is as follows: Figure 5 The illustration shows a pathfinding device M100 provided in an embodiment of this application, comprising:

[0147] The parameter query instruction response module M110 is used to respond to parameter query instructions in the OTX process and determine the target path and the number of layers of the target path according to the parameter query instructions;

[0148] The target container object determination module M120 is used to determine the target container object from multiple first container objects according to the number of layers; each first container object corresponds to a path layer; the first container object is used to store a first correspondence relationship, which is the correspondence relationship between the parameter and the path that matches the parameter;

[0149] The target parameter acquisition module M130 is used to retrieve target parameters based on the target path using the target container object.

[0150] Optional, the parameter query instruction response module includes:

[0151] The path determination module is used to determine the path based on the short name in the layer name element of the parameter search instruction;

[0152] The path layer number determination module is used to determine the number of layers based on the number of layer name elements in the parameter search instruction.

[0153] Optionally, the device further includes:

[0154] The first container object acquisition module is used to acquire the first container object; the first container object is a key-value pair container object, and the key-value pair is a key-value pair consisting of a pointer to a parameter and a path matching the parameter.

[0155] It is understood that the various implementation methods and combinations of implementation methods in the above embodiments and their beneficial effects are also applicable to this embodiment, and will not be repeated here.

[0156] Corresponding to the above Figure 3 The path parameter finding method shown is as follows: Figure 6 The illustration shows a data processing apparatus M200 provided in an embodiment of this application, comprising:

[0157] The target data packet acquisition module M210 is used to acquire target data packets;

[0158] The parameter parsing module M220 is used to parse each parameter in the target data packet, obtain the path matched by each parameter, and the number of layers of the path;

[0159] The matching relationship storage module M230 is used to store a first correspondence relationship for each parameter in a first container object corresponding to the number of layers of the matching path. The first correspondence relationship is the correspondence between the parameter and the path matched by the parameter. The first container object is used to determine a target container object based on the number of layers of the target path. The target container object is used to retrieve the target parameter from the target path. The target path and the number of layers are determined based on the parameter search instructions in the OTX process.

[0160] Optionally, the first container object is a key-value pair container object; the matching relationship storage module includes:

[0161] A container object value storage module is used to store the pointer of the parameter as the value of the first container object;

[0162] The container object key saving module is used to save the path that matches the parameter as the key of the first container object of the corresponding layer.

[0163] Optional, the parameter parsing module includes:

[0164] The reference relationship path determination module is used to determine the path based on the short name reference relationship of the parameters;

[0165] The jump count determination module is used to determine the number of levels based on the number of jumps referenced by the short name.

[0166] It is understood that the various implementation methods and combinations of implementation methods in the above embodiments and their beneficial effects are also applicable to this embodiment, and will not be repeated here.

[0167] Figure 7 This is a schematic diagram of an electronic device provided according to an embodiment of this application. This electronic device is used to implement the electronic device, server, or third-party computing device described in the above embodiments. Figure 7 As shown, the electronic device D10 of this embodiment includes: at least one processor D100 ( Figure 7 (Only one is shown) a processor, a memory D101, and a computer program D102 stored in the memory D101 and executable on the at least one processor D100, wherein the processor D100 executes the computer program D102 to implement the steps in any of the above method embodiments.

[0168] In some embodiments, when the processor D100 executes the computer program D102, it performs the following steps: in response to a parameter lookup instruction in the OTX process, it determines the target path and the number of layers of the target path according to the parameter lookup instruction;

[0169] Based on the number of layers, a target container object is determined from multiple first container objects; each first container object corresponds to a path layer; the first container object is used to store a first correspondence, which is the correspondence between the parameter and the path that matches the parameter;

[0170] Based on the target path, the target container object is used to perform a retrieval to obtain the target parameters.

[0171] Optionally, when the processor D100 executes the computer program D102 to determine the target path and the number of layers of the target path according to the parameter search instructions, the following steps are specifically implemented:

[0172] The path is determined based on the short name within the layer name element in the parameter search instruction;

[0173] The number of layers is determined based on the number of layer name elements in the parameter search instruction.

[0174] Optionally, the processor D100 executes the computer program D102, which, before determining the target path and the number of layers of the target path according to the parameter lookup instruction in the OTX process, further implements the following steps:

[0175] Obtain the first container object; the first container object is a key-value pair container object, wherein the key-value pair is a key-value pair consisting of a pointer to the parameter and a path matching the parameter.

[0176] In some embodiments, when the processor D100 executes the computer program D102, it performs the following steps: acquiring a target data packet;

[0177] Parse each parameter in the target data packet to obtain the path that matches each parameter and the number of layers in the path;

[0178] For each parameter, based on the number of layers of the path matched by the parameter, the first correspondence is saved to the first container object of the corresponding layer. The first correspondence is the correspondence between the parameter and the path matched by the parameter.

[0179] The first container object is used to determine the target container object based on the number of layers in the target path. The target container object is used to retrieve the target parameters from the target path. The target path and the number of layers are determined based on the parameter search instructions in the OTX process.

[0180] Optionally, the first container object is a key-value pair container object; when the processor D100 executes the computer program D102 to implement the step of saving the first correspondence to the first container object of the corresponding level, the following steps are specifically implemented:

[0181] Save the pointer to the parameter as the value of the first container object;

[0182] The path that matches the parameter is saved as the key of the first container object of the corresponding layer.

[0183] Optionally, when the processor D100 executes the computer program D102 to obtain the path matching each parameter and the number of layers of the path, the following steps are specifically implemented:

[0184] The path is determined based on the short name reference relationship of the parameters;

[0185] The number of levels is determined based on the number of jumps referenced by the short name.

[0186] The electronic device D10 can be a desktop computer, laptop, handheld computer, cloud server, or other computing device. This electronic device may include, but is not limited to, a processor D100 and a memory D101. Those skilled in the art will understand that... Figure 7 This is merely an example of electronic device D10 and does not constitute a limitation on electronic device D10. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0187] The processor D100 can be a Central Processing Unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0188] In some embodiments, the memory D101 may be an internal storage unit of the electronic device D10, such as a hard disk or memory of the electronic device D10. In other embodiments, the memory D101 may be an external storage device of the electronic device D10, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device D10. Furthermore, the memory D101 may include both internal and external storage units of the electronic device D10. The memory D101 is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory D101 can also be used to temporarily store data that has been output or will be output.

[0189] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0190] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0191] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the steps in the above-described method embodiments.

[0192] This application provides a computer program product that, when run on an electronic device, enables the electronic device to implement the steps described in the various method embodiments above.

[0193] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographic device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

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

[0195] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0196] In the embodiments provided in this application, it should be understood that the disclosed apparatus / network devices and methods can be implemented in other ways. For example, the apparatus / network device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

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

[0198] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.< / stepbyname> < / stepbyname> < / stepbyname> < / diag:path> < / diag:responseparameters> < / stepbyname> < / stepbyname> < / diag:path> < / diag:responseparameters>

Claims

1. A method for path parameter finding, characterized in that, include: In response to the OTX process reaching a parameter lookup instruction, the target path and the number of layers in the target path are determined based on the aggregated layer name element in the parameter lookup instruction, including: The path is determined based on the short name within the layer name element in the parameter search instruction; The number of layers is determined based on the number of layer name elements in the parameter search instruction; The parameter search instruction is a request instruction or response instruction in the OTX process. When the OTX process executes to... <diag:responseparameters>When processing a node, the parameter lookup instructions corresponding to that node are processed, and the aggregated responses are used to determine the appropriate parameters. <diag:path>Within the node <stepbyname>The number of nodes determines the number of layers; <stepbyname> The "value" in the node corresponds to the short name of the index parameter. Combining the "value" in a preset order forms the path of the index parameter. The preset order is the OTX order.< / stepbyname> < / stepbyname> < / diag:path> < / diag:responseparameters> Based on the number of layers, a target container object is determined among multiple first container objects; each first container object corresponds to a path layer; the first container object is used to store a first correspondence, which is the correspondence between a parameter and the path that matches the parameter; wherein, the electronic device has pre-acquired multiple first container objects, the first container object is a key-value pair container object, the key-value pair is a key-value pair consisting of a pointer to the parameter and the path that matches the parameter, the path is used as the key, and the pointer to the parameter is used as the value, the parameter is also called a diagnostic parameter, used to parse the request command, or to parse the data returned by the ECU in the response command; Based on the target path, the target container object is used to perform a retrieval to obtain the target parameters.

2. A data processing method, characterized in that, include: Obtain the target data packet; Parse each parameter in the target data packet to obtain the path matching each parameter and the layer number of the path, including: The path is determined based on the short name reference relationship of the parameters; the level is determined based on the number of jumps in the short name reference; wherein, when the OTX process executes to the response instruction... <diag:responseparameters>When processing a node, the parameter lookup instructions corresponding to that node are processed, and the aggregated responses are used to determine the appropriate parameters. <diag:path>Within the node <stepbyname>The number of nodes determines the number of layers; <stepbyname> The "value" in the node corresponds to the short name of the index parameter. Combining the "value" in a preset order forms the path of the index parameter. The preset order is the OTX order. The parameter search instruction is a request instruction or response instruction in the OTX process.< / stepbyname> < / stepbyname> < / diag:path> < / diag:responseparameters> For each parameter, based on the number of layers in the path matching the parameter, a first correspondence is saved to a first container object of the corresponding layer. The first correspondence is the correspondence between the parameter and the path matching the parameter. The first container object is used to determine a target container object based on the number of layers in the target path. The target container object is used to retrieve the target parameter from the target path. The target path and the number of layers are determined based on the parameter search instructions in the OTX process. The first container object is a key-value pair container object. Saving the first correspondence to the first container object of the corresponding layer includes: saving the pointer of the parameter as the value of the first container object; saving the path matching the parameter as the key of the first container object of the corresponding layer. The parameter is also called a diagnostic parameter and is used to parse the request instruction or the data returned by the ECU in the response instruction. The first container object is used to determine the target container object based on the number of layers in the target path. The target container object is used to retrieve the target parameters from the target path. The target path and the number of layers are determined based on the parameter search instructions in the OTX process.

3. A pathfinding device, characterized in that, include: The parameter lookup instruction response module is used to respond to the execution of a parameter lookup instruction in the OTX process, and to determine the target path and the layer number of the target path based on the aggregated layer name element in the parameter lookup instruction, including: The path is determined based on the short name within the layer name element in the parameter search instruction; The number of layers is determined based on the number of layer name elements in the parameter search instruction; The parameter search instruction is a request instruction or response instruction in the OTX process. When the OTX process executes to... <diag:responseparameters>When processing a node, the parameter lookup instruction corresponding to that node is processed, and the aggregated data is based on the response instruction. <diag:path>Within the node <stepbyname>The number of nodes determines the number of layers; <stepbyname> The "value" in the node corresponds to the short name of the index parameter. Combining the "value" in a preset order forms the path of the index parameter. The preset order is the OTX order.< / stepbyname> < / stepbyname> < / diag:path> < / diag:responseparameters> The target container object determination module is used to determine the target container object from multiple first container objects according to the number of layers; each first container object corresponds to a path layer number; the first container object is used to store a first correspondence relationship, which is the correspondence relationship between the parameter and the path that matches the parameter; wherein, the electronic device has pre-acquired multiple first container objects, the first container object is a key-value pair container object, the key-value pair is a key-value pair consisting of the pointer of the parameter and the path that matches the parameter, the path is used as the key, and the pointer of the parameter is used as the value, the parameter is also called diagnostic parameter, used to parse the request command, or parse the data returned by the ECU in the response command; The target parameter acquisition module is used to retrieve target parameters based on the target path using the target container object.

4. A data processing apparatus, characterized in that, include: The target data packet acquisition module is used to acquire target data packets; The parameter parsing module is used to parse each parameter in the target data packet, obtain the path matching each parameter, and the layer number of the path, including: The path is determined based on the short name reference relationship of the parameters; the level is determined based on the number of jumps in the short name reference; wherein, when the OTX process executes to the response instruction... <diag:responseparameters>When processing a node, the parameter lookup instruction corresponding to that node is processed, and the aggregated data is based on the response instruction. <diag:path>Within the node <stepbyname>The number of nodes determines the number of layers; <stepbyname> The "value" in the node corresponds to the short name of the index parameter. Combining the "value" in a preset order forms the path of the index parameter. The preset order is the OTX order. The parameter search instruction is a request instruction or response instruction in the OTX process.< / stepbyname> < / stepbyname> < / diag:path> < / diag:responseparameters> A matching relationship storage module is used to store a first correspondence relationship for each parameter in a first container object corresponding to the number of layers of the matching path. The first correspondence relationship is the relationship between the parameter and the path it matches. The first container object is used to determine a target container object based on the number of layers of the target path. The target container object is used to retrieve the target parameter from the target path. The target path and the number of layers are determined based on parameter seeking instructions in the OTX process. The first container object is a key-value pair container object. Storing the first correspondence relationship in the first container object corresponding to the number of layers includes: storing the pointer of the parameter as the value of the first container object; storing the path matching the parameter as the key of the first container object corresponding to the number of layers. The parameter, also called a diagnostic parameter, is used to parse request instructions or data returned by the ECU in response instructions.

5. An electronic device comprising a memory, a processor, and a computer program stored in the memory and capable of running on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in claim 1 or 2.

6. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in claim 1 or 2.

Images