CN117271330A - Function verification method and system for ODX interpreter - Google Patents

Function verification method and system for ODX interpreter Download PDF

Info

Publication number
CN117271330A
CN117271330A CN202311213076.8A CN202311213076A CN117271330A CN 117271330 A CN117271330 A CN 117271330A CN 202311213076 A CN202311213076 A CN 202311213076A CN 117271330 A CN117271330 A CN 117271330A
Authority
CN
China
Prior art keywords
odx
interpreter
result
test
data file
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202311213076.8A
Other languages
Chinese (zh)
Other versions
CN117271330B (en
Inventor
赵文旋
翟肖
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Magna Wuhan Technology Co ltd
Original Assignee
Magna Wuhan Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Magna Wuhan Technology Co ltd filed Critical Magna Wuhan Technology Co ltd
Priority to CN202311213076.8A priority Critical patent/CN117271330B/en
Publication of CN117271330A publication Critical patent/CN117271330A/en
Application granted granted Critical
Publication of CN117271330B publication Critical patent/CN117271330B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3692—Test management for test results analysis

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

The application relates to the technical field of automobile diagnosis, in particular to a function verification method and system for an ODX interpreter, wherein the method comprises the following steps: firstly, an ODX diagnosis data file is obtained, and according to the ODX protocol standard definition, a test expected result is extracted from the obtained ODX diagnosis data file; then, taking the ODX diagnosis data file as input, executing an ODX interpreter to obtain an execution result; and finally, comparing the expected test result with the execution result to obtain a verification result of the ODX interpreter. The application provides the function verification method for the ODX interpreter based on the ODX protocol standard and the application of the ODX protocol standard in the automobile diagnosis system, and the function verification method is used for verifying the function correctness and completeness of the ODX interpreter, so that the stability of the ODX interpreter is improved, the development efficiency of the automobile diagnosis system is further improved, and the comprehensive development cost is reduced.

Description

Function verification method and system for ODX interpreter
Technical Field
The application relates to the technical field of automobile diagnosis, in particular to a function verification method and system for an ODX interpreter.
Background
In the field of automobile diagnostics, ODX (Open Diagnostic Data Exchange, open diagnostic data exchange format) is an ISO (International Organization for Standardization ) standard protocol for describing diagnostic data of an automobile ECU (Electronic Control Unit ), and is widely used in the field of automobile diagnostics.
The ODX is mainly used for describing communication parameters, diagnosis data, programming data, vehicle type information and the like related to ECU diagnosis, and is mainly described in an XML (Extensible Markup Language ) format, one ODX object is described through one XML node, and a series of ODX objects form one XML file, which is called an ODX diagnosis data file. At present, for an automobile diagnosis system supporting an ODX protocol, an ODX diagnosis data file needs to be parsed, that is, an ODX parser is implemented, firstly, contents of communication parameters, diagnosis data, programming data, vehicle type information and the like related to automobile ECU diagnosis need to be extracted from the ODX diagnosis data file, and then, an actual ECU diagnosis function is completed according to the extracted contents of the ODX diagnosis data, however, the following error scenarios may occur in the process: (1) The ODX interpreter function is incorrectly realized, so that the extracted automobile ECU diagnosis data is wrong, and the diagnosis operation of the automobile ECU is failed; (2) The ODX interpreter function is not fully realized, and because of differences in diagnostic data files of the respective vehicle ECUs, it may happen that the ODX interpreter can complete the diagnostic test of ecu_1, but an error occurs when the diagnostic test is performed on ecu_2.
In the above-mentioned scheme, when the above-mentioned error scenario occurs, repeated analysis and confirmation of the cause of the ODX interpreter extracting the diagnostic data abnormality are generally required, which may reduce the development efficiency of the vehicle diagnostic system and increase the comprehensive development cost.
Disclosure of Invention
In view of this, the embodiment of the application provides a method and a system for verifying functions of an ODX interpreter, which can verify the correctness and completeness of the functions of the ODX interpreter, so as to improve the stability of the ODX interpreter, further improve the development efficiency of a vehicle diagnostic system, and reduce the comprehensive development cost.
In a first aspect, the present application provides a method for functional verification of an ODX interpreter, the method comprising:
obtaining an ODX diagnosis data file;
extracting a test expected result from the ODX diagnosis data file according to an ODX protocol standard definition;
executing an ODX interpreter according to the ODX diagnosis data file and outputting an execution result;
and comparing the expected test result with the execution result, and outputting a verification result of the ODX interpreter.
According to the technical means, the application provides a function verification method for the ODX interpreter based on the ODX protocol standard and the application of the ODX protocol standard in an automobile diagnosis system, and the function verification method is used for verifying the correctness and completeness of the ODX interpreter, so that the stability of the ODX interpreter is improved, the development efficiency of the automobile diagnosis system is further improved, and the comprehensive development cost is reduced.
With reference to the first aspect, in an implementation manner, the ODX diagnostic data file includes diagnostic data of an electronic control unit of a vehicle model developed by a vehicle manufacturer, and a content format of the diagnostic data of the electronic control unit of the vehicle accords with an ODX protocol standard definition.
According to the technical means, the ODX diagnosis data file is provided by a vehicle manufacturer and is used for realizing vehicle diagnosis.
With reference to the first aspect, in an implementation manner, the ODX diagnostic data file is read row by row, and each ODX object type is identified;
extracting test expected results corresponding to the ODX object types from the ODX diagnosis data file;
and according to the ODX object types, storing the test expected results respectively corresponding to the ODX object types into an expected result storage library.
According to the technical means, the test expected result extracted by the application is used for verifying whether the execution result output by the ODX interpreter is correct, the content of the test expected result is extracted from the ODX diagnosis data file, and the content is from the standard definition of ODX and does not need to be self-constructed or specially processed.
With reference to the first aspect, in one implementation manner, according to the ODX object types, the expected test results corresponding to the ODX object types are stored in the expected result repository with the ODX object as granularity and with a structure of key value pairs.
According to the technical means, the method stores the test expected results corresponding to each ODX object type into the expected result storage library, so that the corresponding test expected results are extracted when the test expected results and the execution results are compared later.
With reference to the first aspect, in one implementation manner, the ODX interpreter complies with MVCI standard protocol and implements MVCI defined standard ODX parsing interface.
According to the technical means, the ODX interpreter is required to follow the MVCI (Modular Vehicle Communication Interface, modularized vehicle communication interface) standard protocol, the MVCI standardizes the analysis interface of the ODX diagnostic data file, the application is mainly aimed at the ODX interpreter to perform function verification, and the ODX interpreter is assumed to follow the MVCI standard protocol, namely, the standard ODX analysis interface defined by the MVCI is realized.
With reference to the first aspect, in one implementation manner, a target test item of the ODX interpreter is selected;
selecting a target test object from the ODX diagnosis data file according to the target test item;
and calling an MVCI corresponding interface to execute the ODX interpreter through the target test object, and outputting an execution result.
With reference to the first aspect, in one implementation manner, the expected test result corresponding to the target test object is queried from the expected result storage library;
matching the queried expected test result with the execution result corresponding to the target test object, and if matching is successful, executing correctly by the ODX interpreter;
if the matching fails, the ODX interpreter executes the error and outputs detailed error information.
According to the technical means, the expected test result and the execution result are compared, and if the matching is successful, the ODX interpreter executes correctly; if the matching fails, the ODX interpretation execution error is indicated, and detailed error information is output, so that the correctness and completeness of the ODX interpreter function are verified.
In a second aspect, the present application provides a function verification system for an ODX interpreter, where the system is configured to implement a function verification method for an ODX interpreter as described above, and the system includes: the system comprises an ODX diagnosis data file module, an expected result extraction module, an ODX interpreter execution module and an ODX interpreter verification module; the ODX diagnosis data file module is respectively connected to the input end of the expected result extraction module and the input end of the ODX interpreter execution module, and the output end of the expected result extraction module and the output end of the ODX interpreter execution module are respectively connected to the input end of the ODX interpreter verification module;
the ODX diagnosis data file module is used for acquiring an ODX diagnosis data file;
the expected result extracting module is used for extracting a test expected result from the ODX diagnosis data file according to ODX protocol standard definition;
the ODX interpreter execution module is used for executing an ODX interpreter and outputting an execution result according to the ODX diagnosis data file input to the ODX interpreter execution module;
the ODX interpreter verification module is used for comparing the expected test result and the execution result input to the ODX interpreter verification module and outputting the verification result of the ODX interpreter.
In a third aspect, the present application provides a computer device, where the computer device includes a processor and a memory, where at least one instruction is stored in the memory, where the at least one instruction is loaded and executed by the processor to implement a method for verifying a function of an ODX interpreter as described above.
In a fourth aspect, the present application provides a computer readable storage medium having stored therein at least one instruction that is loaded and executed by a processor to implement a method of functional verification for an ODX interpreter as described above.
The technical scheme that this application provided can include following beneficial effect:
firstly, an ODX diagnosis data file is obtained, and according to ODX protocol standard definition, a test expected result is extracted from the ODX diagnosis data file; then, according to the ODX diagnosis data file, executing an ODX interpreter and outputting an execution result; and finally comparing the expected test result with the execution result and outputting a verification result of the ODX interpreter. The application provides the function verification method for the ODX interpreter based on the ODX protocol standard and the application of the ODX protocol standard in the automobile diagnosis system, and the function verification method is used for verifying the correctness and completeness of the functions of the ODX interpreter, so that the stability of the ODX interpreter is improved, the development efficiency of the automobile diagnosis system is further improved, and the comprehensive development cost is reduced.
In addition, for a set of ODX interpreter system scenes to be newly developed, the application can perform functional test on the developed functions in the development process of the ODX interpreter system, so that the development efficiency of the ODX interpreter system is improved; for the existing ODX interpreter scene with a set of developed and completed ODX interpreter, the application can develop detailed system test on the ODX interpreter scene, and the functional correctness and completeness of the ODX interpreter scene are improved; for the development scene of the vehicle factory diagnosis system, the diagnosis data of the ECU of the vehicle type needs to be frequently changed in the development stage, the ODX interpreter can be subjected to functional test after the ECU diagnosis data is changed, the hidden problem is discovered very early, the development efficiency of the vehicle factory diagnosis system is improved, and the scheme provided by the application is flexible and has higher reliability.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are needed in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present application, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
Fig. 1 is a schematic diagram showing a structure of a function verification system for an ODX interpreter according to an exemplary embodiment.
Fig. 2 is a flowchart illustrating a method of functional verification for an ODX interpreter, according to an example embodiment.
Fig. 3 is a flowchart illustrating a method of functional verification for an ODX interpreter, according to an example embodiment.
FIG. 4 is a schematic diagram illustrating an extraction flow of test expected results according to an example embodiment.
Fig. 5 is a schematic diagram showing an execution result acquisition flow of the ODX interpreter according to an exemplary embodiment.
Fig. 6 is a schematic diagram showing a verification result acquisition flow of the ODX interpreter according to an exemplary embodiment.
Fig. 7 shows a block diagram of a computer device according to an exemplary embodiment of the present application.
Detailed Description
The following description of the embodiments of the present application will be made apparent and fully in view of the accompanying drawings, in which some, but not all embodiments of the invention are shown. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure.
Fig. 1 is a schematic diagram showing a structure of a function verification system for an ODX interpreter according to an exemplary embodiment. The system is used for realizing a function verification method for an ODX interpreter, and comprises the following steps: the system comprises an ODX diagnosis data file module, an expected result extraction module, an ODX interpreter execution module and an ODX interpreter verification module; the ODX diagnosis data file module is respectively connected to the input end of the expected result extraction module and the input end of the ODX interpreter execution module, and the output end of the expected result extraction module and the output end of the ODX interpreter execution module are respectively connected to the input end of the ODX interpreter verification module;
the ODX diagnosis data file module is used for acquiring an ODX diagnosis data file;
the expected result extracting module is used for extracting a test expected result from the ODX diagnosis data file according to the ODX protocol standard definition;
the ODX interpreter execution module is used for executing an ODX interpreter and outputting an execution result according to the ODX diagnosis data file input to the ODX interpreter execution module;
the ODX interpreter verification module is used for comparing the expected test result and the execution result input to the ODX interpreter verification module and outputting the verification result of the ODX interpreter.
Further, the proposal proposed by the application mainly based on the ODX protocol standard and the application thereof in the automobile diagnosis system is mainly divided into four modules: the system comprises an ODX diagnosis data file module, an expected result extraction module, an ODX interpreter execution module and an ODX interpreter verification module, wherein the modules work cooperatively.
Further, as shown in fig. 1, the collaborative workflow of each module is: the expected result extracting module firstly extracts a test expected result from the ODX diagnosis data file and marks the test expected result as a test expected; secondly, taking the ODX diagnosis data file as input of an ODX interpreter execution module, executing the ODX interpreter, outputting an execution result, and marking the result as a test result; and finally, inputting the TestExpect and the TestResult together into an ODX interpreter verification module, and outputting a verification result.
Further, the ODX diagnosis data file is provided by a vehicle manufacturer, contains data related to diagnosis of each ECU of the developed vehicle model, and has a content format conforming to the standard definition of the ODX protocol.
Further, the expected result extracting module is a priori knowledge base of the ODX interpreter verifying module, and the extracted test expected result is used as an input of the ODX interpreter verifying module to verify whether the execution result output by the ODX interpreter executing module is correct. The content of the expected test results is extracted from the ODX diagnosis data file, and the content is all defined by the standard of the ODX, and does not need to be self-constructed or specially processed, so that different contents can be extracted as expected results according to requirements for different types of ODX objects, and the same expected results can be extracted for similar or identical ODX objects with structures.
Further, the expected result extraction module of the present application can extract the required test expected result only after reading the ODX diagnostic data file provided by the vehicle factory row by row, and all the extracted test expected result contents are stored in a key-value (key-value pair) structure with the ODX object as granularity, wherein the key is SHORT-NAME (SHORT NAME) of the ODX object, the value is the extracted test expected result content, the format is JSON format, and JSON (JavaScript Object Notation, JS object profile) is a lightweight data exchange format.
Further, the general ODX interpreter should all follow MVCI (Modular Vehicle Communication Interface, modularized vehicle communication interface) standard protocol, MVCI standardizes the parsing interface of the ODX diagnostic data file, and the application is mainly aimed at the existing ODX interpreter to perform function verification, and it is assumed that the existing ODX interpreter complies with MVCI standard protocol, that is, the standard ODX parsing interface defined by MVCI is implemented.
Further, the ODX interpreter verification module of the present application first searches for a test expected result corresponding to the target test object from an expected result repository (the expected result repository is used for storing all test expected results); then matching the queried test expected result with the output result of the ODX interpreter execution module, and if the matching is successful, indicating that the ODX interpreter is executed correctly; if the matching fails, the ODX interpretation execution error is indicated, and error detailed information is output, so that the correctness and completeness of the ODX interpreter function are verified.
In summary, the application firstly obtains an ODX diagnostic data file, and extracts a test expected result from the ODX diagnostic data file according to an ODX protocol standard definition; then, according to the ODX diagnosis data file, executing an ODX interpreter and outputting an execution result; and finally comparing the expected test result with the execution result and outputting a verification result of the ODX interpreter. The application provides the function verification method for the ODX interpreter based on the ODX protocol standard and the application of the ODX protocol standard in the automobile diagnosis system, which is used for verifying the correctness and completeness of the functions of the ODX interpreter, so that the stability of the ODX interpreter is improved, the development efficiency of the automobile diagnosis system is further improved, and the comprehensive development cost is reduced.
In addition, for a set of ODX interpreter system scenes to be newly developed, the application can perform functional test on the developed functions in the development process of the ODX interpreter system, so that the development efficiency of the ODX interpreter system is improved; for the existing ODX interpreter scene with a set of developed and completed ODX interpreter, the application can develop detailed system test on the ODX interpreter scene, and the functional correctness and completeness of the ODX interpreter scene are improved; for the development scene of the vehicle factory diagnosis system, the diagnosis data of the ECU of the vehicle type needs to be frequently changed in the development stage, the ODX interpreter can be subjected to functional test after the ECU diagnosis data is changed, the hidden problem is discovered very early, the development efficiency of the vehicle factory diagnosis system is improved, and the scheme provided by the application is flexible and has higher reliability.
Fig. 2 is a flowchart illustrating a method of functional verification for an ODX interpreter, according to an example embodiment. The method is applied to a function verification system for an ODX interpreter as shown in FIG. 1. As shown in fig. 2, the method may include the steps of:
step S201, an ODX diagnostic data file is acquired.
In one possible embodiment, OTX: open Test Sequence eXchange is an open test sequence exchange format realized based on XML language, specially provides sequence development standard for automobile industry, and has wide application in the fields of vehicle diagnosis and the like; in the function verification system for an ODX interpreter provided by the application, the ODX diagnosis data file is stored in an ODX diagnosis data file module and provided by a vehicle factory, the ODX diagnosis data file comprises data (automobile electric control unit diagnosis data) related to each ECU diagnosis of a vehicle type developed by the vehicle factory, and the content format of the ODX diagnosis data file accords with an ODX protocol standard.
Step S202, according to ODX protocol standard definition, a test expected result is extracted from the ODX diagnosis data file.
In one possible implementation, since the content format of the ODX diagnostic data file conforms to the ODX protocol standard, the test expected result can be extracted from the ODX diagnostic data file according to the ODX protocol standard definition, and since the content of the test expected result is extracted from the ODX diagnostic data file and all the content is defined by the ODX protocol standard, no self-construction or special processing is required; when the expected test results are extracted, the expected test results can be extracted according to the ODX object types, and after the extraction is completed, the extracted expected test results are stored in an expected result storage library according to the ODX object types, so that the expected result storage library of the application can store all required expected test results corresponding to each ODX object type, and the expected test results in the expected result storage library are used as verification standards to verify the execution results of the ODX interpreter;
in the function verification system for the ODX interpreter provided by the application, the expected result extraction module is used for extracting a test expected result from the ODX diagnosis data file, the ODX diagnosis data file is an input of the expected result extraction module, and the test expected result is an output of the expected result extraction module.
Step S203, executing the ODX interpreter and outputting the execution result according to the ODX diagnosis data file.
In one possible implementation manner, after the expected result of the test corresponding to each required ODX object type is stored in the expected result storage, the expected result storage includes verification criteria corresponding to each execution result of the ODX interpreter; at this time, according to the test object selected from the ODX diagnostic data file, an ODX interpreter is executed, and an execution result corresponding to the test object is output, where each test expected result in the expected result repository corresponds to the execution result of each test object one by one;
in the function verification system for the ODX interpreter provided by the application, the ODX interpreter executing module executes the ODX interpreter according to the ODX diagnosis data file and outputs an execution result, wherein the ODX diagnosis data file is input by the ODX interpreter executing module, and the execution result is output by the ODX interpreter executing module.
Step S204, comparing the expected test result with the execution result, and outputting the verification result of the ODX interpreter.
In one possible implementation manner, since each test expected result in the expected result storage corresponds to each test object execution result one by one, when verifying the execution result of the ODX interpreter, the test expected result of the test object can be queried from the expected result storage according to the SHORT-NAME of the test object, and the test expected result and the execution result of the test object can be compared to obtain the verification result of the ODX interpreter;
in the function verification system for the ODX interpreter provided by the application, the ODX interpreter verification module is used for comparing the expected test result and the execution result and outputting the verification result of the ODX interpreter, wherein the expected test result and the execution result are both input by the ODX interpreter verification module, and the verification result is output by the ODX interpreter verification module.
In summary, the application firstly obtains an ODX diagnostic data file, and extracts a test expected result from the ODX diagnostic data file according to an ODX protocol standard definition; then, according to the ODX diagnosis data file, executing an ODX interpreter and outputting an execution result; and finally comparing the expected test result with the execution result and outputting a verification result of the ODX interpreter. The application provides the function verification method for the ODX interpreter based on the ODX protocol standard and the application of the ODX protocol standard in the automobile diagnosis system, and the function verification method is used for verifying the correctness and completeness of the functions of the ODX interpreter, so that the stability of the ODX interpreter is improved, the development efficiency of the automobile diagnosis system is further improved, and the comprehensive development cost is reduced.
In addition, for a set of ODX interpreter system scenes to be newly developed, the application can perform functional test on the developed functions in the development process of the ODX interpreter system, so that the development efficiency of the ODX interpreter system is improved; for the existing ODX interpreter scene with a set of developed and completed ODX interpreter, the application can develop detailed system test on the ODX interpreter scene, and the functional correctness and completeness of the ODX interpreter scene are improved; for the development scene of the vehicle factory diagnosis system, the diagnosis data of the ECU of the vehicle type needs to be frequently changed in the development stage, the ODX interpreter can be subjected to functional test after the ECU diagnosis data is changed, the hidden problem is discovered very early, the development efficiency of the vehicle factory diagnosis system is improved, and the scheme provided by the application is flexible and has higher reliability.
Fig. 3 is a flowchart illustrating a method of functional verification for an ODX interpreter, according to an example embodiment. The method is applied to a function verification system for an ODX interpreter as shown in FIG. 1. As shown in fig. 3, the method may include the steps of:
step S301, an ODX diagnostic data file is acquired.
In one possible implementation manner, the ODX diagnostic data file contains diagnostic data of an electronic control unit of a vehicle model developed by a vehicle manufacturer, and the content format of the diagnostic data of the electronic control unit of the vehicle accords with the standard definition of the ODX protocol.
Step S302, reading the ODX diagnosis data file row by row, and identifying each ODX object type.
Step S303, extracting test expected results corresponding to the ODX object types from the ODX diagnosis data file.
Step S304, according to the ODX object types, storing the test expected results corresponding to the ODX object types respectively to an expected result storage library.
In one possible implementation manner, according to the ODX object types, the expected test results corresponding to the ODX object types are stored in the expected result repository with the ODX object as granularity and with the structure of key value pairs.
Further, since the test expected results are all from the standard definition of ODX and do not need to be self-constructed or specially processed, different contents can be extracted as expected results for different types of ODX objects according to the requirements, and the same expected results can be extracted for similar or identical ODX objects. For a partial ODX object, this example lists the expected results of a partial test as follows:
(1) The expected results for the extraction of the DIAG-SERVICE object are as follows:
REQUEST object: namely, the REQUEST object contained in the DIAG-SERVICE object is represented by the ID attribute of the REQUEST object;
POS-RESPONSES object: namely, the POS-RESPONSE set contained in the DIAG-SERVICE object is represented by the ID attribute of the POS-RESPONSE object;
NEG-RESPONSES object: i.e. the NEG-RESPONSE set contained in the DIAG-SERVICE object is represented by the ID attribute of the NEG-RESPONSE object;
(2) The expected results of the REQUEST object extraction are as follows:
PARAMS object: i.e., a plurality of PARAM objects contained in the REQUEST object;
(3) The expected results of POS-RESPONSE object extraction are as follows:
PARAMS object: namely a plurality of PARAM objects contained in the POS-RESPONSE object;
(4) The expected results of NEG-RESPONSE object extraction are as follows:
PARAMS object: i.e., a plurality of PARAM objects contained in the present NEG-RESPONSE object;
(5) The expected results of the ParAM object extraction are as follows:
BYTE-POSITION object: i.e. the absolute starting position of the present PARAM object in bytes in the current PDU (Protocol Data Unit, protocol data unit, corresponding to a message structure body in ODX, such as REQUEST object, POS-RESPONSE object, etc.);
BIT-position object: namely, in the current PDU, the BIT starting POSITION of the PARAM object in BYTE-POSITION BYTEs takes BIT as a unit, and the range is 0-7;
BIT-LENGTH object: namely the BIT length occupied by the PARAM object in the current PDU;
CONST-VALUE object: i.e., a constant value defined in ODX for the present PARAM object;
(6) The expected results of the DATA-OBJECT-pro OBJECT extraction are as follows:
BIT-LENGTH object: namely the BIT length occupied by the data described by the DOP;
(7) The expected results of the STRUCTURE object extraction are as follows:
BYTE-SIZE object: namely the BYTE length occupied by the data described by the STRUCTURE object;
PARAMS object: namely, a plurality of PARAM objects contained in the STRUCTURE object;
the above examples list different expected result contents extracted according to a part of ODX objects, the extracted contents are all defined by ODX protocol standards, the extraction flow of test expected results is shown in fig. 4, and assuming that an ODX diagnostic data file provided by a vehicle factory meets the ODX protocol standards, the expected result extraction module in this embodiment can extract the required expected result only by reading the ODX diagnostic data file provided by the vehicle factory line by line, and all the extracted expected result contents are stored in a key-value (key-value pair) structure with the ODX objects as granularity, where key is SHORT-NAME (SHORT NAME) of the ODX objects, and value is the extracted expected result content in JSON format.
Step S305, selecting a target test item of the ODX interpreter.
In one possible implementation, the ODX interpreter complies with the MVCI standard protocol and implements the MVCI-defined standard ODX parsing interface.
Step S306, selecting a target test object from the ODX diagnosis data file according to the target test item.
Step S307, through the target test object, the MVCI corresponding interface is called to execute the ODX interpreter, and an execution result is output.
Further, first, before executing the ODX interpreter, a test item needs to be selected, for example: testing the interpretation correctness of the RESPONSE object contained in the DIAG-SERVICE object named TEST_SERVICE by the ODX interpreter; secondly, finding the DIAG-SERVICE object with the NAME of TEST_SERVICE from the ODX diagnosis data file provided by the vehicle manufacturer; next, all the RESPONSE sets, including POS-RESPONSEs and NEG-RESPONSEs, contained in the TEST_SERVICE object are obtained from the ODX diagnostic data file provided by the vehicle manufacturer through the TEST_SERVICE object call MVCI getDbResponses () interface as ODX interpreter execution outputs. The ODX interpreter execution result acquisition flow is shown in fig. 5.
Step S308, comparing the expected test result with the execution result, and outputting the verification result of the ODX interpreter.
In one possible implementation manner, the verification result obtaining flow of the ODX interpreter is as shown in fig. 6, and the expected test result corresponding to the target test object is queried from the expected result storage library;
matching the queried expected test result with the execution result corresponding to the target test object, and if the matching is successful, executing correctly by the ODX interpreter;
if the matching fails, the ODX interpreter executes errors and outputs detailed error information, so that the correctness and completeness of the functions of the ODX interpreter are verified.
The disclosure of the above embodiments is explained below by way of a simple example:
if the analysis result of a DIAG-SERVICE object in the ODX diagnostic data file is verified, the verification steps are as follows:
(1) In the ODX diagnostic data file provided by the vehicle manufacturer, there is a DIAG-SERVICE object named TEST_SERVICE, and the ODX is defined as follows:
(2) The test_service TEST expected result extracted by the expected result extraction module is as follows:
(3) The output result of the ODX interpreter execution module and the verification result of the ODX interpreter verification module are as follows:
it can be seen that the present embodiment proposes a method for performing system test on an ODX interpreter, which is used for verifying the correctness and completeness of the function of the ODX interpreter; the ODX interpreter test can be performed in a static environment without verifying the functional correctness of the ODX interpreter through an actual ECU diagnosis environment, and the diagnosis test efficiency is improved.
In summary, the application firstly obtains an ODX diagnostic data file, and extracts a test expected result from the ODX diagnostic data file according to an ODX protocol standard definition; then, according to the ODX diagnosis data file, executing an ODX interpreter and outputting an execution result; and finally comparing the expected test result with the execution result and outputting a verification result of the ODX interpreter. The application provides the function verification method for the ODX interpreter based on the ODX protocol standard and the application of the ODX protocol standard in the automobile diagnosis system, and the function verification method is used for verifying the correctness and completeness of the functions of the ODX interpreter, so that the stability of the ODX interpreter is improved, the development efficiency of the automobile diagnosis system is further improved, and the comprehensive development cost is reduced.
In addition, for a set of ODX interpreter system scenes to be newly developed, the application can perform functional test on the developed functions in the development process of the ODX interpreter system, so that the development efficiency of the ODX interpreter system is improved; for the existing ODX interpreter scene with a set of developed and completed ODX interpreter, the application can develop detailed system test on the ODX interpreter scene, and the functional correctness and completeness of the ODX interpreter scene are improved; for the development scene of the vehicle factory diagnosis system, the diagnosis data of the ECU of the vehicle type needs to be frequently changed in the development stage, the ODX interpreter can be subjected to functional test after the ECU diagnosis data is changed, the hidden problem is discovered very early, the development efficiency of the vehicle factory diagnosis system is improved, and the scheme provided by the application is flexible and has higher reliability.
Referring to fig. 7, a schematic diagram of a computer device according to an exemplary embodiment of the present application is provided, where the computer device includes a memory and a processor, and the memory is configured to store a computer program, and when the computer program is executed by the processor, implement a function verification method for an ODX interpreter as described above.
The processor may be a central processing unit (Central Processing Unit, CPU). The processor may also be any other general purpose processor, digital signal processor (Digital Signal Processor, DSP), application specific integrated circuit (Application Specific Integrated Circuit, ASIC), field programmable gate array (Field-Programmable Gate Array, FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof.
The memory, as a non-transitory computer readable storage medium, may be used to store non-transitory software programs, non-transitory computer executable programs, and modules, such as program instructions/modules corresponding to the methods in embodiments of the present application. The processor executes various functional applications of the processor and data processing, i.e., implements the methods of the method embodiments described above, by running non-transitory software programs, instructions, and modules stored in memory.
The memory may include a memory program area and a memory data area, wherein the memory program area may store an operating system, at least one application program required for a function; the storage data area may store data created by the processor, etc. In addition, the memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, flash memory device, or other non-transitory solid state storage device. In some implementations, the memory optionally includes memory remotely located relative to the processor, the remote memory being connectable to the processor through a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.
In an exemplary embodiment, a computer readable storage medium is also provided for storing at least one computer program that is loaded and executed by a processor to implement all or part of the steps of the above method. For example, the computer readable storage medium may be Read-Only Memory (ROM), random-access Memory (Random Access Memory, RAM), compact disc Read-Only Memory (CD-ROM), magnetic tape, floppy disk, optical data storage device, and the like.
Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the application disclosed herein. This application is intended to cover any variations, uses, or adaptations of the application following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the application pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.
It is to be understood that the present application is not limited to the precise arrangements and instrumentalities shown in the drawings, which have been described above, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Claims (10)

1. A method of functional verification for an ODX interpreter, the method comprising:
obtaining an ODX diagnosis data file;
extracting a test expected result from the ODX diagnosis data file according to an ODX protocol standard definition;
executing an ODX interpreter according to the ODX diagnosis data file and outputting an execution result;
and comparing the expected test result with the execution result, and outputting a verification result of the ODX interpreter.
2. The method of claim 1, wherein the ODX diagnostic data file contains diagnostic data of an automotive electronic control unit of a model developed by a vehicle manufacturer, and wherein the content format of the diagnostic data of the automotive electronic control unit complies with an ODX protocol standard definition.
3. The method of claim 1, wherein extracting the test expected result from the ODX diagnostic data file according to an ODX protocol standard definition comprises:
reading the ODX diagnosis data file row by row, and identifying each ODX object type;
extracting test expected results corresponding to the ODX object types from the ODX diagnosis data file;
and according to the ODX object types, storing the test expected results respectively corresponding to the ODX object types into an expected result storage library.
4. The method according to claim 3, wherein storing the test expected results respectively corresponding to the respective ODX object types to an expected result repository according to the ODX object types, comprises:
and according to the ODX object types, storing the test expected results corresponding to the ODX object types respectively to the expected result storage library by taking the ODX object as granularity and the structure of the key value pair.
5. The method of claim 1, wherein the ODX interpreter complies with the MVCI standard protocol and implements a MVCI defined standard ODX parsing interface.
6. The method according to any one of claims 1 to 5, wherein executing the ODX interpreter and outputting the execution result according to the ODX diagnostic data file includes:
selecting a target test item of the ODX interpreter;
selecting a corresponding target test object from the ODX diagnosis data file according to the target test item;
and calling an MVCI corresponding interface to execute the ODX interpreter through the target test object, and outputting an execution result.
7. The method of claim 6, wherein comparing the test expected result and the execution result and outputting a verification result of the ODX interpreter comprises:
inquiring a test expected result corresponding to the target test object from an expected result storage library;
matching the queried expected test result with the execution result corresponding to the target test object, and if matching is successful, executing correctly by the ODX interpreter;
if the matching fails, the ODX interpreter executes the error and outputs detailed error information.
8. A functional verification system for an ODX interpreter, wherein the system is configured to implement a functional verification method for an ODX interpreter according to any one of claims 1 to 7, the system comprising: the system comprises an ODX diagnosis data file module, an expected result extraction module, an ODX interpreter execution module and an ODX interpreter verification module; the ODX diagnosis data file module is respectively connected to the input end of the expected result extraction module and the input end of the ODX interpreter execution module, and the output end of the expected result extraction module and the output end of the ODX interpreter execution module are respectively connected to the input end of the ODX interpreter verification module;
the ODX diagnosis data file module is used for acquiring an ODX diagnosis data file;
the expected result extracting module is used for extracting a test expected result from the ODX diagnosis data file according to ODX protocol standard definition;
the ODX interpreter execution module is used for executing an ODX interpreter and outputting an execution result according to the ODX diagnosis data file input to the ODX interpreter execution module;
the ODX interpreter verification module is used for comparing the expected test result input to the ODX interpreter verification module with the ODX interpreter execution result and outputting the ODX interpreter verification result.
9. A computer device comprising a processor and a memory having stored therein at least one instruction that is loaded and executed by the processor to implement a method of functional verification for an ODX interpreter as claimed in any one of claims 1 to 7.
10. A computer readable storage medium having stored therein at least one instruction that is loaded and executed by a processor to implement a method of functional verification for an ODX interpreter as claimed in any one of claims 1 to 7.
CN202311213076.8A 2023-09-19 2023-09-19 Function verification method and system for ODX interpreter Active CN117271330B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311213076.8A CN117271330B (en) 2023-09-19 2023-09-19 Function verification method and system for ODX interpreter

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311213076.8A CN117271330B (en) 2023-09-19 2023-09-19 Function verification method and system for ODX interpreter

Publications (2)

Publication Number Publication Date
CN117271330A true CN117271330A (en) 2023-12-22
CN117271330B CN117271330B (en) 2024-07-19

Family

ID=89202035

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311213076.8A Active CN117271330B (en) 2023-09-19 2023-09-19 Function verification method and system for ODX interpreter

Country Status (1)

Country Link
CN (1) CN117271330B (en)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105867352A (en) * 2016-04-29 2016-08-17 深圳市元征科技股份有限公司 ODX diagnostic system
CN107491061A (en) * 2017-08-31 2017-12-19 中国第汽车股份有限公司 The network automatically test system and its method of a kind of commercial car OBD diagnostic devices
CN112860563A (en) * 2021-02-25 2021-05-28 东风柳州汽车有限公司 Automobile diagnostic instrument testing method, device, equipment and storage medium
US20210241548A1 (en) * 2020-01-31 2021-08-05 Martin Raul Maurer Vehicle diagnostic testing system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105867352A (en) * 2016-04-29 2016-08-17 深圳市元征科技股份有限公司 ODX diagnostic system
CN107491061A (en) * 2017-08-31 2017-12-19 中国第汽车股份有限公司 The network automatically test system and its method of a kind of commercial car OBD diagnostic devices
US20210241548A1 (en) * 2020-01-31 2021-08-05 Martin Raul Maurer Vehicle diagnostic testing system
CN112860563A (en) * 2021-02-25 2021-05-28 东风柳州汽车有限公司 Automobile diagnostic instrument testing method, device, equipment and storage medium

Also Published As

Publication number Publication date
CN117271330B (en) 2024-07-19

Similar Documents

Publication Publication Date Title
CN110351325B (en) Data processing method and related equipment
CN109658542B (en) Diagnostic parameter data verification method, diagnostic parameter data verification device, vehicle diagnostic equipment and storage medium
CN110990276A (en) Automatic testing method and device for interface field and storage medium
CN114090671A (en) Data import method and device, electronic equipment and storage medium
CN108804315B (en) Test method and device applied to dynamic development, electronic equipment and storage medium
CN111723019A (en) Interface debugging method and system
CN111258884B (en) System for automatically generating interface accuracy verification script
CN113384896A (en) Unity-based resource packaging method, device, equipment and medium
CN117349188B (en) Test case generation method and device based on large model
CN115599359A (en) Code generation method, device, equipment and medium
CN113761879A (en) Message format checking method, device and storage medium
CN114896161A (en) File construction method and device based on artificial intelligence, computer equipment and medium
CN112395339B (en) Intersystem data admission verification method, device, computer equipment and storage medium
CN111078529B (en) Client writing module testing method and device and electronic equipment
CN112800194A (en) Interface change identification method, device, equipment and storage medium
CN117271330B (en) Function verification method and system for ODX interpreter
CN112363939A (en) Method, system and equipment for quickly generating fuzzy test network protocol template
CN114564336B (en) Data consistency verification method, device, equipment and storage medium
CN110298018B (en) Text data processing method, device, computer equipment and storage medium
CN114253828A (en) Method and device for determining test template, computing equipment and storage medium
CN114020249B (en) Data processing method, device, electronic equipment and storage medium
CN115113856B (en) Automatic code generation method, system, equipment and medium
CN113360381B (en) Case verification system and method in automatic test of host lower platform
CN112445491B (en) File sequence processing method, device, terminal equipment and storage medium
CN111722996B (en) Interactive standard compliance testing method and device

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant