UDS diagnostic protocol parsing and execution method and system, electronic device and storage medium

Abstract

The application discloses a UDS diagnosis protocol analysis and execution method and system, electronic equipment and a storage medium, and relates to the field of vehicle diagnosis. The method comprises the following steps: a UDS service abstraction step, a UDS service message encoding and decoding step, a data block abstraction step, a data block serialization and analysis step, a result determination step, an execution control step, an interface configuration step, a solidification and storage step, and a loading and reuse step. Through the above scheme, a user can obtain a list of options such as a report, and can understand the required diagnosis option service content, thereby greatly reducing the use threshold of the diagnosis service, and greatly facilitating the use of UDS service participants in the whole life cycle of vehicle research, production and maintenance. Only by operating the friendly interface of the upper computer software, the meaning of the option content of all messages can be understood.

Description

Technical Field

[0001] This application relates to the field of vehicle diagnostics, and in particular to UDS diagnostic protocol parsing and execution methods, UDS diagnostic protocol parsing and execution systems, electronic devices, storage media, and vehicle diagnostic platforms. Background Technology

[0002] Most existing tools can send / receive corresponding messages starting from the services defined by the protocol. However, this operation generally requires the participation of technical personnel to edit, send, decode, and read the messages. This process is technically demanding, inefficient, and prone to errors.

[0003] Therefore, a solution for parsing and executing the UDS diagnostic protocol is needed, providing a user-friendly interface for understanding the required diagnostic options and business content, thus lowering the barrier to entry for diagnostic services. For the service itself and different service IDs such as 0x22 and 0x31, it is proposed to dynamically load them using configuration files, significantly improving the flexibility and applicability of message parsing. After decoding the meaning of all messages, the solution can determine the result of one or more items in the business meaning set. Summary of the Invention

[0004] The purpose of this invention is to provide a UDS diagnostic protocol parsing and execution method, a UDS diagnostic protocol parsing and execution system, an electronic device, a storage medium, and a vehicle diagnostic platform, which at least solves the problem of understanding the required diagnostic options and business content through a graphical interface, the problem of dynamically loading in the form of configuration files, and the technical problem of determining the result of one or more items in the business meaning set.

[0005] This invention provides the following solution:

[0006] According to one aspect of the present invention, a method for parsing and executing a UDS diagnostic protocol is provided, the method comprising:

[0007] The steps of UDS service abstraction, UDS service message encoding and decoding, data block abstraction, data block serialization and parsing, result determination, execution control, interface configuration, hardening and saving, and loading and reuse.

[0008] The steps of UDS service abstraction include abstracting the UDS service into SID, sub-functions, ID, and data blocks;

[0009] The steps for encoding and decoding UDS service messages include: abstracting the corresponding UDS service into SID, sub-function, ID, and data block; setting up the UDS service message parsing process and the UDS service message encoding process.

[0010] The steps of data block abstraction include: obtaining the template of the corresponding data block based on the data block abstraction process; the template of the corresponding data block includes the correspondence between the data in the data block and the meaning items of the template;

[0011] The steps of data block serialization and data block parsing include arranging the data of the meaning items into a message according to the template and restoring the message into the data of the corresponding meaning items;

[0012] The steps for determining the result include: setting preset judgment conditions for key business meaning items; and determining the result status after service execution based on the preset judgment conditions for key business meaning items.

[0013] The steps for execution control include setting the execution parameters required by the service and controlling the execution of the service based on the execution parameters;

[0014] The steps for configuring the interface include setting or configuring relevant options and operation windows for services, data blocks, and execution control through the interface;

[0015] The process of solidifying and saving includes solidifying reproducible data and processes into a loadable template for re-parse and execute of the UDS diagnostic protocol;

[0016] The loading reuse steps include loading a loadable template and reproducing reproducible data and processes; loading a loadable template and reproducing reproducible data and processes includes verifying the validity of the template.

[0017] Furthermore, the data block abstraction step also includes:

[0018] Based on data block abstraction, the process includes steps for setting major categories, structural abstraction, position and length processing, meaning item processing, and abstract node definition.

[0019] The steps for setting up major categories include abstracting data blocks into ordinary data blocks, DID data blocks, and RID data blocks;

[0020] Among them, data blocks are used to represent business meaning items;

[0021] It also includes that a data block corresponds to one or more meaning items.

[0022] Furthermore, the structural abstraction steps include:

[0023] The organization of each meaning item is abstracted into a tree-like node architecture;

[0024] The organization of each meaningful item is abstracted into a tree-like node architecture, which does not extend the tree-like nodes according to the data type of the node, such as numeric, structure, string, array or enumeration.

[0025] Based on the structure of abstracting the organization of each meaning item into a tree-like node, the meaning items are visited.

[0026] Furthermore, the position and length processing steps also include:

[0027] Based on the tree-like structure that abstracts the organization of each meaning item, the meaning items of string, numeric and enumeration data types have a fixed word length; among them, the string meaning item determines the number of bytes it occupies based on the preset maximum byte length.

[0028] Structured data types also include union meaning items;

[0029] The term "consortium" contains multiple terms.

[0030] The meaning of a concatenation is that it contains multiple meanings, and each meaning is either concatenated or occupies a single byte.

[0031] Furthermore, the steps for processing the meaning item also include:

[0032] Since the nodes are numerical data types, physical quantity units are added after calculation according to preset rules to express the meaning of the data.

[0033] Furthermore, the steps for defining the abstract node also include:

[0034] Nodes include basic nodes and special nodes;

[0035] The attributes of a basic node include name, description, basic type, extended type, child nodes, sibling nodes, array length, and loop start node;

[0036] The attributes of special nodes include attributes defined separately in addition to those based on those of basic nodes;

[0037] Based on separately defined attributes, the enumeration data type node includes, ensuring the correspondence between enumeration values ​​and enumeration strings;

[0038] Numeric data type nodes include ensuring that the Factor property is 1 by default, the Offset property is 0 by default, the Unit property is empty by default, the Mask property is 0xffffffff by default, and the shift property is 0 by default.

[0039] The character data type node must include the encoding method, which defaults to ASCII.

[0040] According to two aspects of the present invention, a UDS diagnostic protocol parsing and execution system is provided, the UDS diagnostic protocol parsing and execution system comprising:

[0041] The module includes modules for UDS service abstraction, UDS service message encoding and decoding, data block abstraction, data block serialization and parsing, result determination, execution control, interface configuration, hard storage, and loading and reuse.

[0042] The UDS service abstraction module is used to abstract UDS services into SID, sub-functions, ID, and data blocks;

[0043] The module for UDS service message encoding and decoding is used to abstract the corresponding UDS service into SID, sub-function, ID and data block, and to set the UDS service message parsing process and UDS service message encoding process.

[0044] The data block abstraction module is used to process data block abstractions and obtain the template of the corresponding data block; the template of the corresponding data block includes the correspondence between the data in the data block and the meaning items of the template;

[0045] The data block serialization and data block parsing module is used to arrange the meaning item data into a message according to the template and to restore the message into the corresponding meaning item data;

