Vehicle fault snapshot data analysis method, device, equipment and medium

Abstract

The present application discloses a method, device, equipment and medium for analyzing vehicle fault snapshot data. The present application relates to the field of automobile technology. The method includes: receiving a synchronous response file fed back by the vehicle; reading the fault snapshot data and its rule information of the target controller therefrom; and storing it in a database in association with the target controller; initiating a remote diagnosis request, receiving a data response file of the vehicle end for the diagnosis request; obtaining vehicle information therefrom, and determining the controller to be diagnosed based on the vehicle information; determining the analysis rules based on the match with the database, and reading the fault snapshot data from the data response file. By adopting this solution, it can help and guide the developers of automobile companies to more intuitively understand the remote diagnosis process based on DOIP, the snapshot data analysis process and principles, reduce dependence on external suppliers, greatly improve the adaptation efficiency of various models, and improve the efficiency of developers.

Description

Technical Field

[0001] The present disclosure relates to the field of automobile technology, and in particular to a vehicle fault snapshot data analysis method, device, equipment and medium. Background Art

[0002] With the development of technology, the previous offline mode of vehicle diagnosis in the automotive field has many inconveniences because it requires offline operation and has high technical requirements.

[0003] DoIP, also known as Diagnostic communication over Internet Protocol, is defined by the ISO 13400 standard and is an IP-based automotive diagnostic protocol. Since DoIP can transmit large amounts of data, has a fast response speed, and can perform remote diagnosis via Ethernet, DoIP has gradually replaced traditional CAN bus and other diagnostic methods, becoming an inevitable trend in vehicle network diagnosis. Fault snapshot information is a set of additional data stored when the fault code is set, which can effectively support the repair of the fault. However, the acquisition of snapshot information is currently heavily dependent on suppliers, which is not transparent to car company developers and is not conducive to the adaptation and transformation of multiple models. Summary of the invention

[0004] In view of the above-mentioned defects or deficiencies in the prior art, it is desirable to provide a vehicle fault snapshot data analysis method, device, equipment and medium.

[0005] In a first aspect, the present application provides a method for analyzing vehicle fault snapshot data, the method comprising the following steps:

[0006] Sending an information synchronization request of a target controller to the vehicle end, and receiving a synchronization response file fed back by the vehicle end;

[0007] Reading the fault snapshot data of the target controller from the synchronization response file, and obtaining rule information of the fault snapshot data;

[0008] Associating the fault snapshot data, the rule information and the target controller into a database;

[0009] Initiate a remote diagnosis request and receive the vehicle-side data response file for the diagnosis request;

[0010] Acquire vehicle information from the data response file;

[0011] determining a controller to be diagnosed according to the vehicle information;

[0012] Determining a parsing rule for the controller to be diagnosed based on matching the controller to be diagnosed with the database;

[0013] The fault snapshot data is read from the data response file based on the parsing rule.

[0014] Reading the fault snapshot data of the target controller from the synchronization response file includes:

[0015] Searching for a target suffix file from the synchronization response file; wherein the target suffix file has a controller ID in its file name;

[0016] The fault snapshot data included in the target suffix file is read.

[0017] Reading the fault snapshot data included in the target suffix file includes:

[0018] For the target suffix file, the fault snapshot data is read according to a preset label sequence to obtain all fault snapshot data corresponding to the current controller ID.

[0019] For the target suffix file, the fault snapshot data is read according to a preset label sequence, including:

[0020] For the target suffix file, the diagnostic fault code information is read in the order of the diagnostic container tag, the controller multi-attribute definition tag, the controller attribute definition tag, the diagnostic data dictionary definition tag, the dictionary table tag, and the dictionary table tag.

[0021] Reading the fault snapshot data of the target controller from the synchronization response file and obtaining rule information of the fault snapshot data includes:

[0022] The fault snapshot data of the target controller is read from the synchronization response file, and the starting byte position, starting bit position and attribute value of the fault snapshot data are obtained.

[0023] After obtaining the starting byte, starting bit and attribute value of the fault snapshot data, the method further includes:

[0024] Determine a data processing type according to the attribute value; wherein the data processing type includes: no processing, enumeration conversion and linear conversion;

