Vehicle diagnosis method and device, electronic equipment and storage medium
By parsing and decomposing the response data in the ODX file in advance and determining the parsing strategy in advance, the problem of slow ODX resolution is solved, and the effects of rapid diagnosis and resource conservation are achieved.
Patent Information
- Application Number
- CN202311470294.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-11-06
- Publication Date
- 2025-05-13
AI Technical Summary
The ODX resolution speed is slow, resulting in the inability to obtain diagnostic results in time, affecting the vehicle's diagnostic efficiency.
The ODX file is parsed in advance, the response data is decomposed into fixed partial parameters and variable partial parameters, and the analysis strategy of each variable partial parameter is determined in advance, and the parameter values input by user or ECU reply are directly converted, so as to quickly generate diagnostic requests or responses.
It significantly improves the vehicle resolution speed, improves vehicle diagnostic efficiency, and reduces hard disk and memory consumption, meeting the needs of rapid analysis and diagnostic data under limited resource conditions.
Smart Images
Figure CN119987321A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of vehicle diagnosis technology, and in particular to a vehicle diagnosis method and device, electronic equipment, and computer-readable storage medium. Background Art
[0002] Open diagnostic data (ODX) uses a unified format to define the vehicle's network topology, ECU diagnostic PIN definition, diagnostic address, communication baud rate, communication timeout parameters, fault code, DID definition, etc., which can achieve detailed analysis of diagnostic data; through a unified format definition, the database of the diagnostic development process can be applied to various links such as testing, offline and after-sales, which greatly reduces the development communication cost and saves development time. Although ODX has many advantages, there are also some problems in the current vehicle control unit running the diagnostic engine using ODX for vehicle diagnosis. For example, ODX has a complex structure and slow parsing speed. It takes about 1 minute to load the element link when parsing the table connection contained in ODX using standard D-Server technology, resulting in the inability to obtain diagnostic results in time. Therefore, the current solution for using ODX for vehicle diagnosis needs to be further improved. Summary of the invention
[0003] The purpose of the present application is to provide a vehicle diagnosis method and device, electronic device, and computer-readable storage medium to solve the technical problem of slow ODX parsing speed.
[0004] To achieve the above objectives, the present application provides a vehicle diagnosis method, including:
[0005] Loading service data of the current diagnostic service; the service data includes a request address, a service request, a fault code list, response data and a parsing strategy, and the response data includes fixed part parameters and variable part parameters;
[0006] Acquire a diagnosis request command according to the service request, and send the diagnosis request command to the ECU according to the request address;
[0007] Receive reply data from the ECU, match fixed part parameters of the reply data with fixed part parameters of the response data, if they do not match, determine an error, generate corresponding fault information according to the fault code list, if they match, parse the variable part parameters of the reply data according to the parsing strategy.
[0008] The embodiment of the present application pre-parses the ODX file to obtain service data of each diagnostic service and stores it in the vehicle local memory, wherein the service data includes a request address, a service request, a fault code list, response data, and a parsing strategy, etc.; when the vehicle control unit runs the diagnostic engine, the service data of the currently called diagnostic service can be loaded from the local memory, and then the vehicle is diagnosed according to the service data; since the embodiment of the present application decomposes the response data of each service in the ODX file into fixed part parameters and variable part parameters, when the ODX file is pre-parsed, the parsing strategy corresponding to each variable part parameter has been determined, and these parsing strategies can directly convert the parameter values input by the user or the parameter values replied by the ECU, so as to quickly obtain the diagnostic request to be sent to the ECU or the diagnostic response replied by the ECU. Therefore, compared with the standard D-Server technology for parsing ODX, the embodiment of the present application can greatly improve the vehicle parsing speed, thereby improving the vehicle diagnostic efficiency.
[0009] An embodiment of the present application also provides a vehicle diagnostic device, including a module for executing the vehicle diagnostic method described in the above embodiment.
[0010] An embodiment of the present application also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the above-mentioned vehicle diagnostic method is implemented when the processor executes the program.
[0011] An embodiment of the present application also provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the above-mentioned vehicle diagnostic method is implemented. BRIEF DESCRIPTION OF THE DRAWINGS
[0012] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.
[0013] Figure 1 This is a flow chart of a vehicle diagnostic method in one embodiment of the present application.
[0014] Figure 2 This is a data structure diagram of the basic information of ECU in one embodiment of the present application.
[0015] Figure 3 This is a data structure diagram of a fault code in one embodiment of the present application.
[0016] Figure 4This is a data structure diagram of a service request, positive response data, and negative response data in one embodiment of the present application.
[0017] Figure 5 This is a pre-parsing flowchart of an ODX file in an embodiment of the present application.
[0018] Figure 6 This is a specific flow chart of a vehicle diagnostic method in one embodiment of the present application. DETAILED DESCRIPTION
[0019] The detailed description of the drawings is intended as an illustration of the current embodiment of the present application, and is not intended to represent the only form in which the present application can be implemented. It should be understood that the same or equivalent functions can be accomplished by different embodiments intended to be included in the spirit and scope of the present application.
[0020] An embodiment of the present application provides a vehicle diagnostic method. The method can be based on a diagnostic engine to perform the steps of the method. The diagnostic engine is installed in a vehicle control unit, such as a central control unit (CCU) of the vehicle, see Figure 1 , the method comprises the following steps:
[0021] Step S10, loading the service data of the current diagnostic service; the service data includes a request address, a service request, a fault code list, response data and a parsing strategy, and the response data includes fixed part parameters and variable part parameters;
[0022] Specifically, the request address is the address of the ECU that is currently to execute the diagnosis request command;
[0023] The service request refers to the request content sent to the ECU during the diagnosis process, which is used to obtain diagnostic data, perform tests, adjust parameters, etc. In this embodiment, a corresponding diagnostic request command needs to be generated according to the content of the service request;
[0024] The fault code list refers to a list of possible fault codes that may occur in a vehicle. Each fault code has a unique identification code and is usually accompanied by other related information, such as fault description, fault type, fault cause, possible repair measures, etc. The specific ODX file and the fault code list therein may vary depending on the vehicle manufacturer, model and software version;
[0025] The response data can be understood as a kind of reference data, which means that the reply data output by the ECU after executing the diagnostic request command should match the reference data. Therefore, the response data is used for subsequent matching with the ECU reply data;
[0026] The parsing strategy is used to parse the variable part parameters of the ECU reply data. The type of the variable part parameters is not unique. Therefore, for each parameter type, a specific parsing strategy needs to be pre-set for parsing.
[0027] Step S20: acquiring a diagnosis request command according to the service request, and sending the diagnosis request command to the ECU according to the request address.
[0028] Specifically, after receiving the diagnostic request command, the ECU will send a reply data to the diagnostic engine regardless of whether the ECU successfully executes the diagnostic request command; generally speaking, the diagnostic request command will carry the address of the diagnostic engine (reply address) and the address of the ECU (request address), and the ECU will send a reply data to the diagnostic engine according to the reply address, and load the service data of the current diagnostic service including the reply address.
[0029] Step S30, receiving the reply data from the ECU, matching the fixed part parameters of the reply data with the fixed part parameters of the response data, if they do not match, determining an error, generating corresponding fault information according to the fault code list, if they match, parsing the variable part parameters of the reply data according to the parsing strategy.
[0030] Specifically, the method of this embodiment pre-parses the ODX file to obtain service data of each diagnostic service and stores it in the vehicle local memory, wherein the service data includes a request address, a service request, a fault code list, response data, and a parsing strategy, etc.; when the vehicle control unit runs the diagnostic engine, the service data of the currently called diagnostic service can be loaded from the local memory, and then the vehicle is diagnosed according to the service data; since the embodiment of the present application decomposes the response data of each service in the ODX file into fixed part parameters and variable part parameters, when the ODX file is parsed in advance, the parsing strategy corresponding to each variable part parameter has been determined, and these parsing strategies can directly convert the parameter values input by the user or the parameter values replied by the ECU, thereby quickly obtaining the diagnostic request to be sent to the ECU or the diagnostic response replied by the ECU. Therefore, compared with the use of standard D-Server technology to parse ODX, the embodiment of the present application can greatly improve the vehicle parsing speed, thereby improving the vehicle diagnostic efficiency.
[0031] In some embodiments, the service request may include only fixed part parameters, or may include fixed part parameters and variable part parameters; if a diagnostic service has no parameters available for user input, then the service request for the diagnostic service includes only fixed part parameters, but does not include variable part parameters; if a diagnostic service has parameters available for user input, then the service request for the diagnostic service includes fixed part parameters and variable part parameters.
[0032] The step S20 acquires a diagnosis request command according to the service request, including:
[0033] Step S21, if the service request only includes fixed part parameters, the fixed part parameters are used as a diagnosis request command, that is, the diagnosis request command = fixed part parameters;
[0034] Step S22: if the service request includes a fixed part parameter and a variable part parameter, and the variable part parameter does not belong to the RESERVED type, the parameter value of the variable part parameter input by the user is converted into a corresponding HEX value according to the parsing strategy corresponding to the variable part parameter, and the HEX value is concatenated to the end of the fixed part parameter to obtain a diagnosis request command, that is, the diagnosis request command = fixed part parameter + the HEX value;
[0035] Step S23, if the service request includes a fixed part parameter and a variable part parameter, and the variable part parameter is of RESERVED type, then 0s of the specified length of the variable part parameter are spliced at the end of the fixed part parameter to obtain a diagnosis request command, that is, the diagnosis request command = fixed part parameter + 0s of the specified length.
[0036] It should be noted that the RESERVED type in the ODX file refers to reserved fields or reserved data, which are reserved in the ODX standard and are not assigned to specific functions or information.
[0037] In some embodiments, different parsing strategies are preset in this embodiment for different variable parameter types, and the preset parsing strategies include LINEAR type parsing strategy, ASCII type parsing strategy, BCD type parsing strategy, HEX type parsing strategy and enumeration value type parsing strategy;
[0038] The LINEAR type parsing strategy refers to converting the physical value input by the user into the corresponding HEX value when obtaining the diagnosis request command, or converting the variable part parameter in the reply data from the HEX value to the corresponding physical value when parsing the reply data;
[0039] The ASCII type parsing strategy refers to converting the ASCII code input by the user into the corresponding HEX value when obtaining the diagnostic request command, or converting the variable part parameter in the reply data from the HEX value to the corresponding ASCII code when parsing the reply data;
[0040] The BCD type parsing strategy refers to converting the BCD value input by the user into the corresponding HEX value when obtaining the diagnostic request command, or converting the variable part parameter in the reply data from the HEX value to the corresponding BCD value when parsing the reply data;
[0041] The HEX type parsing strategy means that when obtaining the diagnostic request command, the parameter value input by the user does not need to be converted, or when parsing the reply data, the parameter value does not need to be converted, and the variable part parameters in the reply data do not need to be converted;
[0042] The enumeration value type parsing strategy refers to searching a preset reverse parsing table when obtaining a diagnostic request command, and converting the physical value input by the user into a corresponding HEX value according to the table lookup result, or, when parsing the reply data, searching a preset forward parsing table, and converting the variable part parameters in the reply data from HEX values to corresponding physical values according to the table lookup result.
[0043] In some embodiments, the service data further includes communication layer parameters. In the ODX file, the communication layer parameters are used to describe the diagnostic communication protocol and communication parameters. The communication layer parameters include various parameter settings related to diagnostic communication to ensure that the diagnostic tool and the diagnosed ECU can communicate correctly. The communication layer parameters specify the response time of the ECU.
[0044] The method further comprises:
[0045] Determine whether the ECU response times out according to the communication parameters; if so, determine that the ECU response fails, and generate corresponding fault information according to the fault code list.
[0046] Specifically, the response time of the ECU diagnosis can be determined according to the communication parameters. If after sending a diagnosis request command to the ECU, the response data of the ECU is not received after the response time has passed, it is determined that the ECU response has timed out.
[0047] In some embodiments, the response data includes positive response data and negative response data, and the positive response data and the negative response data each include a fixed portion parameter and a variable portion parameter;
[0048] The matching of the fixed part parameters of the reply data with the fixed part parameters of the response data specifically includes:
[0049] Step S31, if the response type of the reply data is an affirmative response, matching the fixed part parameters of the reply data with the fixed part parameters of the affirmative response data; specifically, if they match, parsing the variable part parameters of the reply data according to the parsing strategy corresponding to the variable part parameters of the affirmative response data; if they do not match, determining an error and generating corresponding fault information according to the fault code list;
[0050] Step S32, if the response type of the reply data is a negative response, the fixed part parameters of the reply data are matched with the fixed part parameters of the negative response data; specifically, if they match, the variable part parameters of the reply data are parsed according to the parsing strategy corresponding to the variable part parameters of the negative response data; if they do not match, an error is determined and corresponding fault information is generated according to the fault code list.
[0051] Specifically, if there is no timeout, that is, the reply data from the ECU is received within the reply time after the diagnostic request command is sent to the ECU, then it is first determined whether the response type of the reply data is a positive response or a negative response, and the reply data also includes fixed part parameters and variable part parameters; specifically, it can be determined whether it is a positive response or a negative response based on whether Byte[0] of the reply data is equal to 0x7F. When Byte[0] is not equal to 0x7F, it is determined that the ECU is a positive response type and the process goes to step S31. When Byte[0] is equal to 0x7F, it is determined that the ECU is a negative response type and the process goes to step S32.
[0052] The positive response of each diagnostic service in the ODX file contains multiple parameters. In this embodiment, these parameters of the positive response are decomposed into fixed part parameters and variable part parameters. The fixed part parameters of the positive response are used for matching, and the variable part parameters need to be parsed. The parsing strategy corresponding to each variable part parameter is predetermined. These parsing strategies can directly convert the parameter value input by the user or the parameter value replied by the ECU, so as to quickly obtain the diagnostic request to be sent to the ECU or the diagnostic response replied by the ECU; wherein, when there is no match in step S31, for example, the fixed part of the positive response in the service data is 62F100, and the fixed part of the corresponding data replied by the ECU is 62F10155667788, the corresponding fault information is recorded as the current diagnostic result; when there is a match in step S31, the parsing results of the fixed part parameters of the reply data and the variable part parameters of the reply data are spliced together to obtain the current diagnostic result, that is, the current diagnostic result = the parsing results of the fixed part parameters of the reply data + the variable part parameters of the reply data;
[0053] The negative response of each diagnostic service in the ODX file contains multiple parameters (Parameter). In this embodiment, these parameters of the negative response are decomposed into fixed part parameters and variable part parameters. The fixed part parameters of the negative response are used for matching, and the variable part parameters need to be parsed. The parsing strategy corresponding to each variable part parameter is predetermined. These parsing strategies can directly convert the parameter value input by the user or the parameter value replied by the ECU, so as to quickly obtain the diagnostic request to be sent to the ECU or the diagnostic response replied by the ECU; wherein, when there is no match in step S32, the corresponding fault information is recorded as the current diagnostic result; when there is a match in step S32, the parsing results of the fixed part parameters of the reply data and the variable part parameters of the reply data are spliced together to obtain the current diagnostic result, that is, the current diagnostic result = the fixed part parameters of the reply data + the parsing results of the variable part parameters of the reply data.
[0054] It should be noted that, in ODX diagnosis, a diagnostic service package may include one or more service requests. At this time, if the current diagnostic service has other service requests, then return to step S20, continue to send the next diagnostic request command to the ECU according to the other service requests, and then continue to execute step S30;
[0055] It should be noted that since the present embodiment decomposes the positive response and negative response of each service in the ODX file into fixed part parameters and variable part parameters, the parsing strategy corresponding to each variable part parameter has been determined when the ODX file is parsed in advance. These parsing strategies can directly convert the parameter values (variable part parameters) input by the user or the parameter values (variable part parameters) replied by the ECU, so as to quickly obtain the diagnostic request to be sent to the ECU or the diagnostic response replied by the ECU. Therefore, compared with the use of standard D-Server technology to parse ODX, the embodiment of the present application can greatly improve the vehicle parsing speed, thereby improving the vehicle diagnostic efficiency.
[0056] In some embodiments, the service data of each diagnostic service is obtained by pre-parsing the ODX file, and is converted into JSON format and stored in the vehicle's local memory.
[0057] Specifically, the current vehicle control unit runs the diagnostic engine and uses ODX to perform vehicle diagnosis, which has the following problems. For example, the hard disk consumption is large. Using the standard D-Server technology to store the whole vehicle-level ODX consumes about 50M hard disk. For another example, the memory consumption is large. Using the standard D-Server technology to store and load the whole vehicle-level ODX database consumes about 500M-1G memory. At this time, the vehicle control unit does not have much remaining memory for other components to work, which easily causes other vehicle software to crash. Before the method of this embodiment arranges the ODX file to the vehicle, the ODX file is restructured in advance to obtain service data of each diagnostic service (including ECU name, request address, reply address, fault code list, communication parameters, service request, positive response, negative response and preset parsing strategy), and the format is converted into JSON format to achieve format simplification. Then, the JSON format file is stored in the local storage, reducing the hard disk consumption of the whole vehicle-level ODX to about 3M and the memory consumption to 30M, thereby meeting the demand for fast parsing of diagnostic data under limited vehicle hard disk and memory resources.
[0058] When parsing the ODX file, the parameters of the service request, positive response data and negative response data are decomposed into fixed part parameters and variable part parameters, among which the parameters of CODED-CONST type, TABLE-KEY type and MATCHING-REQUEST-PARAM type are parsed into fixed part parameters, and the parameters of other types are parsed into variable part parameters.
[0059] The following is a detailed description of the pre-parsing process of the ODX file in this embodiment. Figure 5 , including the following parsing steps:
[0060] Step 1, extract the ECU name, request address, reply address, and communication layer parameters Cp_Ar, Cp_As, Cp_Br, Cp_Bs, Cp_Cr, and Cp_Cs in the ODX file for caching; these 9 parameters define the key parameters for the on-board diagnostic engine to parse the diagnostic message, and the extraction path (XPATH expression) of each information is as shown in Table 1 below;
[0061] Table 1-ECU basic information extraction path
[0062]
[0063]
[0064]
[0065] The ECU name refers to the name of the ECU that is currently to execute the diagnostic request command;
[0066] The reply address is the address of the vehicle control unit running the diagnostic engine, and the ECU sends the reply data to the diagnostic engine according to the reply address;
[0067] After extracting the above 9 pieces of information, the basic information data structure of the ECU is as follows: Figure 2 As shown;
[0068] Step 2, extract the fault code definition in the ODX file, including the fault code HEX value, display value, text index TI (TextIndex) fault code translation information. The extraction path is ODX / DIAG-LAYER-CONTAINER / BASE-VARIANTS / BASE-VARIANT / DIAG-DATA-DICTIONARY-SPEC / DTC-DOPS / DTC-DOP / DTCS / DTC. The HEX value, display code, text index, and fault text path of DTC are as follows:
[0069] Table 2-ECU fault code information extraction path
[0070]
[0071] The data structure after fault code extraction is as follows Figure 3 .
[0072] Step 3. Extract the basic service information in the ODX file, including the service's "SHORT-NAME" and "SEMANTIC". The extraction path is: ODX / DIAG-LAYER-CONTAINER / BASE-VARIANTS / BASE-VARIANT / DIAG-COMMS / DIAG-SERVICE.
[0073] Step 4, find the linked service request ("REQUEST"), positive response data ("POS-RESPONSE") and negative response data ("NEG-RESPONSE") through the service ID, and decompose "REQUEST", "POS-RESPONSE" and "NEG-RESPONSE" into two parts, namely a fixed part and a variable part, in order to speed up the matching and parsing of the diagnostic data, such as Figure 4As shown; the service request, positive response data, and negative response data are all composed of multiple parameters (Parameter), each parameter has a corresponding parsing strategy, which is a calculation formula (Date Object Property, referred to as DOP), where CODED-CONST, TABLE-KEY, MATCHING-REQUEST-PARAM type PARAM will be parsed into a fixed part, which is a string, and the other types of PARAM are parsed into a variable part; each variable part PARAM is linked to a DOP (except for RESERVED type), indicating its parsing strategy, which is used when sending a diagnostic request. If there is a variable part parameter available for user input, the parameter value entered by the user is converted into a HEX value and sent to the bus, such as converting "ON" to 0x01 to control the vehicle to light up the headlights. When receiving the ECU reply data, it is used to parse the HEX data stream replied by the ECU into a user-readable parameter value, such as converting 0x01 to "ON" to display that the headlight control result is lit; if the service has no parameters available for user input, the service request has no variable part parameters. Furthermore, for the multi-layer ID links of table (TABLE) and structure (STRUCTURE), including TABLE-REF, TABLE-ROW-REF, TABLE-KEY-REF, STRUCTURE-REF, the link ID is used to search level by level until all parameters (PARAM) are linked to DOP through only one layer of ID. This process can effectively save the time of parsing ODX parameter links on the vehicle side. After parsing, the structure of service request, positive response reply, and negative response reply is as follows: Figure 4 As shown, after link resolution, the link ID and OID information are discarded.
[0074] Step 5, calculate the BYTE-POSITION and BIT-POSITION of each parameter (PARAM). When BIT-POSITION is 0, it is not displayed by default.
[0075] Step 6, parse the bit-length of the DOP in ODX and set the DOP type tag. The diagnostic analysis strategy DOP calculation types mainly include five categories: linear formula, ASCII type, enumeration value, BCD and HEX type. For each type, use the following tags to speed up the analysis:
[0076] For linear formulas, add the tag "COMPU-METHOD": "LINEAR" and store the coefficients a, b and c of the linear calculation formula y = (a + b * x) / c, and the coefficients c, -a, b of the inverse function x = (c * ya) / b, where y represents the physical value and x represents the HEX value. The function y = (a + b * x) / c is used to parse the HEX data stream into physical values in the positive response. The inverse calculation formula x = (c * yb) / a is used to convert the physical value into HEX in the diagnostic request so that the diagnostic data can be sent to the bus.
[0077] For the ASCII type, add the "IS-ASCII":"TRUE" tag to indicate that the calculation formula is of ASCII type. When the diagnosis engine parses it, it can quickly identify that the type is ASCII.
[0078] For the enumeration value type, a forward parsing table [Hex1: Physic1, Hex2: Physic2] and a reverse parsing table [Physic1: Hex1, Physic2: Hex2] are listed. The forward parsing table is used to parse the HEX value into a physical enumeration value in a positive response, and the reverse parsing table is used to convert the physical value into a HEX value in a diagnostic request. The two tables can speed up the parsing speed of the diagnostic engine.
[0079] For the BCD type, add the "IS-BCD":"TRUE" tag to indicate that the calculation formula is of BCD type. When the diagnostic engine parses, it can quickly identify that the type is BCD.
[0080] For the HEX type, add the "IS-HEXDUMP":"TRUE" tag to indicate that the calculation formula is of the HEXDUMP type. When the diagnostic engine parses, it can quickly identify that the type is HEX (physical value equals HEX data stream, no unit).
[0081] Step 7, save the parsing cache results as a JOSN file. Since the standard ODX database uses the double-tag structure of XML, for example <byte-position> 3< / byte-position> After saving as JSON, only the single tag BYTE-POSITION:3 remains, so this step alone can compress the ODX file size from 30M to about 15M. In addition, step 1 and step 4 further compress the file size to about 3M by presetting the routing table, communication parameters and resolving ID links.
[0082] Based on the above parsing strategy, the variable part parameters of the service request are parsed as follows:
[0083] Specifically, for LINEAR type parameters, use the inverse function x = (c*ya) / b to convert the physical value to a HEX value; for ASCII type parameters, convert the ASCII code to a HEX value, such as "A"->0x41; for BCD type parameters, convert BCD to a HEX value, such as "81"->0x08,0x01; for HEX type, directly splice the input into the request; for enumeration value types, look up the reverse parsing table to convert the physical value to a HEX value. The spliced position of the parsed HEX data stream corresponds to the BYTE-POSITION position of the PARAM.
[0084] Based on the above analysis strategy, the variable part parameters of the ECU response data are analyzed as follows:
[0085] For LINEAR type parameters, use the function y=(a+b*x) to convert the HEX value to a physical value; for ASCII type parameters, convert the HEX value to ASCII code, such as 0x41->"A"; for BCD type parameters, convert the HEX value to BCD, such as 0x08, 0x01->"81"; for HEX type, directly splice the input into the response; for enumeration value types, look up the forward parsing table and convert the HEX value to a physical value. The HEX data stream should be intercepted from the BYTE-POSITION position of the corresponding PARAM, and the interception length is BIT-LENGTH bits of the corresponding DOP.
[0086] In some embodiments, the method further comprises:
[0087] Step S60, after completing the diagnosis of the current diagnostic service, uninstalling the service data of the current diagnostic service;
[0088] Step S70, if there are other diagnostic services that have not been completed, then load the service data of the next diagnostic service and perform diagnosis according to the service data;
[0089] Step S80: If the diagnosis of all diagnostic services has been completed, the entire diagnostic process is terminated, and the diagnostic results of all diagnostic services are summarized and uploaded to the server.
[0090] Specifically, some current technologies deploy the ODX database and parsing software (D-Server) on a cloud server, and utilize the capabilities of the cloud server to parse diagnostic data. Each time a piece of diagnostic data is parsed, it is necessary to report a piece of data to the cloud server and wait for a reply. The vehicle-cloud communication takes a long time. During the electrical inspection of offline vehicles, 2000-3000 messages need to be parsed. At this time, the vehicle-cloud communication takes too long and cannot meet the real-time requirements of production. When the vehicle-cloud communication link is unstable, program operation is also prone to errors. Moreover, when the cloud parses diagnostic data for hundreds to thousands of vehicles, the computing power of the cloud server is consumed greatly. It should be noted that, compared with the solution of utilizing the capabilities of the cloud server to parse diagnostic data, this embodiment deploys the ODX database in the diagnostic engine of the vehicle control unit. When the diagnostic engine is run in the vehicle control unit, there is no need to interact with the cloud server multiple times. After all results are parsed, they are uniformly reported to the cloud server, thereby improving the program parsing speed and ensuring the integrity and accuracy of program execution.
[0091] Figure 6 A specific flow chart for implementing the method of this embodiment includes the following steps:
[0092] Step a1, loading the service data of the diagnostic service to be called into the memory of the central processing unit (CCU);
[0093] Step a2, determine whether the service request has variable part parameters; if so, proceed to step a31, if not, proceed to step a32;
[0094] Step a31, convert the variable part parameters of the service request from physical values to HEX values, splice them to the end of the fixed part parameters to obtain a diagnostic command, and then go to step a4;
[0095] Step a32, taking the variable part parameters of the service request as the diagnosis command and proceeding to step a4;
[0096] Step a4, sending a diagnostic command to the ECU according to the request address;
[0097] Step a5, determining whether the diagnostic response has timed out; that is, whether the ECU replies with data within the specified reply time, if so, proceeding to step a6, if not, proceeding to step a9;
[0098] Step a6, determining whether the reply data is a positive response or a negative response; if it is a positive response, proceed to step a71, if it is a negative response, proceed to step a72;
[0099] Step a71, determining whether the fixed part parameters of the reply data match the fixed part parameters of the positive response data, if they match, proceeding to step a81, if not, proceeding to step a9;
[0100] Step a72, determining whether the fixed part parameters of the reply data match the fixed part parameters of the negative response data, if they match, proceeding to step a82, if not, proceeding to step a9;
[0101] Step a81, according to the analysis strategy of the variable part parameter link of the affirmative response data, the variable part parameter of the ECU's reply data is converted from the HEX value to the corresponding physical value;
[0102] Step a82, according to the analysis strategy of the variable part parameter link of the negative response data, the variable part parameter of the reply data of the ECU is converted from the HEX value to the corresponding physical value (negative response code);
[0103] Step a9, cache the diagnosis result, uninstall the current service, and process the next service;
[0104] Step a10: After all services are processed, the summary results are uploaded to the cloud.
[0105] See also Figure 6 To help understand the above content of the method of this embodiment, based on the description of the above embodiment, it can be known that the method of this embodiment has the following advantages:
[0106] (1) The vehicle ODX database is compressed from 30M to about 3M, meeting the requirements for storing diagnostic databases in the limited storage environment of the vehicle and reducing the traffic consumption of updating ODX data in the vehicle;
[0107] (2) According to actual data statistics, the resolution time of a single service can be compressed to 0.1-0.2 seconds, ensuring the offline time;
[0108] (3) Reduced the memory consumption of ODX calls from 500M-1G to about 50M, reducing the memory load of the vehicle control unit;
[0109] (4) Placing ODX parsing in the vehicle disperses the parsing pressure on the cloud server, ensures the integrity of program execution, and compresses the multiple vehicle-cloud communication time.
[0110] Another embodiment of the present application provides a vehicle diagnostic device, including a module for executing the vehicle diagnostic method described in the above embodiment, and the module may be the diagnostic engine described in the above embodiment.
[0111] It should be noted that the device of this embodiment corresponds to the method of the above-mentioned embodiment. Therefore, the undescribed part of the device of this embodiment can be obtained by referring to the contents of the method of the above-mentioned embodiment, and will not be repeated here. Moreover, if the device of the above-mentioned embodiment is implemented in the form of a software function module and sold or used as an independent product, it can be stored in a computer-readable storage medium.
[0112] An embodiment of the present application also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above method when executing the program.
[0113] Wherein, the processor is, for example, a central control unit (CCU) of a vehicle, and the electronic device may further include a bus connecting different components (including memory and processor). The memory may include a computer-readable medium in the form of a volatile memory, such as a random access memory (RAM) and / or a cache memory. The memory may also include at least one program product having a set (e.g., at least one) of program modules, which are configured to perform the functions of each embodiment of the present application. The electronic device may also communicate with one or more external devices (e.g., a keyboard, a pointing device, a display, etc.), may communicate with one or more devices that enable a user to interact with the electronic device, and / or communicate with any device (e.g., a network card) that enables the electronic device to communicate with one or more other computing devices, such communication may be performed through an input / output (I / O) interface, and the electronic device may also communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) through a network adapter.
[0114] An embodiment of the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the above method is implemented.
[0115] Specifically, the computer-readable storage medium may include: any entity or recording medium that can carry the computer program instructions, a USB flash drive, a mobile hard disk, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.
[0116] The embodiments of the present application have been described above, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and changes will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The selection of terms used herein is intended to best explain the principles of the embodiments, practical applications, or technical improvements in the market, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.
Claims
1. A vehicle diagnostic method, characterized in that: include: Loading service data of the current diagnostic service; the service data includes a request address, a service request, a fault code list, response data and a parsing strategy, and the response data includes fixed part parameters and variable part parameters; Acquire a diagnosis request command according to the service request, and send the diagnosis request command to the ECU according to the request address; Receive reply data from the ECU, match fixed part parameters of the reply data with fixed part parameters of the response data, if they do not match, determine an error, generate corresponding fault information according to the fault code list, if they match, parse the variable part parameters of the reply data according to the parsing strategy.
2. The method according to claim 1, characterized in that The service request includes fixed part parameters, or includes fixed part parameters and variable part parameters; The obtaining of a diagnosis request command according to the service request comprises: If the service request only includes fixed part parameters, the fixed part parameters are used as a diagnosis request command; If the service request includes a fixed part parameter and a variable part parameter, and the variable part parameter does not belong to the RESERVED type, the parameter value of the variable part parameter input by the user is converted into a corresponding HEX value according to the parsing strategy corresponding to the variable part parameter, and the HEX value is concatenated to the end of the fixed part parameter to obtain a diagnosis request command; If the service request includes a fixed part parameter and a variable part parameter, and the variable part parameter is of RESERVED type, 0s of a length specified by the variable part parameter are spliced at the end of the fixed part parameter to obtain a diagnosis request command.
3. The method according to claim 2, characterized in that The parsing strategy includes at least one of a LINEAR type parsing strategy, an ASCII type parsing strategy, a BCD type parsing strategy, a HEX type parsing strategy, and an enumeration value type parsing strategy; The LINEAR type parsing strategy refers to converting the physical value input by the user into the corresponding HEX value when obtaining the diagnosis request command, or converting the variable part parameter in the reply data from the HEX value to the corresponding physical value when parsing the reply data; The ASCII type parsing strategy refers to converting the ASCII code input by the user into the corresponding HEX value when obtaining the diagnostic request command, or converting the variable part parameter in the reply data from the HEX value to the corresponding ASCII code when parsing the reply data; The BCD type parsing strategy refers to converting the BCD value input by the user into the corresponding HEX value when obtaining the diagnostic request command, or converting the variable part parameter in the reply data from the HEX value to the corresponding BCD value when parsing the reply data; The HEX type parsing strategy means that when obtaining the diagnostic request command, the parameter value input by the user does not need to be converted, or when parsing the reply data, the parameter value does not need to be converted, and the variable part parameters in the reply data do not need to be converted; The enumeration value type parsing strategy refers to searching a preset reverse parsing table when obtaining a diagnostic request command, and converting the physical value input by the user into a corresponding HEX value according to the table lookup result, or, when parsing the reply data, searching a preset forward parsing table, and converting the variable part parameters in the reply data from HEX values to corresponding physical values according to the table lookup result.
4. The method according to claim 1, characterized in that The service data also includes communication parameters; The method further comprises: Determine whether the ECU response times out according to the communication parameters; if so, determine that the ECU response fails, and generate corresponding fault information according to the fault code list.
5. The method according to claim 2, characterized in that: The response data includes positive response data and negative response data, and the positive response data and the negative response data both include fixed part parameters and variable part parameters; The matching of the fixed part parameters of the reply data with the fixed part parameters of the response data specifically includes: If the response type of the reply data is an affirmative response, matching the fixed part parameters of the reply data with the fixed part parameters of the affirmative response data; If the response type of the reply data is a negative response, the fixed part parameters of the reply data are matched with the fixed part parameters of the negative response data.
6. The method according to claim 5, characterized in that The service data of each diagnostic service is obtained by pre-parsing the ODX file, and then converted into JSON format and stored in the vehicle's local storage; When parsing the ODX file, the parameters of the service request, positive response data and negative response data are decomposed into fixed part parameters and variable part parameters, among which the parameters of CODED-CONST type, TABLE-KEY type and MATCHING-REQUEST-PARAM type are parsed into fixed part parameters, and the parameters of other types are parsed into variable part parameters.
7. The method according to any one of claims 1 to 6, characterized in that: The method further comprises: After completing the diagnosis of the current diagnostic service, uninstall the service data of the current diagnostic service; If the diagnosis of other diagnostic services is not completed, the service data of the next diagnostic service is loaded and the diagnosis is performed according to the service data; If the diagnosis of all diagnostic services has been completed, the entire diagnostic process ends, and the diagnostic results of all diagnostic services are summarized and uploaded to the server.
8. A vehicle diagnostic device, characterized in that: The vehicle diagnostic method comprises a module for executing the vehicle diagnostic method as claimed in any one of claims 1 to 7.
9. An electronic device, characterized in that: The method comprises a processor, a memory and a computer program stored in the memory and executable on the processor, wherein the method according to any one of claims 1 to 7 is implemented when the processor executes the program.
10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.