[0046] The result determination module is used to set preset key business meaning item determination conditions; and to determine the result status after service execution based on the preset key business meaning item determination conditions.

[0047] The execution control module is used to set the execution parameters required by the service and control the execution of the service based on the execution parameters;

[0048] The interface configuration module is used to set or configure options and operation windows for services, data blocks, and execution control through the interface;

[0049] The solidified and stored module is used to solidify reproducible data and processes into a loadable template for re-parse and execute the UDS diagnostic protocol;

[0050] Loading reusable modules is used to load loadable templates and reproduce reproducible data and processes; loading loadable templates and reproducing reproducible data and processes includes verifying the validity of the template.

[0051] According to three aspects of the present invention, an electronic device is provided, comprising: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0052] The memory stores a computer program, which, when executed by the processor, causes the processor to perform the steps of the UDS diagnostic protocol parsing and execution method.

[0053] According to four aspects of the present invention, a computer-readable storage medium is provided storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of the UDS diagnostic protocol parsing and execution method.

[0054] According to five aspects of the present invention, a vehicle diagnostic platform is provided, comprising:

[0055] An electronic device for implementing the steps of the UDS diagnostic protocol parsing and execution method described above;

[0056] The processor runs a program, and when the program runs, it executes the steps of the UDS diagnostic protocol parsing and execution method based on the data output from the electronic device.

[0057] A storage medium for storing a program that, when running, executes the steps of the UDS diagnostic protocol parsing and execution method on data output from an electronic device.

[0058] The above solution achieves the following beneficial technical effects:

[0059] This application allows users to configure options on the interface, similar to filling out a survey form, to select and fill in the required diagnostic options. After submission, the interface tool processes the data internally and provides feedback on the results through the interface as well. Users will receive an option list similar to a report, which allows them to understand the required diagnostic options and business content. This greatly lowers the barrier to entry for diagnostic services and significantly facilitates the use of UDS services by all personnel involved in the entire lifecycle of vehicle R&D, production, and maintenance. Users only need to operate the user-friendly host computer software to understand the meaning of all message options.

[0060] This application significantly improves the flexibility and applicability of message parsing by dynamically loading the different ID content of the service itself and services 0x22, 0x2E, and 0x31 using configuration files. It also effectively enhances the adaptability of messages when IDs are modified, decoupling the development of the host computer software from the development of various vehicle-mounted system processes. Users only need to replace the configuration file according to the vehicle model and version to use the matching diagnostic message set. Alternatively, it matches the built-in UDS service configuration table according to the vehicle identification code, automatically loading the UDS message service configuration table matching the vehicle identifier. This achieves fully automated message matching and parsing, further reducing the difficulty of use and eliminating human errors such as incorrect meaning configurations due to decoding errors.

[0061] This application decodes the meaning of all messages to transform the content of a specific ID message into a set of business meanings. This allows for result determination on one or more items within the set of business meanings. Furthermore, it enables result determination on some business meaning items fed back by the vehicle system during the UDS service process, based on their type. By pre-arranging these determinations and executing different subsequent steps according to different determination results, a complete and selective branch execution path can be obtained, along with a clear and definite result on whether the execution was successful. Attached Figure Description

[0062] Figure 1 This is a schematic diagram of a diagnostic request message format provided in a specific embodiment of the present invention.

[0063] Figure 2 This is a schematic diagram illustrating a diagnostic message example provided in a specific embodiment of the present invention.

[0064] Figure 3 This is a schematic diagram of a diagnostic service list provided in a specific embodiment of the present invention.

[0065] Figure 4 This is a schematic diagram of a 0x22 service request message format provided in a specific embodiment of the present invention.

[0066] Figure 5 This is a schematic diagram of a 0x31 service request message format provided in a specific embodiment of the present invention.

[0067] Figure 6 This is a schematic diagram illustrating a 0x22 service message and its meaning, provided in a specific embodiment of the present invention.

[0068] Figure 7 This is a schematic diagram illustrating a 0x19 service message and its meaning, provided in a specific embodiment of the present invention.

[0069] Figure 8 This is a schematic diagram of a UDS service message parsing process provided in a specific embodiment of the present invention.

[0070] Figure 9 This is a schematic diagram of a UDS service message encoding process provided in a specific embodiment of the present invention.

[0071] Figure 10 This is a schematic diagram of a DTC fault code definition provided in a specific embodiment of the present invention.

[0072] Figure 11 This is a schematic diagram of a fault code definition provided in a specific embodiment of the present invention.

[0073] Figure 12This is a schematic diagram of a data block serialization process provided in a specific embodiment of the present invention.

[0074] Figure 13 This is a schematic diagram of a node serialization process provided in a specific embodiment of the present invention.

[0075] Figure 14 This is a schematic diagram of a data block parsing process provided in a specific embodiment of the present invention.

[0076] Figure 15 This is a schematic diagram of a node parsing process provided in a specific embodiment of the present invention.

[0077] Figure 16 This is a schematic diagram illustrating an FDA0 business example provided in a specific embodiment of the present invention.

[0078] Figure 17 This is a schematic diagram illustrating an abstract example of an FDA0 meaning item provided in a specific embodiment of the present invention.

[0079] Figure 18 This is a schematic diagram illustrating an example of the value of the FDA0 meaning item provided in a specific embodiment of the present invention.

[0080] Figure 19 This is a flowchart of a UDS diagnostic protocol parsing and execution method provided by one or more embodiments of the present invention.

[0081] Figure 20 This is a structural diagram of a UDS diagnostic protocol parsing and execution system provided by one or more embodiments of the present invention.

[0082] Figure 21 This is a block diagram of an electronic device structure for a UDS diagnostic protocol parsing and execution method provided in one or more embodiments of the present invention. Detailed Implementation

[0083] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0084] Figure 19 This is a flowchart of a UDS diagnostic protocol parsing and execution method provided by one or more embodiments of the present invention.

[0085] like Figure 19 The UDS diagnostic protocol parsing and execution methods shown include:

[0086] The steps of UDS service abstraction, UDS service message encoding and decoding, data block abstraction, data block serialization and parsing, result determination, execution control, interface configuration, hardening and saving, and loading and reuse.

[0087] The steps of UDS service abstraction include abstracting the UDS service into SID, sub-functions, ID, and data blocks;

[0088] The steps for encoding and decoding UDS service messages include: abstracting the corresponding UDS service into SID, sub-function, ID, and data block; setting up the UDS service message parsing process and the UDS service message encoding process.

[0089] The steps of data block abstraction include: obtaining the template of the corresponding data block based on the data block abstraction process; the template of the corresponding data block includes the correspondence between the data in the data block and the meaning items of the template;

[0090] The steps of data block serialization and data block parsing include arranging the data of the meaning items into a message according to the template and restoring the message into the data of the corresponding meaning items;

[0091] The steps for determining the result include: setting preset judgment conditions for key business meaning items; and determining the result status after service execution based on the preset judgment conditions for key business meaning items.

[0092] The steps for execution control include setting the execution parameters required by the service and controlling the execution of the service based on the execution parameters;

[0093] The steps for configuring the interface include setting or configuring relevant options and operation windows for services, data blocks, and execution control through the interface;

[0094] The process of solidifying and saving includes solidifying reproducible data and processes into a loadable template for re-parse and execute of the UDS diagnostic protocol;

[0095] The loading reuse steps include loading a loadable template and reproducing reproducible data and processes; loading a loadable template and reproducing reproducible data and processes includes verifying the validity of the template.

[0096] Specifically, in one particular embodiment, a series of related strategies are disclosed, including UDS service abstraction, UDS message encoding and decoding process, data block abstraction, data block encoding and decoding process, execution process abstraction, and execution condition model.

[0097] For example, in the steps of UDS service abstraction, UDS service abstraction is based on the ISO14229 protocol. For a UDS message, it is abstracted into several parts: SID (mandatory), one SID corresponds to one type of service item, 1 byte in length, which can be used as an identifier; Sub-function (optional), for some SIDs, it may include sub-service items, 1 byte in length. Whether a specific SID contains a sub-function is determined. ID (optional for some services), required for specific SID and / or sub-function combinations (e.g., 0x22 service, 0x2E service, 0x31 service 01 sub-function, 02 function, 03 sub-function, etc.), 2 bytes in length; Data block, for specific SID and / or sub-function combinations, may include data blocks of different lengths. Therefore, for a UDS service, a specific service can be abstracted as: SID, whether it contains a sub-service, sub-service ID, whether it contains a data ID, data ID, and data block.

[0098] For example, in the steps of UDS service message encoding and decoding, such as Figure 8 The UDS service message parsing process shown is as follows: Figure 9 The UDS service message encoding process shown is as follows: UDS service message encoding and decoding is based on the list of services supported by the vehicle host and the list of sub-services of the services, and converts service information and message information to each other according to certain rules to achieve encoding and decoding.

[0099] For example, in the data block abstraction step, the role of the data block region is to transmit some business item data. For a specific service, sub-service, or ID combination, the meaning of the data block is fixed. Therefore, the data block abstraction step strives to establish an abstraction mechanism so that for any data block, a template can be extracted. Based on the template, the data within the data block can be mapped one-to-one with the meaning items of the template, thereby achieving software encoding and decoding, which serves as the basis for subsequent execution path determination based on the meaning.

[0100] For example, in the data block serialization and parsing steps, data block serialization, based on the steps mentioned above, involves abstracting a template for any given combination of SID, sub-service, and data ID, if it contains data blocks. The template contains a set of meaning items. Knowing the values ​​of all meaning items, the template is used to arrange the data of the meaning items into a message according to rules; this is the serialization process in this step. The flow involves accessing the root node and performing a depth-first traversal. For each accessed node, the data value is converted into a message according to the aforementioned rules and appended to the end of the data block until all accesses are completed. This process includes, for example,... Figure 12 The data block serialization process shown includes accessing nodes and serializing them, as follows: Figure 13 The node serialization process is shown.

[0101] Corresponding to the aforementioned data block serialization, for any given combination of SID, sub-service, and data ID, if it contains data blocks, the message can be mapped to the meaning item according to the rules using the abstract template of the meaning item. All values ​​of the meaning items are then parsed from the message; this is data block parsing, or deserialization. The process involves accessing the root node and performing a depth-first traversal. For each accessed node, a message of the corresponding length is retrieved according to the aforementioned rules and converted into data values, until all data blocks have been accessed. The data block parsing process includes, for example: Figure 14 The data block parsing process shown is as follows: Figure 15 The node parsing process is shown below.

[0102] The steps of data block serialization and parsing complete the bidirectional conversion between message and business meaning item set, clarify the segmentation and correspondence rules of message and business meaning item, as well as the mutual conversion rules. The process does not require manual intervention. The software can directly display the value of any business meaning item in any service message, or modify any meaning item, and automatically generate a message.

[0103] For example, in the result determination step, based on the above steps, it is possible to anticipate the business meaning of the response message before a service instruction is executed. Furthermore, through the interface, operators can determine some important business meaning items to confirm whether they meet expectations.

[0104] For different types of numbers, different expected methods can be set. For example, for numeric types, several conditions such as greater than, greater than or equal to, less than, less than or equal to, equal to, and not equal to are required to meet actual business judgment needs. For string types, conditions such as equal to, contain, are contained, and whether the first three conditions are case sensitive are required. For other types, conditions such as equal to and not equal to are required.

[0105] Furthermore, by setting judgment conditions for one or more key parameters through the interface, the software can judge the execution result after the service is executed.

[0106] For example, in the execution control process, after obtaining the execution result, if some execution parameters required by the business are still needed, the execution can be controlled to be closer to the actual needs. For instance, it may be necessary to set the waiting time before execution, the waiting time after execution, the number of loops, the limit on the number of retries after failure, the retry time limit after failure, the retry interval, and whether to continue executing subsequent instructions or terminate execution after a retry still fails.

[0107] For example, in the interface configuration steps, all options and attributes involved in the above abstraction method and execution process can be configured through the interface. For instance, through a new user interface, the service ID input box allows you to check / uncheck whether it can contain sub-services, the sub-service ID input box allows you to check / uncheck whether it can contain data IDs, the data ID input box allows you to check whether it can contain data blocks, and the data block length input box. This forms the configuration options for a service, sub-services (if any), data IDs (if any), and data blocks (if any).

[0108] Similarly, when configuring a data block through the interface, a new node option is provided. The node editing interface provides name and remarks input boxes, dropdown menus for selecting the basic type, and dropdown menus for selecting the extended type. When the basic type is numeric, input boxes for Factor, Offset, Unit, Mask, and Shift are displayed. When an enumeration type is selected, a double-row input table is provided for entering the enumeration meaning and value. When adding a root node, if no node is selected and adding a node is clicked, the last sibling node of the root node is first found (if none exists, it is added as a sibling node of the root node) and added to its sibling node. If a node is selected, it is first checked for child nodes. If none exist, it is directly added to its child nodes; if child nodes exist, the last sibling node of the child node is found (if no sibling node exists, the child node itself is added) and added to its sibling node. In summary, the required tree structure and the attributes required for each node can be configured through the interface.

[0109] For example, in the process of solidifying and saving, based on the abstracts and templates mentioned above, the data can be solidified by saving it as a file for future use.

[0110] For example, the above landline strategies can be summarized into three categories of documents.

[0111] For example, the first type of file is a service template, which lists the key attributes one by one and saves all the supported services to a list, thus obtaining a complete list of supported services.

[0112] The file format can be XML, JSON, or a custom binary format, and it can also be managed using a database.

[0113] The second type of file is the data block template, which lists the key attributes of the data block one by one and saves them to a list, thus obtaining an abstraction of the data block. However, since the data block is tree-like, two methods are provided here to save its structure. One is to directly save the child nodes and sibling nodes as a special type of attribute to the current node. The other is to identify them through common methods such as indentation and inclusion.

[0114] The identifier format for a data block template can be the identifier in the first type of file, that is, a data block is identified by its service ID, sub-service ID (if included), and data ID (if included).