[0025] If it is a linear conversion type, the linear conversion rule is calculated according to the preset method.

[0026] In a second aspect, the present application provides a vehicle fault snapshot data analysis device, comprising:

[0027] A file receiving module, used for sending an information synchronization request of a target controller to a vehicle end, and receiving a synchronization response file fed back by the vehicle end;

[0028] An information reading module, used to read the fault snapshot data of the target controller from the synchronization response file, and obtain rule information of the fault snapshot data;

[0029] An associated storage module, used to associate the fault snapshot data, the rule information and the target controller and store them in a database;

[0030] The diagnostic module is used to initiate a remote diagnostic request and receive a data response file from the vehicle end for the diagnostic request;

[0031] A vehicle information acquisition module, used to acquire vehicle information from the data response file;

[0032] A controller to be diagnosed determining module, used to determine the controller to be diagnosed according to the vehicle information;

[0033] A matching module, configured to determine a parsing rule of the controller to be diagnosed based on matching the controller to be diagnosed with the database;

[0034] A parsing module is used to read the fault snapshot data from the data response file based on the parsing rule.

[0035] The information reading module is specifically used for:

[0036] Searching for a target suffix file from the synchronization response file; wherein the target suffix file has a controller ID in its file name;

[0037] The fault snapshot data included in the target suffix file is read.

[0038] In a third aspect, a terminal device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the vehicle fault snapshot data parsing method as described above when executing the computer program.

[0039] In a fourth aspect, the present application provides a computer-readable storage medium, wherein the computer-readable storage medium has a computer program, and when the computer program is executed by a processor, the steps of the vehicle fault snapshot data parsing method as described above are implemented.

[0040] The above technical solution of the present application receives the synchronous response file fed back by the vehicle; reads the fault snapshot data and its rule information of the target controller therefrom; and stores it in a database in association with the target controller; initiates a remote diagnosis request, receives the data response file of the vehicle for the diagnosis request; obtains the vehicle information therefrom, determines the controller to be diagnosed according to the vehicle information; determines the parsing rules based on the match with the database, and reads the fault snapshot data from the data response file. By adopting this solution, it helps and guides the developers of automobile enterprises to more intuitively understand the remote diagnosis process based on DOIP, the snapshot data parsing process and principle, reduces the dependence on external suppliers, greatly improves the adaptation efficiency of various models, and improves the efficiency of developers. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Other features, objects and advantages of the present application will become more apparent by reading the detailed description of non-limiting embodiments made with reference to the following drawings:

[0042] Figure 1 It is a flowchart of a vehicle fault snapshot data analysis method provided in Example 1 of the present application;

[0043] Figure 2 This is a schematic diagram of the format of the data response file provided in Example 1 of the present application;

[0044] Figure 3 is a schematic diagram of the UDS data structure provided in Example 1 of the present application;

[0045] Figure 4 This is a schematic diagram of the parsing logic provided in Example 1 of the present application;

[0046] Figure 5 It is a structural schematic diagram of a vehicle fault snapshot data analysis device provided in Example 2 of the present application;

[0047] Figure 6 It is a schematic diagram of the structure of the device provided in Example 3 of the present application. DETAILED DESCRIPTION

[0048] The present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It is to be understood that the specific embodiments described herein are only used to explain the relevant invention, rather than to limit the invention. It is also necessary to explain that, for ease of description, only the parts related to the invention are shown in the accompanying drawings.

[0049] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0050] Example 1

[0051] This embodiment provides a method for analyzing vehicle fault snapshot data. Figure 1 FIG. 1 is a flow chart of the vehicle fault snapshot data analysis method provided in Example 1 of the present application. Figure 1 As shown, the method comprises the following steps:

[0052] S1, sending an information synchronization request of the target controller to the vehicle end, and receiving a synchronization response file fed back by the vehicle end;

[0053] This solution can be executed by the vehicle remote diagnosis server. It can be understood that the server can be connected to the vehicle wirelessly and communicate remotely. Based on this connection, it is possible to send information synchronization requests to the vehicle and receive synchronization response files fed back by the vehicle.

[0054] It can be known that the server here can be operated in the intelligent terminal device to realize the configuration and display of some information.

[0055] It should be noted that the information synchronization request sent to the vehicle side can be for one or more controllers on the vehicle side. As a design, after the information synchronization request is sent to the vehicle side, the information synchronization request of each controller on the vehicle side can be received.

[0056] It can be understood that the information synchronization request can be a request for each controller on the vehicle side to feedback the fault snapshot data corresponding to the controller. For example, 0001 represents the first snapshot data when the fault occurs, and 0002 represents the first snapshot data when the fault occurs. Each snapshot data is equivalent to the status data of the vehicle. The real-time environmental data of the vehicle will be recorded at the moment the fault code occurs to determine what abnormality caused the fault.

[0057] In this solution, the remote diagnosis task needs to be enabled, and the link and routing need to be activated before information can be sent and received between the server and the vehicle.

[0058] To start a remote diagnosis task, you can include the following steps:

[0059] web / event, issue remote diagnosis ( / admin / remote-diagnosis:POST);

[0060] Backend, add remote diagnosis tasks, obtain diagnosis task types, and call remote UDS diagnosis account opening ( / v0 / public / vehicles / remote.instructions);

[0061] Terminal center, Kafka sends the call request;

[0062] adapter, Kafka sends the call;

[0063] Terminal-gateway, mqtt sends the call request;

[0064] Tbox, send response;

[0065] Terminal-gateway, kafka sends a response;

[0066] adapter, call response interface (internal remote-diagnosis / start-stop / response:POST);

[0067] adapter, updates the diagnostic task record status;

[0068] The server sends a diagnostic start command to the Tbox on the vehicle end based on Mqtt, and Tbox responds positively to the cloud, indicating that the diagnostic task is started.

[0069] The process of link building and routing activation is as follows:

[0070] Tbox: TCP / TLS link establishment;

[0071] ng: Kafak sends the link successfully;

[0072] adapter: link established successfully;

[0073] backend: Update the task status to route activation;

[0074] backend: builds a link response and initiates routing activation;

[0075] adapter: kafka sends routing activation;

[0076] ng: initiates routing activation;

[0077] Tbox: Routing activation response;

[0078] ng: kafka routing activation response;

[0079] adapter: route activation response;

[0080] backend: Update the task status to successful routing activation;

[0081] The Tbox on the vehicle side actively initiates a connection, the server side receives the connection, and sends a routing instruction to the vehicle side. After the vehicle side completes the activation, it replies to the server side to complete the activation.

[0082] After completing the link establishment and route activation, you can start the interaction of diagnostic instructions. The specific steps are as follows:

[0083] backend: kafka sends remote diagnosis requests;

[0084] adapter: encapsulates diagnostic request instruction information;

[0085] adapter: Kafka sends remote diagnostic instructions;

[0086] ng: send remote diagnosis request;

[0087] Tbox: respond;

[0088] ng: kafka sends remote diagnostic response;

[0089] adapter: parses remote diagnostic responses;

[0090] adapter: remote diagnosis response interface;

[0091] backend: Update remote diagnosis tasks;

[0092] After successful activation, the server will initiate a UDS command, and the vehicle-side Tbox will report a diagnostic response and a diagnostic response message.

[0093] S2, reading the fault snapshot data of the target controller from the synchronization response file, and obtaining rule information of the fault snapshot data;

[0094] After the synchronization response file is obtained, it can be parsed to read the fault snapshot data of the target controller and obtain the rule information of the fault snapshot data.

[0095] In this embodiment, reading the fault snapshot data of the target controller from the synchronization response file includes:

[0096] Searching for a target suffix file from the synchronization response file; wherein the target suffix file has a controller ID in its file name;

[0097] The fault snapshot data included in the target suffix file is read.

[0098] Combined with the previous introduction, the vehicle side can have many controllers, and the target suffix file can be searched for any of the controllers.

[0099] The target suffix file can be a .odx file, for example, a file named DLC_EV_xxx.odx-d, where xxx represents a controller ID.

[0100] Furthermore, the DTC fault code, DID data identifier (fault snapshot data), and fault snapshot rule information when the DTC fault code occurs can be read in the DLC_EV_xxx.odx-d file.

[0101] The present solution is configured in this way, by clarifying the suffix type of the file where the diagnostic trouble code information is located, the file can be quickly and accurately located, thus providing conditions for efficiently and accurately reading the diagnostic trouble code information.

[0102] On the basis of the above technical solution, the fault snapshot data included in the target suffix file is read, including:

[0103] For the target suffix file, the fault snapshot data is read according to a preset label sequence to obtain all fault snapshot data corresponding to the current controller ID.

[0104] Among them, the fault snapshot data cannot be directly read in the target suffix file. It is necessary to search and read according to the label where the file is written. Therefore, it is necessary to clarify the label order. According to this label order, the diagnostic fault code information can be accurately read.

[0105] This solution can accurately read all fault snapshot data corresponding to the current controller ID by providing a method of reading in label order, and because the synchronous response files of various vehicle ends have the same or similar fault snapshot data writing method, this setting of this solution can have universal characteristics and provide convenience for developers' analysis design.

[0106] On the basis of the above technical solution, the fault snapshot data is read from the target suffix file according to the preset label sequence, including:

[0107] For the target suffix file, the diagnostic fault code information is read in the order of the diagnostic container tag, the controller multi-attribute definition tag, the controller attribute definition tag, the diagnostic data dictionary definition tag, the dictionary table tag, and the dictionary table tag.

[0108] Among them, DLC_EV_AC.odx-d,AC represents the controller. This file contains the snapshot data DID of the current controller.

[0109] In the DLC_EV_xxx.odx-d file, the snapshot data DID (data identifier) ​​needs to be located layer by layer through the tags. The search order is: <diag-layer-container>(Diagnostic Container Label) → <ecu-variants>(Controller multi-attribute definition tag tag) → <ecu-variant>(Controller property definition tag) → <diag-data-dictionary-spec>(Diagnostic Data Dictionary Definition Tag) → <tables>(Dictionary table tag) → SHORT-NAME is "DTCSnapshotRecord_TABLE"

[0110]

[0111]

[0112] Figure 2 Figure 2

[0113]

[0114]

[0115]

[0116]

[0117]

[0118] Figure 3 Figure 3

[0119]

[0120]

[0121]

[0122]

[0123]

[0124]

[0125]

[0126]

[0127]

[0128]

[0129]

[0130]

[0131]

[0132]

[0133]

[0134] <table-row>, get the ID-REF attribute under the element STRUCTURE-REF, and get the hex value of the snapshot data DID.

[0135] Among them, according to the ID-REF of the previous step, <structures>(Structure) element, we can get the read start byte of a single snapshot data DID data (from <byte-positon>Attribute value acquisition), snapshot data reading starting bit (from <bit-position>Attribute value acquisition)) and <dop-ref>Element ID-REF attribute value; BYTE-POSITION and BIT-POSITION are used together and define the starting position of the data, which is used to extract data from the response data stream. It is worth noting that there will be multiple snapshot data DIDs. <param> The tag indicates a sub-did. The starting bit and byte of the sub-did are processed separately. The starting bit of the sub-did of the overall snapshot is calculated according to the first sub-did.

[0136] In one technical solution, after obtaining the starting byte position, the starting bit position and the attribute value of the fault snapshot data, the method further includes:

[0137] Determine a data processing type according to the attribute value; wherein the data processing type includes: no processing, enumeration conversion and linear conversion;

[0138] If it is a linear conversion type, the linear conversion rule is calculated according to the preset method.

[0139] Among them, according to the ID-REF attribute value of DOP-REF in the previous step, <data-object-props>(object data attribute collection) tag node to find the only one <data-object-prop>,exist <data-object-prop>We can get from <data-object-prop>of <compu-method>Down <category>The data processing type is obtained from the element. Common types include IDENTICAL (no processing), TEXTTABLE (enumeration conversion), and LINEAR (linear conversion). The specific calculation rule for LINEAR is: result = (data parsing value + offset) * precision / denominator. In addition, we can obtain the data type of the snapshot data from the DIAG-CODED-TYPE (coded value data type) element and the total bit length of the snapshot data from BIT-LENGTH (response data bit length). These are important bases for whether we can parse the DID response data normally.

[0140] S3, associating the fault snapshot data, the rule information and the target controller and storing them in a database;

[0141] Among them, the Chinese and English names involved in the snapshot did data are all from the Ti.xml file. Finally, the parsed snapshot data did and rule information are persisted, and the corresponding relationship between vehicle models is maintained.