[0115] The file format can be XML, JSON, or a custom binary format, and it can also be managed using a database.

[0116] The third type of file is the execution control file. The first and second types of files mentioned above are template files and do not contain specific values. The execution control file, however, focuses on containing specific execution data; therefore, its emphasis is on numerical values ​​and execution conditions. Thus, this file does not contain a structure, but only the identifiers from the first and second types of files mentioned above, matching the message itself, and the execution control required for execution, as well as the expected conditions.

[0117] The third type of file involves distribution and is generally related to specific operational business. It may contain multiple files of the same type. It is recommended to save the files in XML, JSON, or a custom binary format.

[0118] Of the three types of files mentioned above, the first and second types are related to specific vehicle models and can be saved together and built into the host computer software to serve as templates. The third type of file is different for each user; it is configured with execution conditions and steps based on specific business needs. It can also be configured by a group of technicians and then distributed to operators.

[0119] The loading and reuse process includes the reverse process of the previous process (the process of generating the first type of file, the second type of file, and the third type of file mentioned above). The execution process is achieved by reading the files from the previous step. The second type of file depends on the first type of file, and the third type of file depends on the first type of file and the second type of file. Therefore, the loading order must be the first type of file, the second type of file, and the third type of file.

[0120] By parsing the properties configured within each file, services, data blocks, and execution control are loaded into the executable program. The steps for converting service templates and data block templates are generally fixed add-ins, built into the host computer software package and loaded by default. The steps for converting execution control files can be manually loaded and used within the application via the file interface, depending on the specific business operations required.

[0121] In this embodiment, the data block abstraction step further includes:

[0122] Based on data block abstraction, the process includes steps for setting major categories, structural abstraction, position and length processing, meaning item processing, and abstract node definition.

[0123] The steps for setting up major categories include abstracting data blocks into ordinary data blocks, DID data blocks, and RID data blocks;

[0124] Among them, data blocks are used to represent business meaning items;

[0125] It also includes that a data block corresponds to one or more meaning items.

[0126] Specifically, in one embodiment, public data is abstracted into categories. Data blocks can be abstracted into three categories: ordinary data blocks, DID data blocks, and RID data blocks. Ordinary data blocks are collections of business items, DID data blocks correspond to services 0x22 / 0x2E, and RID data blocks correspond to services 0x31. DID and RID data blocks are marked as special because these two services require data IDs, and different data IDs have different lengths and business meanings. Logically, one data ID corresponds to one major business item, which contains one or more minor business items. Different DIDs have different execution permissions. Different RIDs also have different execution permissions under different sub-functions, hence the three categories. The data block is the foundation; DID information additionally includes the data ID, execution permissions, major business item name (in Chinese and English), and major business item remarks. RID information further includes a sub-function ID, i.e., it includes the data ID, sub-function ID, execution permissions, major business item name (in Chinese and English), and major business item remarks.

[0127] In this embodiment, the structural abstraction steps include:

[0128] The organization of each meaning item is abstracted into a tree-like node architecture;

[0129] The organization of each meaningful item is abstracted into a tree-like node architecture, which does not extend the tree-like nodes according to the data type of the node, such as numeric, structure, string, array or enumeration.

[0130] Based on the structure of abstracting the organization of each meaning item into a tree-like node, the meaning items are visited.

[0131] Specifically, in one particular embodiment, an abstraction of the structure is disclosed. Data blocks are used to represent specific business meaning items, typically corresponding to one or more meaning items, wherein nodes may mean numerical values ​​(of different lengths), strings, arrays, structures, enumerations, etc.

[0132] For a structure, it may contain one or more of the aforementioned meaning items. Therefore, the organization of each meaning item can be abstracted as a tree-like node structure similar to folders and files. When the meaning item is a structure, it is similar to a folder, and it can contain files and folders. When the meaning item is a string, array, enumeration, etc., it is similar to a file, and it generally does not have any nodes inside. Note that there is a special case here, namely, an array of structures. In this case, the array is generally expanded first, that is, N structures are listed side by side, and then the structures are expanded.

[0133] Additionally, in certain IDs and services, the concept of circular references may be encountered. At the end, there will be a special node that can continuously loop until the end of the data block. In this case, the loop end node needs to be weakly pointed to the head of the referenced node.

[0134] For the above situation, child nodes and sibling nodes can be defined for any node. Starting from the first meaning item, for each meaning item, its child nodes are configured according to whether it can be expanded, and its sibling nodes are configured according to whether it has a next node. After recursively configuring all nodes, all meaning items are connected into a tree structure. For several blocks, only the root node needs to be obtained, and its child and sibling nodes can be accessed through depth-first or breadth-first traversal to access all meaning items.

[0135] In this embodiment, the position and length processing steps further include:

[0136] Based on the tree-like structure that abstracts the organization of each meaning item, the meaning items of string, numeric and enumeration data types have a fixed word length; among them, the string meaning item determines the number of bytes it occupies based on the preset maximum byte length.

[0137] Structured data types also include union meaning items;

[0138] The meaning of the consortium includes multiple meanings;

[0139] The meaning of a concatenation is that it contains multiple meanings, and each meaning is either concatenated or occupies a single byte.

[0140] Specifically, in one embodiment, the byte occupation strategy of the public node is disclosed. Generally, the length occupied by a node is a fixed number of bytes. For example, numeric and enumeration meaning items usually occupy 1, 2, 4, or 8 bytes. String meaning items usually determine their byte occupation based on their defined maximum length. The parent node of a structural meaning item is only used to wrap the name and does not occupy bytes. The length occupied by the entire structure is usually formed by sequentially adding up all its child nodes and the child nodes of its child nodes.

[0141] In some special cases, nodes cannot be treated like regular nodes. For example, unions can be considered a special type of structure. A union may have one or more semantic items occupying the same message position, but expressing different meanings or achieving different display effects depending on the interpretation. Similarly, nodes with numerical meanings may not necessarily occupy an entire byte. A node with a particular numerical meaning might only occupy the first n bits of a byte, and several such numerical meaning items might be combined, occupying different bits of the same byte.

[0142] Additionally, for the DTC service, its messages may contain a portion of the data ID used by 0x22 0x2E, and the specific parsing length is determined by the length of a certain data ID in the definition.

[0143] Therefore, given the aforementioned structural abstract model, a specific message can be segmented from beginning to end into one or more bytes, corresponding to all the meaning items, or the values ​​of all the meaning items are known and concatenated according to rules, thus serializing it into a complete message.

[0144] In this embodiment, the steps for processing the meaning item further include:

[0145] Since the nodes are numerical data types, physical quantity units are added after calculation according to preset rules to express the meaning of the data.

[0146] Specifically, in one embodiment, the processing of meaning items is disclosed. For enumeration nodes, an additional mapping list is needed to store their corresponding enumeration meanings. This includes a special enumeration type that only contains True or False and occupies 1 byte. For this commonly used special enumeration, a separate type—Boolean—can be assigned.