[0142] After the diagnostic trouble code information is obtained, it can be associated with the target controller and stored in a database as a kind of configuration information.

[0143] S4, initiating a remote diagnosis request, and receiving a data response file from the vehicle end for the diagnosis request;

[0144] The remote diagnosis request may be issued by the server, which may be understood as the cloud, that is, the cloud sends the request to the vehicle. Afterwards, the cloud may receive a data response file from the vehicle for the diagnosis request. It is understandable that the data response file may be a data response file generated by the vehicle according to the actual fault.

[0145] For example, the cloud initiates a snapshot read request. After receiving the request, the vehicle obtains snapshot data from each ECU and then returns it to the cloud. The response data is a hexadecimal string in the form of 02FD800100000024030A0E805904C2358709FF06CF008bCF010000CF020000CF0300032FCF05170319CF0601.

[0146] S5, obtaining vehicle information from the data response file;

[0147] Vehicle information can be obtained during DOIP protocol processing, thereby locating the diagnostic configuration information in the database.

[0148] S6, determining a controller to be diagnosed according to the vehicle information;

[0149] Match ECU information according to diagnostic configuration information.

[0150] S7, determining a parsing rule for the controller to be diagnosed based on matching the controller to be diagnosed with the database;

[0151] The obtained ECU information can be used to obtain the parsing rules of the DID in the database. After obtaining the parsing rules, the response data can be parsed accordingly.

[0152] S8. Read fault snapshot data from the data response file based on the parsing rule.

[0153] After the parsing rule is obtained, the fault snapshot data may be read from the data response file according to the obtained parsing rule.

[0154] In this solution, after the fault and the corresponding controller are identified, they can be displayed. The display end can be the server end or the display device end connected to the server end, which can be convenient for developers to view.

[0155] Figure 4 is a schematic diagram of the parsing logic provided in Example 1 of the present application; Figure 4 The core logic of the analysis shown includes the following:

[0156] Filter out the first 8 bytes, which are the message header, and the last four bytes represent the message payload length L, which are saved and the string pointer moves backward 8 bytes

[0157] Filter out the fixed bytes of snapshot data, 4-byte address - ECU address (2 bytes), cloud address (2 bytes); fixed 2 bytes 5904, 59 is the positive response of UDS protocol 19 service, 04 is the sub-service id; 4-byte fault code information - fault code (3 bytes), status bit (1 byte), the string pointer moves back 10 bytes

[0158] The current string pointer starts at the snapshot data's starting position. The first byte is parsed as an int type, representing the snapshot number. The second byte is also parsed as an int, representing the snapshot DID data count. The string pointer moves back 2 bytes.

[0159] The current string pointer starts at the snapshot DID start position. First read 2 bytes of data, namely the snapshot DID, and obtain the rule information corresponding to the DID from the database according to the DID. The DID data is determined according to the start bit and length L1, so the L1 (integer bit length of 8) byte data is the result data of the DID. At the same time, it is converted according to the data type corresponding to the DID (A_INT32, A_UINT32, A_FLOAT32, A_FLOAT64, A_BYTEFIELD, A_ASCIISTRING, etc.). For example, data data = 0x01, the data type is A_INT32, and after conversion, result = 1. Result is not its final physical value yet, and it needs to be processed according to the data processing type (IDENTICAL (no processing), TEXTTABLE (enumeration conversion), LINEAR (linear conversion) to get the final result.

[0160] Here we take LINEAR as an example. Now the precision is 0.1, the offset is 0, the denominator is 1, and the converted result lastResult=(0+1)*0.1 / 1=0.1. At this point, the result of a did is parsed, and the string pointer moves back 2+L1 bytes to read the next did until count; after the did of the current snapshot number is read, the next number DID is read in a loop until the string pointer reaches the L position.

[0161] In this solution, based on the DOIP protocol and combined with ODX data analysis, a fault snapshot data analysis method is provided, and the general processing of the complex part of data analysis is completed, which reduces the development complexity and is easy to apply to the remote diagnosis development of various models, making it truly simple and universal. When developing remote diagnosis of new models, car companies only need to import the vehicle PDX file to complete the snapshot data acquisition, which is convenient for locating and repairing faults.

[0162] The above technical solution of the present application receives the synchronous response file fed back by the vehicle; reads the fault snapshot data and its rule information of the target controller therefrom; and stores it in a database in association with the target controller; initiates a remote diagnosis request, receives the data response file of the vehicle for the diagnosis request; obtains the vehicle information therefrom, determines the controller to be diagnosed according to the vehicle information; determines the parsing rules based on the match with the database, and reads the fault snapshot data from the data response file. By adopting this solution, it helps and guides the developers of automobile enterprises to more intuitively understand the remote diagnosis process based on DOIP, the snapshot data parsing process and principle, reduces the dependence on external suppliers, greatly improves the adaptation efficiency of various models, and improves the efficiency of developers.

[0163] Example 2

[0164] Corresponding to the first embodiment, this embodiment provides a vehicle fault snapshot data analysis device, Figure 5 Schematic diagram of the structure of the vehicle fault snapshot data analysis device provided in Example 2 of the present application. Figure 5 As shown, the device comprises:

[0165] The file receiving module 501 is used to send an information synchronization request of the target controller to the vehicle end, and receive a synchronization response file fed back by the vehicle end;

[0166] An information reading module 502 is used to read the fault snapshot data of the target controller from the synchronization response file, and obtain rule information of the fault snapshot data;

[0167] An associated storage module 503 is used to associate the fault snapshot data, the rule information and the target controller and store them in a database;

[0168] Diagnostic module 504, used to initiate a remote diagnostic request and receive a data response file from the vehicle end for the diagnostic request;

[0169] The vehicle information acquisition module 505 is used to acquire the vehicle information from the data response file;

[0170] A controller to be diagnosed determining module 506, configured to determine a controller to be diagnosed according to the vehicle information;

[0171] A matching module 507, configured to determine a parsing rule of the controller to be diagnosed based on matching the controller to be diagnosed with the database;

[0172] The parsing module 508 is configured to read the fault snapshot data from the data response file based on the parsing rule.

[0173] Optionally, the information reading module 502 is used to:

[0174] Searching for a target suffix file from the synchronization response file; wherein the target suffix file has a controller ID in its file name;

[0175] The fault snapshot data included in the target suffix file is read.

[0176] The above technical solution of the present application receives the synchronous response file fed back by the vehicle; reads the fault snapshot data and its rule information of the target controller therefrom; and stores it in a database in association with the target controller; initiates a remote diagnosis request, receives the data response file of the vehicle for the diagnosis request; obtains the vehicle information therefrom, determines the controller to be diagnosed according to the vehicle information; determines the parsing rules based on the match with the database, and reads the fault snapshot data from the data response file. By adopting this solution, it helps and guides the developers of automobile enterprises to more intuitively understand the remote diagnosis process based on DOIP, the snapshot data parsing process and principle, reduces the dependence on external suppliers, greatly improves the adaptation efficiency of various models, and improves the efficiency of developers.

[0177] The device provided in the embodiment of the present application can implement each process implemented by the above-mentioned method embodiment, and has corresponding functional modules and beneficial effects. To avoid repetition, they will not be described here.

[0178] Example 3

[0179] This embodiment provides a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps of the vehicle fault snapshot data parsing method described in any one of the above items are implemented. Figure 6 Schematic diagram of the structure of the device provided in Example 3 of the present application. Figure 6 As shown, the terminal device 600 is, for example, a computer, and the computer system includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 602 or the program loaded from the storage part to the random access memory (RAM) 603. In the RAM 603, various programs and data required for system operation are also stored. The CPU 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0180] The following components are connected to the I / O interface 605: an input section 606 including a keyboard, a mouse, etc.; an output section 607 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, a modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive is also connected to the I / O interface 605 as needed. A removable medium 611, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 610 as needed, so that a computer program read therefrom is installed into the storage section 608 as needed.

[0181] In particular, according to an embodiment of the present invention, the process of the vehicle fault snapshot data parsing method described in the above embodiment can be implemented as a computer software program. For example, embodiment 1 of the present invention includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program contains program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication part, and / or installed from a removable medium. When the computer program is executed by a central processing unit (CPU) 601, the above-mentioned functions defined in the device of the present application are executed.