[0147] For numeric nodes, besides length, we often encounter cases such as signed numbers, unsigned numbers, and floating-point numbers. Floating-point numbers also involve different parsing standards, thus requiring different type markings. Some applications of numeric nodes don't use the original meaning of the byte-to-value pair. Instead, they perform calculations according to certain rules, then add physical units to arrive at the final meaning. These calculations typically include multiplication, division, addition, and subtraction. For multiplication and division, the result is a factor; for addition and subtraction, it's an offset; and for physical units, it's a separate string "Unit" used for concatenation after calculation.

[0148] Furthermore, for the case where multiple values ​​share the same byte location but different bit positions, a mask and a shift operator are used together to determine the meaning. Therefore, for a numeric type's meaning item, in addition to the basic type, the aforementioned additional descriptions also need to be defined.

[0149] There is another special type of numerical meaning item, Byte. For this type of business meaning item, the original hexadecimal code stream of the message is also meaningful, so the message segment containing the meaning item is directly presented in hexadecimal value format.

[0150] For character and string types, in addition to the basic type and length (or maximum length), you also need to define their encoding type. The default is ASCII encoding. For example, for Chinese characters, the commonly used encodings are GB2312 and UTF-8. For the same message segment, using an incorrect encoding method may result in different Chinese characters or even garbled characters.

[0151] DTC, or fault code storage related services 0x19 and 0x14. When the system detects an error or fault, it stores the corresponding numerical fault code. This numerical value can be used as a fault code, which is the DTC. A DTC occupies 3 bytes and is converted and parsed according to certain rules. The correspondence between the fault code and the 5-bit standard fault code is as follows: DTCHighByte and DTCMiddleByte represent the fault code, corresponding to the 5-bit standard fault code (e.g., the first digit is a letter, and the last four are numbers). For example, in the fault code "U005588" for a customer's BUSOFF, "U0055" represents "U0055". The last "16" is the content of DTCLowByte. The positional correspondence between the fault code and the 5-bit standard fault code is as follows: Figure 10 The fault code definitions shown are as follows: Figure 11 The fault code definition is shown.

[0152] In this embodiment, the step of defining an abstract node further includes:

[0153] Nodes include basic nodes and special nodes;

[0154] The attributes of a basic node include name, description, basic type, extended type, child nodes, sibling nodes, array length, and loop start node;

[0155] The attributes of special nodes include attributes defined separately in addition to those based on those of basic nodes;

[0156] Based on separately defined attributes, the enumeration data type node includes, ensuring the correspondence between enumeration values ​​and enumeration strings;

[0157] Numeric data type nodes include ensuring that the Factor property is 1 by default, the Offset property is 0 by default, the Unit property is empty by default, the Mask property is 0xffffffff by default, and the shift property is 0 by default.

[0158] The character data type node must include the encoding method, which defaults to ASCII.

[0159] Specifically, in one particular embodiment, the definition of an abstract byte is disclosed. Based on the rules formed above, any node can be abstracted as follows:

[0160] All nodes are basic nodes. For nodes that require additional attributes, they should be defined as specific nodes that are extensions of the basic nodes.

[0161] A basic node must include the following attributes: name, description, basic type, extended type, child nodes, sibling nodes, array length, and loop start node.

[0162] The following are the additional attributes that need to be defined separately for various special nodes:

[0163] Enumeration nodes: must include the correspondence between enumeration values ​​and enumeration strings.

[0164] Numeric nodes: must include the Factor property (default 1), Offset property (default 0), Unit (default empty), Mask property (default 0xffffffff), and shift property (default 0).

[0165] Character node: must include the encoding method, the default is ASCII.

[0166] All other nodes can be classified as basic nodes.

[0167] The basic and extended types of a basic node have the following meanings: the basic type defines the basic length template of the data, while the extended type defines the parsing length related to the parsing of the data.

[0168] Basic data types must include: Boolean, Character, 8-bit enumeration, 16-bit enumeration, 32-bit enumeration, 8-bit signed number, 8-bit unsigned number, 16-bit signed number, 16-bit unsigned number, 32-bit signed number, 32-bit unsigned number, 64-bit signed number, 64-bit unsigned number, Floating-point 1, Floating-point 2, Double-precision Floating-point 1, Double-precision Floating-point 2, Structure, Union, DTC

[0169] Extended type definitions must include: basic types, bit field types, and array types.

[0170] By combining basic and extended types in pairs, we can obtain abstract node definitions that cover the meaning items required by the business, such as 16-bit signed values, arrays of structures, bit fields of 8-bit enumerations, etc.

[0171] Figure 20 This is a structural diagram of a UDS diagnostic protocol parsing and execution system provided by one or more embodiments of the present invention.

[0172] like Figure 20 The UDS diagnostic protocol parsing and execution system shown includes:

[0173] The module includes modules for UDS service abstraction, UDS service message encoding and decoding, data block abstraction, data block serialization and parsing, result determination, execution control, interface configuration, hard storage, and loading and reuse.

[0174] The UDS service abstraction module is used to abstract UDS services into SID, sub-functions, ID, and data blocks;

[0175] The module for UDS service message encoding and decoding is used to abstract the corresponding UDS service into SID, sub-function, ID and data block, and to set the UDS service message parsing process and UDS service message encoding process.

[0176] The data block abstraction module is used to obtain the template of the corresponding data block based on the data block abstraction; the template of the corresponding data block includes the correspondence between the data in the data block and the meaning items of the template;

[0177] The data block serialization and data block parsing module is used to arrange the meaning item data into a message according to the template and to restore the message into the corresponding meaning item data;

[0178] The result determination module is used to set preset key business meaning item determination conditions; and to determine the result status after service execution based on the preset key business meaning item determination conditions.

[0179] The execution control module is used to set the execution parameters required by the service and control the execution of the service based on the execution parameters;

[0180] The interface configuration module is used to set or configure options and operation windows for services, data blocks, and execution control through the interface;

[0181] The solidified and stored module is used to solidify reproducible data and processes into a loadable template for re-parse and execute the UDS diagnostic protocol;

[0182] Loading reusable modules is used to load loadable templates and reproduce reproducible data and processes; loading loadable templates and reproducing reproducible data and processes includes verifying the validity of the template.

[0183] It is worth noting that although this system / device only discloses the modules for UDS service abstraction, UDS service message encoding and decoding, data block abstraction, data block serialization and parsing, result determination, execution control, interface configuration, hard storage, and loading and reuse, this does not mean that this device is limited to the above-mentioned basic functional modules. On the contrary, what this invention intends to express is that, based on the above-mentioned basic functional modules, those skilled in the art can arbitrarily add one or more functional modules in combination with existing technology to form an infinite number of embodiments or technical solutions. That is to say, this system is open rather than closed. The fact that this embodiment only discloses a few basic functional modules does not mean that the scope of protection of the claims of this invention is limited to the above-disclosed basic functional modules.

[0184] In one specific embodiment, a method is disclosed. Figure 16 The FDA0 business example shown illustrates the methods for abstraction, data serialization, and message parsing.

[0185] Service Abstraction:

[0186] First, the host computer software needs to support the 0x22 service. The 0x22 service is defined as having no sub-functions, a data ID, and data blocks.