[0182] It should be noted that the computer-readable medium shown in the present invention may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present invention, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0183] The flow charts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the apparatus, method and computer program product according to various embodiments of the present invention. In this regard, each box in the flow chart or block diagram can represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of boxes in the block diagram or flow chart, can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0184] The units involved in the embodiments of the present invention may be implemented by software or hardware, and the units described may also be arranged in a processor. The names of these units do not, in some cases, constitute limitations on the units themselves. The units or modules described may also be arranged in a processor, for example, they may be described as: a processor includes a first generation module, an acquisition module, a search module, a second generation module, and a merging module. The names of these units or modules do not, in some cases, constitute limitations on the units or modules themselves, for example, the input module may also be described as "an acquisition module for acquiring multiple instances to be detected in the basic table."

[0185] As another aspect, the present application also provides a computer-readable medium, which may be included in the terminal device described in the above embodiment; or may exist independently without being assembled into the terminal device. The above computer-readable medium carries one or more programs, and when the above one or more programs are executed by a terminal device, the terminal device implements the vehicle fault snapshot data parsing method described in the above embodiment.

[0186] It should be noted that, although several modules or units of the device for action execution are mentioned in the above detailed description, this division is not mandatory. In fact, according to the embodiments of the present disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. On the contrary, the features and functions of one module or unit described above can be further divided into multiple modules or units to be embodied.

[0187] In addition, although the steps of the method in the present disclosure are described in a specific order in the drawings, this does not require or imply that the steps must be performed in this specific order, or that all the steps shown must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps, etc.

[0188] Through the description of the above implementations, those skilled in the art can easily understand that the example implementations described here can be implemented by software, or by combining software with necessary hardware.

[0189] The above description is only a preferred embodiment of the present application and an explanation of the technical principles used. Those skilled in the art should understand that the scope of the invention involved in the present application is not limited to the technical solution formed by a specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the inventive concept. For example, the above features are replaced with (but not limited to) technical features with similar functions disclosed in the present application.< / category> < / structures> (Dictionary table), each TABLE-ROW (row data) under this TABLE contains the fault snapshot data DID under the current controller. After finding all readable fault snapshot data under the current controller, each fault snapshot data can be parsed out. Through such a setting, this solution can accurately parse the fault snapshot data of each controller. It is a format diagram of the data response file provided in Example 1 of the present application; as shown: the DoIP message is contained in the Ethernet message, and the DoIP data is passed down layer by layer as the SDU (Service Data Unit) service data unit, and the DoIP data content can be divided into 5 contents: Protocol Version: the ISO13400 version information used (1 Byte); Inverse Protocol Version: the inverse of the ISO13400 version information used (1 Byte); Data Type: load type (2 Bytes), used to identify the actual purpose of this frame message, such as: requesting vehicle information, diagnostic command, Alive Check, reporting vehicle information, etc.; Data Length: data length (4 Bytes); UDSData: diagnostic data (0-4294967295 Bytes); Contains specific data corresponding to the Data Type: divided into source address, destination address, and application data. This is a schematic diagram of the UDS data structure provided in Example 1 of the present application; as shown, the UDS data structure is as follows: Source address: source address; Target address: target address; ServiceId: service id, 19 is the diagnostic service id; Subfunction: subfunction, 04 fault snapshot; Data: specific content; DTC: fault code; DTCstatus: fault code status; snapshotNumber: snapshot number; number: did data quantity; DID data: did data; DID: data identifier; Value: specific value of data. In this solution, DOIP implementation needs to rely on the import of ODX, PDX, CDD, and COD databases. The PDX file used in this article is briefly introduced below. PDX is a compressed package of ODX files. ODX is an open diagnostic data format used for the interaction of diagnostic data during the life cycle of the vehicle. The ODX database file saves DTC fault codes, DID data identifiers, and fault snapshot rule information when DTC fault codes occur.Based on the above technical solutions, the fault snapshot data of the target controller is read from the synchronization response file, and the rule information of the fault snapshot data is obtained, including: reading the fault snapshot data of the target controller from the synchronization response file, and obtaining the starting byte, starting bit and attribute value of the fault snapshot data. In which, in combination with each TABLE-ROW (row data) under the TABLE introduced above, all are traversed. < / tables>