[0187] Based on this, define a data block template with data ID 0xFDA0, a length of 10, and a name of USB_info (Chinese name: USB device information).

[0188] Data block abstraction:

[0189] After the data block template is abstracted, as follows: Figure 17 The FDA0 meaning item abstract example shows the logic. It contains 8 nodes. The root node is USB30_Info, of type STRUCT, with an extended type of BASIC. It contains 3 child nodes: vendor_id (type BYTE, extended type BASIC), product_id (type BYTE, extended type ARRAY, length 2), and speed(CMUSBSpeedType) (type ENUM8, extended type BASIC). The root node USB30_Info also has a sibling node USB20_Info, which also contains 3 child nodes of the same type. The traversal order is as described above.

[0190] Message serialization:

[0191] like Figure 18 The example value for the FDA0 meaning field shown illustrates the process of converting a business meaning field into a message. After loading the information from the template, the business can be processed.

[0192] Because of the 0x22 service, the UDS service portion of the message begins with 0x22, does not contain sub-functions, is skipped, and has a data ID of 0xFDA0. Therefore, FD A0 is appended to the message, resulting in the following message:

[0193] 22 FD A0;

[0194] Traversing the business meaning item tree of the data block, we obtain: the root node USB30_Info, type STRUCT, does not occupy data bits; continuing to traverse its child node verndor_id, type BYTE, extended type BASIC, data is 0x01, therefore 0x01 is appended to the message.

[0195] 22 FD A0 01;

[0196] The Product_id node is of type BYTE, with an extended type of ARRAY, a length of 2, and data of 0x010x1. Therefore, 01 01 is appended to the message.

[0197] 22 FD A0 01 01 01;

[0198] The Speed ​​node is of type ENUM8, the extended type is BASIC, and the data is 0x03, so 03 is appended to the message;

[0199] 22 FD A0 01 01 01 03;

[0200] After traversing all child nodes of USB30_Info, continue traversing the sibling node of USB30_Info, USB20_Info, which is of type STRUCT and does not occupy data bits. Continue traversing its child nodes, the process is the same as above and will not be repeated. The final message is 22 FD A001 01 01 03 01 02 02 02.

[0201] Message parsing:

[0202] Given the following message and the abstract data mentioned above, the message parsing process is shown below.

[0203] 22 FD A0 01 01 01 03 01 02 02 02;

[0204] First, identify the service ID, 0x22, which does not contain sub-services but includes the data ID. Therefore, parse the two-digit data ID, 0xFDA0. The parsed packet location is as follows:

[0205] 22 FD A0 01 01 01 03 01 02 02 02;

[0206] Traverse the data block abstract tree, parsing the messages sequentially. The root node, USB30_Info, is of type STRUCT and does not occupy data bits, so continue traversing its child nodes. The verndor_id is of type BYTE, with the extended type BASIC, therefore a 1-bit message is parsed: vendor_id = 0x01;

[0207] 22 FD A0 01 01 01 03 01 02 02 02;

[0208] The Product_id node is of type BYTE, with an extended type of ARRAY, a length of 2, and parses 2 bits: product_id = 0x0101;

[0209] 22 FD A0 01 01 01 03 01 02 02 02;

[0210] The Speed ​​node is of type ENUM8, with an extended type of BASIC. It parses 1 bit, 03, and by referring to the enumeration table, we can obtain: speed = 0x3: Super speed;

[0211] After traversing all child nodes of USB30_Info, continue traversing the sibling node of USB30_Info, USB20_Info, which is of type STRUCT and does not occupy data bits. Continue traversing its child nodes, the process is the same as above and will not be repeated. The final parsed meaning item is:

[0212] vendor_id = 0x01;

[0213] product_id = 0x0202;

[0214] speed = 0x2: High speed.

[0215] In another specific embodiment, the background technology of this application is disclosed to explain the above technical solution.

[0216] The UDS (Unified Diagnostic Services) protocol is a diagnostic communication protocol used in the automotive electronic control unit (ECU) environment. To date, this protocol is used in almost all new ECUs manufactured by Tier 1 OEM suppliers. These ECUs control various vehicle functions, including electronic fuel injection (EFI), engine control systems, transmissions, anti-lock braking systems (ABS), door locks, and brakes. Most new cars on the market today have diagnostic interfaces for external diagnostics, allowing a computer or diagnostic tool (known in the industry as a tester) to connect to the vehicle's bus system. Therefore, messages defined in UDS can be sent to controllers (known in the industry as ECUs) that support UDS services. This allows access to the fault memory of each control unit or updates to the ECU's program with new firmware. In addition, UDS is used to write information (such as VIN codes) into various automotive components during off-line testing. These are the core functions of UDS. Therefore, UDS services play a crucial role in vehicle development, testing, manufacturing, repair, maintenance, and upgrade / flashing.

[0217] like Figure 1 The diagnostic request message format shown is used by UDS Diagnostics to connect to the vehicle via CAN bus or Ethernet and to provide different diagnostic services by sending and receiving messages in specific formats.

[0218] like Figure 2 The diagnostic message example shown is as follows: Figure 3 The diagnostic service list shown is typically complex and difficult to read intuitively. Users often need to use methods such as looking up tables or extracting message content to understand the message.

[0219] Among them, services such as 0x22 ReadDataByIdentifier, 0x2E WriteDataByIdentifier, 0x31 RoutineControl, and 0x19 ReadDTCInformation can all contain message formats with IDs and custom structures, and may include multiple IDs concatenated, making message parsing and reading more difficult. Typically, vehicle diagnostic services need to implement dozens or even hundreds of IDs, and each ID's message may contain multiple fields of different lengths and parsing methods. To fully understand the meaning of these fields, it is usually necessary to use the message, combined with an ID definition table, to perform lookups, segmentation, calculations, and other multi-step operations to fully understand the specific business fields and their values ​​or meanings expressed by a particular service + ID combination. For example, the 0x22 server request message format, see... Figure 4 The 0x22 service request message format is shown; for example, the 0x31 server request message format is shown in [reference needed]. Figure 5 The 0x31 service request message format is shown; for example, the 0x22 service ID reply message, see Figure 1 The 0x22 service message and its meaning are shown in the example; for example, 0x19 serves a certain reply message, see Figure 7 The 0x19 service message and its meaning are shown in the example.

[0220] As can be seen from the above, directly reading UDS messages is time-consuming, laborious, and inefficient. Furthermore, for commonly used services such as 0x22 and 0x31, messages with custom IDs require different combinations of the 0x10 DiagnosticSessionControl and 0x27 SecurityAccess services before entering different sessions and performing different levels of authentication, making the process quite complex.

[0221] The current situation is that most existing tools can send / receive corresponding messages starting from the services defined by the protocol. However, this operation generally requires the participation of technical personnel to edit, send, decode, and read the messages. This process is technically demanding, inefficient, and prone to errors.

[0222] Furthermore, the prerequisites for services such as 0x22 and 0x31 under different IDs require technical personnel to use auxiliary means such as table lookup to operate normally. This requires high time and manpower costs for self-testing during the R&D and production stages, as well as after-sales maintenance.

[0223] In practical business applications, such as software flashing, a series of diagnostic operations are often required in a specific order to achieve business objectives. Combining the aforementioned difficulties, the operation is extremely challenging, often resulting in a low success rate. In some cases, errors or omissions in critical steps may cause varying degrees of damage to the vehicle's hardware and software, posing a high risk.

[0224] Some software uses hard-coded parsing of fixed parts of the UDS service messages. This method can parse the basic service messages, but it cannot effectively solve the message content of 0x22, 0x2E, and 0x31 services under different IDs. It still cannot efficiently handle the different message meanings of hundreds of IDs.

[0225] Some software also hard-codes the message content with different IDs to achieve message parsing. However, this method incurs significant manpower costs for hard-coding ID message parsing and lacks flexibility. If the ID changes or needs to be matched to different vehicle models, it will lead to multiple versions of maintenance and require the involvement of upper-level software developers, making maintenance difficult. Furthermore, for the 0x19 service instructions, which attach an ID, this implementation also lacks parsing capabilities. Moreover, throughout the vehicle's lifecycle, upper-level software developers and UDS service business developers often belong to different development teams. This hard-coding method will create coupling between the two development teams, forcing them to develop sequentially and reducing the overall efficiency of vehicle development, production, and maintenance.

[0226] This application discloses a series of coherent and complementary strategies, such as: a method for abstracting related UDS services into service IDs, sub-services, data IDs, and data blocks in the UDS service abstraction method; a method for pre-setting service IDs, sub-services, data IDs, and data blocks supported by vehicle models in the host computer software; a method for mapping UDS messages to UDS service items; a method for configuring service IDs, sub-services, data IDs, and data blocks through an interface; and a method for storing the combination in a file as a configuration file and loading it as a default item.

[0227] For example, data block abstraction methods include: methods for combining sets of meaning items into a tree structure in the form of nodes; connecting nodes into an abstract tree structure by defining their child and sibling nodes; performing depth-first and breadth-first traversals of the entire tree through the root node; abstracting meaning items into combinations of basic and extended types to cover all business meanings; defining the basic types that meaning items can contain; determining the message length occupied by meaning items through different basic and extended types; determining the mutual conversion between meaning items and data blocks through different basic and extended types; providing different judgment methods through combinations of basic and extended types of meaning items to achieve preset expected values ​​and determine the results during execution; configuring the relationships between data block nodes to form a tree structure and node attributes through the interface; and saving the data block abstract structure node relationships and node attributes in a file as a configuration file and loading it as a default item.

[0228] For example, execution control parameters related to the execution process based on execution conditions; retry conditions based on failure results; control options for subsequent execution after execution failure; and methods for saving execution conditions as files for repeated distribution.

[0229] In another specific embodiment, a method for parsing and executing a UDS diagnostic protocol based on a user-defined interface is disclosed, including:

[0230] Service abstraction steps: Abstract the UDS service into a combination of service ID (SID), sub-function, data ID, and data block; generate a service template based on the combination of service ID (SID), sub-function, data ID, and data block through the interface configuration; the service template includes a list of services supported by the vehicle model and their relationships.

[0231] Data block abstraction steps: Abstract the data block into a tree-like node structure; where nodes are connected through child nodes and sibling nodes, supporting the combined definition of basic types such as numbers, strings, and enumerations with extended types such as bit fields and arrays, forming a data block template;

[0232] Dynamic loading steps: Service templates and data block templates are dynamically loaded through configuration files; the configuration files include a service list in XML / JSON format, data block structure, and execution control parameters;

[0233] Message encoding and decoding steps: Based on the service template and data block template, the message and business meaning items are converted bidirectionally by traversing the tree nodes through depth. The conversion includes factor calculation, offset processing and encoding parsing.

[0234] Execution control steps: Set parameters for execution wait time, number of loops, and failure retry strategy, and generate branch execution paths based on the judgment conditions (numerical comparison, string matching, etc.) of business meaning items.

[0235] Based on the above specific embodiments, a system for implementing a UDS diagnostic protocol parsing and execution method based on a user interface configuration is disclosed, comprising:

[0236] Interface configuration module: Provides a visual configuration interface for service ID, sub-function, and data ID, and supports the creation, editing, and attribute setting of tree nodes;

[0237] Template Management Module: Stores service templates and data block templates corresponding to vehicle models, and supports importing / exporting XML / JSON format files;

[0238] Encoding / decoding engine: Based on templates, it parses messages into a business meaning item tree, or generates corresponding messages based on meaning items, including factor / offset calculation and bit field processing;

[0239] Execution control module: Sets execution parameters and judgment conditions, and triggers retry mechanisms or branch processes based on service execution results;

[0240] Communication interface module: Enables message sending and receiving with the vehicle ECU via CAN bus or Ethernet.

[0241] Figure 21This is a block diagram of an electronic device structure for a UDS diagnostic protocol parsing and execution method provided in one or more embodiments of the present invention.

[0242] like Figure 21 As shown, this application provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0243] The memory stores a computer program, which, when executed by the processor, causes the processor to perform the steps of a UDS diagnostic protocol parsing and execution method.

[0244] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of a UDS diagnostic protocol parsing and execution method.

[0245] This application also provides a vehicle diagnostic platform, including:

[0246] Electronic equipment used to implement the steps of the UDS diagnostic protocol parsing and execution method;

[0247] The processor runs a program, and when the program runs, it executes the steps of the UDS diagnostic protocol parsing and execution method based on the data output from the electronic device.

[0248] Storage medium used to store programs, which, when running, execute the UDS diagnostic protocol parsing and execution method steps on data output from electronic devices.

[0249] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0250] The electronic device comprises a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on the operating system. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory. The operating system can be any one or more computer operating systems that control the electronic device through processes, such as Linux, Unix, Android, iOS, or Windows. Furthermore, in this embodiment of the invention, the electronic device can be a smartphone, tablet computer, or other handheld device, or a desktop computer, portable computer, or other electronic device; there is no particular limitation in this embodiment.

[0251] In this embodiment of the invention, the executing entity for electronic device control can be an electronic device itself, or a functional module within an electronic device capable of calling and executing a program. The electronic device can obtain the firmware corresponding to the storage medium. This firmware is provided by the supplier, and different storage media may have the same or different firmware; no limitation is made here. After obtaining the firmware corresponding to the storage medium, the electronic device can write this firmware into the storage medium; specifically, it burns the firmware corresponding to the storage medium into the storage medium. The process of burning the firmware into the storage medium can be implemented using existing technology, and will not be elaborated upon in this embodiment of the invention.

[0252] Electronic devices can also obtain reset commands corresponding to the storage media. The reset commands corresponding to the storage media are provided by the supplier. The reset commands corresponding to different storage media can be the same or different, and no restrictions are imposed here.

[0253] At this time, the storage medium of the electronic device is a storage medium on which the corresponding firmware has been written. The electronic device can respond to the reset command corresponding to the storage medium on which the corresponding firmware has been written, thereby resetting the storage medium on which the corresponding firmware has been written according to the reset command. The process of resetting the storage medium according to the reset command can be implemented by existing technology and will not be described in detail in this embodiment of the invention.