Claims

1. A vehicle fault snapshot data analysis method, characterized in that: The method comprises: Sending an information synchronization request of a target controller to the vehicle end, and receiving a synchronization response file fed back by the vehicle end; Reading the fault snapshot data of the target controller from the synchronization response file, and obtaining rule information of the fault snapshot data; Associating the fault snapshot data, the rule information and the target controller into a database; Initiate a remote diagnosis request and receive the vehicle-side data response file for the diagnosis request; Acquire vehicle information from the data response file; determining a controller to be diagnosed according to the vehicle information; Determining a parsing rule for the controller to be diagnosed based on matching the controller to be diagnosed with the database; Reading fault snapshot data from the data response file based on the parsing rule; Reading the fault snapshot data of the target controller from the synchronization response file and obtaining rule information of the fault snapshot data includes: Reading the fault snapshot data of the target controller from the synchronization response file, and obtaining the starting byte position, starting bit position and attribute value of the fault snapshot data; After obtaining the starting byte, starting bit and attribute value of the fault snapshot data, the method further includes: Determine a data processing type according to the attribute value; wherein the data processing type includes: no processing, enumeration conversion and linear conversion; If it is a linear conversion type, the linear conversion rule is calculated according to the preset method.

2. The vehicle fault snapshot data analysis method according to claim 1, characterized in that: Reading the fault snapshot data of the target controller from the synchronization response file includes: Searching for a target suffix file from the synchronization response file; wherein the target suffix file has a controller ID in its file name; The fault snapshot data included in the target suffix file is read.

3. The vehicle fault snapshot data analysis method according to claim 2, characterized in that: Reading the fault snapshot data included in the target suffix file includes: For the target suffix file, the fault snapshot data is read according to a preset label sequence to obtain all fault snapshot data corresponding to the current controller ID.

4. The vehicle fault snapshot data analysis method according to claim 3, characterized in that: For the target suffix file, the fault snapshot data is read according to a preset label sequence, including: For the target suffix file, the diagnostic fault code information is read in the order of the diagnostic container tag, the controller multi-attribute definition tag, the controller attribute definition tag, the diagnostic data dictionary definition tag, the dictionary table tag, and the dictionary table tag.

5. A vehicle fault snapshot data analysis device, characterized in that: The device comprises: A file receiving module, used for sending an information synchronization request of a target controller to a vehicle end, and receiving a synchronization response file fed back by the vehicle end; An information reading module, used to read the fault snapshot data of the target controller from the synchronization response file, and obtain rule information of the fault snapshot data; An associated storage module, used to associate the fault snapshot data, the rule information and the target controller and store them in a database; The diagnostic module is used to initiate a remote diagnostic request and receive a data response file from the vehicle side for the diagnostic request; A vehicle information acquisition module, used to acquire vehicle information from the data response file; A controller to be diagnosed determining module, used to determine the controller to be diagnosed according to the vehicle information; A matching module, configured to determine a parsing rule of the controller to be diagnosed based on matching the controller to be diagnosed with the database; A parsing module, configured to read the fault snapshot data from the data response file based on the parsing rule; The information reading module is specifically used to read the fault snapshot data of the target controller from the synchronization response file, and obtain the starting byte position, starting bit position and attribute value of the fault snapshot data; it is also used to determine the data processing type according to the attribute value; wherein the data processing type includes: no processing, enumeration conversion and linear conversion; if it is a linear conversion type, the linear conversion rule is calculated according to a preset method.

6. The vehicle fault snapshot data analysis device according to claim 5, characterized in that: The information reading module is specifically used for: Searching for a target suffix file from the synchronization response file; wherein the target suffix file has a controller ID in its file name; The fault snapshot data included in the target suffix file is read.

7. A terminal device, characterized in that: The terminal device comprises: memory for storing programs; and A processor, configured to execute the vehicle fault snapshot data parsing method as described in any one of claims 1 to 4 by calling the program stored in the memory.

8. A readable storage medium, characterized in that: The readable storage medium stores a program or instruction, and when the program or instruction is executed by the processor, the vehicle fault snapshot data parsing method as described in any one of claims 1-4 is implemented.

Images