[0254] For ease of description, the above devices are described separately by function as various units and modules. Of course, in implementing this application, the functions of each unit and module can be implemented in one or more software and / or hardware.

[0255] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the meaning consistent with their meaning in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined.

[0256] For the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0257] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0258] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention 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 or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for parsing and executing a UDS diagnostic protocol, characterized in that, The UDS diagnostic protocol parsing and execution method includes: The steps for UDS service abstraction, UDS service message encoding and decoding, data block abstraction, dynamic loading, data block serialization and parsing, result determination, execution control, interface configuration, hardening and saving, and loading and reuse. The steps of UDS service abstraction include generating a service template through interface configuration based on a combination of parameters including service ID, sub-function, data ID, and data block; wherein, the service template includes a list of services supported by the vehicle model and their associated relationships; The steps for encoding and decoding UDS service messages include: abstracting the corresponding UDS service into SID, sub-function, ID, and data block; setting up the UDS service message parsing process and the UDS service message encoding process. The steps of data block abstraction include: abstracting the data block into a tree-like node structure to form a data block template; the data block template includes the correspondence between the data in the data block and the meaning items of the template. The dynamic loading process includes dynamically loading service templates and data block templates through a configuration file; the configuration file includes a service list in XML / JSON format, a data block structure, and execution control parameters. The steps of data block serialization and data block parsing include arranging the data of the meaning items into a message according to the template and restoring the message into the data of the corresponding meaning items; The steps for determining the result include: setting preset judgment conditions for key business meaning items; and determining the result status after service execution based on the preset judgment conditions for key business meaning items. The steps for execution control include setting the execution parameters required by the service and controlling the execution of the service based on the execution parameters; The steps for configuring the interface include setting or configuring relevant options and operation windows for services, data blocks, and execution control through the interface; The process of solidifying and saving includes solidifying reproducible data and processes into a loadable template for re-parse and execute of the UDS diagnostic protocol; The loading reuse steps include loading a loadable template and reproducing reproducible data and processes; loading a loadable template and reproducing reproducible data and processes includes verifying the validity of the template.

2. The UDS diagnostic protocol parsing and execution method according to claim 1, characterized in that, The data block abstraction process also includes: Based on data block abstraction, the process includes steps for setting major categories, structural abstraction, position and length processing, meaning item processing, and abstract node definition. The steps for setting up major categories include abstracting data blocks into ordinary data blocks, DID data blocks, and RID data blocks; Among them, data blocks are used to represent business meaning items; It also includes that a data block corresponds to one or more meaning items.

3. The UDS diagnostic protocol parsing and execution method according to claim 2, characterized in that, The steps of the structural abstraction include: The organization of each meaning item is abstracted into a tree-like node architecture; The organization of each meaningful item is abstracted into a tree-like node architecture, which does not extend the tree-like nodes according to the data type of the node, such as numeric, structure, string, array or enumeration. Based on the structure of abstracting the organization of each meaning item into a tree-like node, the meaning items are visited.

4. The UDS diagnostic protocol parsing and execution method according to claim 2, characterized in that, The position and length processing steps also include: Based on the structure of abstracting the organization of each meaning item into a tree-like node, the meaning items of string, numeric and enumeration data types are preset with a fixed word length; Structured data types also include union meaning items; The meaning of the consortium includes multiple meanings; The meaning of a concatenation is that it contains multiple meanings, and each meaning is either concatenated or occupies a single byte.

5. The UDS diagnostic protocol parsing and execution method according to claim 2, characterized in that, The steps for processing the meaning item also include: Based on the fact that nodes are numerical data types, physical quantity units are added after calculation according to preset rules to express the meaning of the data.

6. The UDS diagnostic protocol parsing and execution method according to claim 2, characterized in that, The steps for defining the abstract node also include: Nodes include basic nodes and special nodes; The attributes of a basic node include name, description, basic type, extended type, child nodes, sibling nodes, array length, and loop start node; The attributes of special nodes include attributes defined separately in addition to those based on the attributes of basic nodes; Based on separately defined attributes, the enumeration data type node includes, ensuring the correspondence between enumeration values ​​and enumeration strings; Numeric data type nodes include ensuring that the Factor property defaults to 1, the Offset property defaults to 0, the Unit property defaults to empty, the Mask property defaults to 0xffffffff, and the shift property defaults to 0. The character data type node must include the encoding method, which defaults to ASCII.

7. A UDS diagnostic protocol parsing and execution system, characterized in that, The UDS diagnostic protocol parsing and execution system includes: The module includes modules for UDS service abstraction, UDS service message encoding and decoding, data block abstraction, data block serialization and parsing, result determination, execution control, interface configuration, hard storage, and loading and reuse. The UDS service abstraction module is used to generate service templates through interface configuration based on a combination of parameters including service ID, sub-function, data ID, and data block; the service template includes a list of services supported by the vehicle model and their relationships. The module for UDS service message encoding and decoding is used to abstract the corresponding UDS service into SID, sub-function, ID and data block, and to set the UDS service message parsing process and UDS service message encoding process. The data block abstraction module is used to abstract data blocks into a tree-like node structure to form a data block template; the data block template includes a correspondence between the data in the data block and the meaning items of the template; The dynamically loaded module is used to dynamically load service templates and data block templates through a configuration file; the configuration file includes a service list in XML / JSON format, a data block structure, and execution control parameters; The data block serialization and data block parsing module is used to arrange the meaning item data into a message according to the template and to restore the message into the corresponding meaning item data; The result determination module is used to set preset key business meaning item determination conditions; and to determine the result status after service execution based on the preset key business meaning item determination conditions. The execution control module is used to set the execution parameters required by the service and control the execution of the service based on the execution parameters; The interface configuration module is used to set or configure options and operation windows for services, data blocks, and execution control through the interface; The solidified and stored module is used to solidify reproducible data and processes into a loadable template for re-parse and execute the UDS diagnostic protocol; Loading reusable modules is used to load loadable templates and reproduce reproducible data and processes; loading loadable templates and reproducing reproducible data and processes includes verifying the validity of the template.

8. An electronic device, characterized in that, include: The processor, communication interface, memory, and communication bus are connected, with the processor, communication interface, and memory communicating with each other via the communication bus. The memory stores a computer program that, when executed by a processor, causes the processor to perform the steps of the UDS diagnostic protocol parsing and execution method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The device stores a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of the UDS diagnostic protocol parsing and execution method as described in any one of claims 1 to 6.

10. A vehicle diagnostic platform, characterized in that, include: An electronic device for implementing the steps of the UDS diagnostic protocol parsing and execution method as described in any one of claims 1 to 6; The processor runs a program that, when the program is running, executes the steps of the UDS diagnostic protocol parsing and execution method as described in any one of claims 1 to 6 from data output by the electronic device. A storage medium for storing a program that, when running, performs the steps of the UDS diagnostic protocol parsing and execution method as described in any one of claims 1 to 6 on data output from an electronic device.

Images