JSON-based vehicle diagnosis method and related device

Abstract

The invention provides a JSON-based vehicle diagnosis method and a related device, and the method comprises the steps: obtaining first diagnosis data transmitted by a to-be-diagnosed vehicle ECU, and enabling the to-be-diagnosed vehicle ECU to convert original diagnosis data into diagnosis data in a JSON format according to a diagnosis demand; determining a diagnosis function type of the first diagnosis data to obtain a first diagnosis function type; determining diagnosis parameters corresponding to the first diagnosis function type according to the first diagnosis data to obtain a first diagnosis parameter set; and determining a diagnosis result of the to-be-diagnosed vehicle ECU according to the first diagnosis parameter set. The readability and the diagnosis efficiency of the diagnosis message can be improved in the vehicle diagnosis process.

Description

Technical Field

[0001] The present application relates to the field of vehicle diagnosis technology, and in particular to a JSON-based vehicle diagnosis method and related devices. Background Art

[0002] With the rapid adoption of automobiles, more and more cars are becoming part of people's lives. Cars often require regular maintenance and fault diagnosis. During fault diagnosis, maintenance personnel use diagnostic equipment to detect vehicle faults. Most current diagnostic equipment interacts via diagnostic messages, which are unreadable before parsing. Diagnostic results can only be obtained by parsing, determining, and calculating the corresponding bytes in the message. This results in poor message readability and inconvenient viewing of diagnostic results.

[0003] Therefore, how to improve the readability and diagnostic efficiency of diagnostic messages during vehicle diagnosis needs to be solved urgently. Summary of the Invention

[0004] The embodiments of the present application provide a JSON-based vehicle diagnostic method and related devices, which improve the readability of diagnostic messages and the diagnostic efficiency during the vehicle diagnosis process.

[0005] In a first aspect, an embodiment of the present application provides a JSON-based vehicle diagnostic method, applied to a diagnostic device, the method comprising:

[0006] Acquire first diagnostic data transmitted by the ECU of the vehicle to be diagnosed; the first diagnostic data is converted by the ECU of the vehicle to be diagnosed into diagnostic data in JSON format according to diagnostic requirements;

[0007] determining a diagnostic function type of the first diagnostic data to obtain a first diagnostic function type;

[0008] determining diagnostic parameters corresponding to the first diagnostic function type according to the first diagnostic data to obtain a first diagnostic parameter set;

[0009] A diagnosis result of the vehicle ECU to be diagnosed is determined according to the first diagnostic parameter set.

[0010] In a second aspect, an embodiment of the present application provides a JSON-based vehicle diagnostic method, which is applied to a vehicle ECU to be diagnosed. The method includes:

[0011] Converting the original diagnostic data into first diagnostic data in JSON format according to diagnostic requirements;

[0012] transmitting the first diagnostic data to the diagnostic device, and having the diagnostic device determine a diagnostic function type of the first diagnostic data to obtain a first diagnostic function type;

[0013] determining diagnostic parameters corresponding to the first diagnostic function type according to the first diagnostic data to obtain a first diagnostic parameter set;

[0014] A diagnosis result of the ECU of the vehicle to be diagnosed is determined according to the first diagnostic parameter set.

[0015] In a third aspect, an embodiment of the present application provides a JSON-based vehicle diagnostic device, which is applied to a diagnostic device. The device includes:

[0016] A receiving module is configured to obtain first diagnostic data transmitted by the ECU of the vehicle to be diagnosed; the first diagnostic data is converted by the ECU of the vehicle to be diagnosed into diagnostic data in JSON format according to diagnostic requirements;

[0017] a determining module, configured to determine a diagnostic function type of the first diagnostic data to obtain a first diagnostic function type;

[0018] a determination module, further configured to determine diagnostic parameters corresponding to the first diagnostic function type based on the first diagnostic data, to obtain a first diagnostic parameter set;

[0019] A control module is used to determine a diagnosis result of the vehicle ECU to be diagnosed based on the first diagnostic parameter set.

[0020] In a fourth aspect, an embodiment of the present application provides a JSON-based vehicle diagnostic device, which is applied to a vehicle ECU to be diagnosed, and the device includes:

[0021] A control unit, configured to convert the original diagnostic data into first diagnostic data in JSON format according to diagnostic requirements;

[0022] a sending unit, configured to transmit the first diagnostic data to the diagnostic device, and the diagnostic device determines the diagnostic function type of the first diagnostic data to obtain a first diagnostic function type;

[0023] a determining unit, configured to determine diagnostic parameters corresponding to the first diagnostic function type according to the first diagnostic data, to obtain a first diagnostic parameter set;

[0024] The control unit is further configured to determine a diagnosis result of the ECU of the vehicle to be diagnosed based on the first diagnostic parameter set.

[0025] In a fifth aspect, an embodiment of the present application provides a diagnostic device comprising a processor, a memory, a communication interface, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the processor, and the program comprises instructions for executing the steps of any method of the first aspect of the embodiment of the present application.

[0026] In the sixth aspect, an embodiment of the present application provides a vehicle ECU to be diagnosed, comprising a processor, a memory, a communication interface, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the processor, and the program includes instructions for executing the steps of any method in the second aspect of the embodiment of the present application.

[0027] In the seventh aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the above-mentioned computer-readable storage medium stores a computer program for electronic data exchange, wherein the above-mentioned computer program enables a computer to execute part or all of the steps described in any method of the first aspect of the embodiment of the present application.

[0028] In an eighth aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program for electronic data exchange, wherein the computer program enables a computer to execute part or all of the steps described in any method of the second aspect of the embodiment of the present application.

[0029] In a ninth aspect, embodiments of the present application provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program, wherein the computer program is operable to cause a computer to execute some or all of the steps described in any method of the first aspect of the embodiments of the present application. The computer program product may be a software installation package.

[0030] In a tenth aspect, embodiments of the present application provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program, wherein the computer program is operable to cause a computer to execute some or all of the steps described in any method of the second aspect of the embodiments of the present application. The computer program product may be a software installation package.

[0031] By implementing the embodiments of the present application, the following beneficial effects are achieved:

[0032] This application describes a JSON-based vehicle diagnostic method and related apparatus, applied to a diagnostic device. The method obtains first diagnostic data transmitted by the ECU of a vehicle to be diagnosed. The first diagnostic data is converted from raw diagnostic data into JSON format based on diagnostic requirements by the ECU. Next, the diagnostic function type of the first diagnostic data is determined to obtain a first diagnostic function type. Then, diagnostic parameters corresponding to the first diagnostic function type are determined based on the first diagnostic data to obtain a first diagnostic parameter set. Finally, a diagnostic result for the ECU of the vehicle to be diagnosed is determined based on the first diagnostic parameter set. This method, on the one hand, replaces the byte message transmission used in traditional vehicle diagnostics by using the JSON format. JSON uses a key-value pair format, with multiple key-value pairs added to distinguish different information. The key describes the meaning of a data item, and the value is the value of that item. This makes the diagnostic message directly readable in the diagnostic exchange, resulting in clearer and more concise results, thereby improving the readability of the diagnostic message. Furthermore, the JSON-formatted diagnostic message directly transmits the parameters returned by the ECU of the vehicle to be diagnosed, eliminating the need for parsing the data exchanged between the diagnostic device and the vehicle ECU, thereby improving diagnostic efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the description of the embodiments. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0034] Figure 1 This is an architectural diagram of a JSON-based vehicle diagnostic system provided in an embodiment of the present application;

[0035] Figure 2 is a schematic structural diagram of a diagnostic device provided in an embodiment of the present application;

[0036] Figure 3 This is a schematic diagram of the structure of a vehicle ECU to be diagnosed provided in an embodiment of the present application;

[0037] Figure 4 This is a flow chart of a JSON-based vehicle diagnostic method provided in an embodiment of the present application;

[0038] Figure 5 This is a flow chart of another JSON-based vehicle diagnostic method provided in an embodiment of the present application;

[0039] Figure 6 This is a timing diagram of a JSON-based vehicle diagnostic method provided in an embodiment of the present application;

[0040] Figure 7 This is a block diagram of the functional modules of a JSON-based vehicle diagnostic device provided in an embodiment of the present application;

[0041] Figure 8 This is a block diagram of the functional modules of another JSON-based vehicle diagnostic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0042] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0043] The terms "first," "second," and the like in the specification and claims of this application and the accompanying drawings are used to distinguish between different objects, not to describe a particular order. Furthermore, the terms "including," "having," and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or elements is not limited to the listed steps or elements but may optionally include steps or elements not listed, or may optionally include other steps or elements inherent to the process, method, product, or apparatus.

[0044] It should be understood that the term "and / or" in this document is merely a description of the association relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character " / " in this document indicates that the associated objects are in an "or" relationship. The "plurality" appearing in the embodiments of this application refers to two or more.

[0045] In the embodiments of the present application, "at least one item" or similar expressions refers to any combination of these items, including any combination of single items or plural items, and refers to one or more, and multiple refers to two or more. For example, at least one item (item) of a, b, or c can represent the following seven situations: a, b, c, a and b, a and c, b and c, a, b, and c. Among them, each of a, b, and c can be an element or a set containing one or more elements.

[0046] The "connection" appearing in the embodiments of the present application refers to various connection methods such as direct connection or indirect connection to achieve communication between devices, and the embodiments of the present application do not impose any limitations on this.

[0047] References herein to "embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute an independent or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0048] The following are the explanations of the relevant terms involved in this application:

[0049] JSON (JavaScript Object Notation) is a lightweight data exchange format whose core purpose is to provide a standard for transferring structured data between different systems. It stores data as key-value pairs and supports nested objects and arrays. It is suitable for network transmission (such as API interfaces), configuration files (such as software parameters), and persistent data storage. It is defined based on a subset of JavaScript and is programming language-agnostic, meaning it can be used in any programming language. JSON is easy for programmers to read and write.

[0050] Currently, vehicle diagnostics are mostly conducted through diagnostic messages. These messages are formatted as bytes, and both parties interpret them based on the meaning of the bytes. Consequently, the exchanged data must be parsed and calculated before the final result can be viewed. This results in poor readability, requiring data parsing and calculation each time. This limits the readability of diagnostic messages during the vehicle diagnostic process, hindering diagnostic efficiency.

[0051] To address the above-mentioned issues, an embodiment of the present application provides a JSON-based vehicle diagnostic method and related apparatus, which are applied to diagnostic equipment. The method obtains first diagnostic data transmitted by the ECU of the vehicle to be diagnosed, wherein the first diagnostic data is converted by the ECU of the vehicle to be diagnosed into diagnostic data in JSON format based on diagnostic requirements. Next, the diagnostic function type of the first diagnostic data is determined to obtain the first diagnostic function type. Then, the diagnostic parameters corresponding to the first diagnostic function type are determined based on the first diagnostic data to obtain a first diagnostic parameter set. Finally, the diagnostic result of the ECU of the vehicle to be diagnosed is determined based on the first diagnostic parameter set. This improves the readability of diagnostic messages and the efficiency of diagnosis during vehicle diagnosis.

[0052] The following combination Figure 1 The architecture of a vehicle diagnostic system based on JSON in an embodiment of the present application is described. Figure 11 is an architecture diagram of a JSON-based vehicle diagnostic system provided in an embodiment of the present application. The JSON-based vehicle diagnostic system 100 includes a vehicle ECU 110 to be diagnosed and a diagnostic device 120 .

[0053] The vehicle ECU 110 to be diagnosed is used to communicate with the diagnostic device 120 via the on-board diagnostic system (OBD) interface to achieve the collection, storage and diagnostic response of vehicle status data. As the core of the vehicle's electronic control system, the vehicle ECU 110 to be diagnosed integrates multiple subsystem control units and can detect the operating status of key components such as the engine, transmission, and braking system in real time. When an abnormality occurs in the vehicle, the vehicle ECU 110 to be diagnosed can automatically detect the fault based on the built-in diagnostic algorithm and generate a corresponding fault code stored in the non-volatile memory. The fault code includes: fault type, location, and severity. In addition, the vehicle ECU 110 to be diagnosed is also responsible for collecting and storing the vehicle's real-time operating data, including dynamic parameters such as engine speed, coolant temperature, and intake pressure. This data can be read in real time through active requests from the diagnostic device 120 and used to evaluate vehicle performance or assist in fault diagnosis. For example, when the diagnostic device requests to read the data stream, the ECU 110 of the vehicle to be diagnosed organizes the current sensor data according to the JSON format specification and generates a data set containing parameter names, values, units and other information to ensure that the diagnostic device can accurately parse and display it.

[0054] In one possible embodiment, the ECU 110 of the vehicle to be diagnosed stores various operating data during the operation of the vehicle and diagnoses the vehicle's diagnostic function items. When receiving a diagnostic request sent by the diagnostic device 120 via a JSON format diagnostic message, the ECU 110 of the vehicle to be diagnosed will check and analyze the vehicle's related functions based on its own built-in diagnostic logic and data, such as detecting whether there is a fault in the engine control system, whether the various sensor data are normal, etc. After the diagnosis is completed, the diagnostic data items are sorted and returned according to the requirements of the JSON format diagnostic message. For example, if a vehicle fails, the ECU 110 of the vehicle to be diagnosed will record fault-related information, including the fault code, the time when the fault occurred, the fault status, etc. When the diagnostic device 120 requests to obtain fault information, the ECU 110 of the vehicle to be diagnosed will return this information in a form that complies with the JSON format, which is convenient for the diagnostic device to parse and process.

[0055] The diagnostic device 120 is used to send diagnostic requests to the ECU 110 of the vehicle to be diagnosed, and to receive, parse, and display diagnostic data returned by the ECU 110. Based on the operator's needs, the diagnostic device 120 generates a corresponding diagnostic request and sends it to the ECU 110 of the vehicle to be diagnosed via a JSON-formatted diagnostic message. After receiving the JSON-formatted diagnostic data returned by the ECU 110, the diagnostic device 120 parses it and presents the diagnostic information to the operator in an intuitive manner, such as by displaying fault codes, fault descriptions, and data values, to help the operator understand the vehicle's condition.

[0056] In one possible embodiment, the diagnostic device 120 can be configured with different diagnostic function types, such as reading fault codes, reading data items, and clearing fault codes. When the operator selects the read fault code function, the diagnostic device 120 generates a corresponding diagnostic request and sends it to the ECU 110 of the vehicle to be diagnosed via a JSON-formatted diagnostic message. The diagnostic device 120 then receives and parses the fault code-related data returned by the ECU 110 of the vehicle to be diagnosed and displays it to the operator.

[0057] As can be seen, the JSON-formatted diagnostic message plays a key role in information transmission between the vehicle ECU 110 and the diagnostic device 120, ensuring accurate and efficient data exchange between the two parties. Furthermore, the standardization and universality of the JSON format can improve diagnostic efficiency and enhance the readability of diagnostic information during the diagnostic process.

[0058] The following combination Figure 2 The diagnostic device in the embodiment of the present application is described. Figure 2 A schematic diagram of the structure of a diagnostic device provided in an embodiment of the present application is shown in FIG. Figure 2 As shown, the diagnostic device 200 includes one or more processors 210 , a memory 220 , a communication interface 230 , and one or more programs 221 . The processor 210 is communicatively connected to the memory 220 and the communication interface 230 via an internal communication bus.

[0059] The processor 210 is mainly used for:

[0060] Acquire first diagnostic data transmitted by the ECU of the vehicle to be diagnosed; the first diagnostic data is converted by the ECU of the vehicle to be diagnosed into diagnostic data in JSON format according to diagnostic requirements;

[0061] determining a diagnostic function type of the first diagnostic data to obtain a first diagnostic function type;

[0062] determining diagnostic parameters corresponding to the first diagnostic function type according to the first diagnostic data to obtain a first diagnostic parameter set;

[0063] A diagnosis result of the vehicle ECU to be diagnosed is determined according to the first diagnostic parameter set.

[0064] The one or more programs 221 are stored in the memory 220 and configured to be executed by the processor 210 . The one or more programs include instructions for executing any step in the following embodiment of the JSON-based vehicle diagnostic method.

[0065] Among them, the processor 210 can be a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. It can implement or execute the various exemplary logic blocks, units and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, and the like. The communication unit can be a communication interface, a transceiver, a transceiver circuit, etc., and the storage unit can be a memory.

[0066] The memory 220 may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. The non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link DRAM (SLDRAM), and direct RAM bus RAM (DR RAM).

[0067] It is understandable that the diagnostic device 200 may include more or fewer structural elements than those in the above structural block diagram, for example, a power module, physical buttons, a Wi-Fi module, a speaker, a Bluetooth module, a sensor, a display module, etc., which are not limited here.

[0068] For the same example as above, please refer to Figure 3 , Figure 3 This is a schematic diagram of the structure of a vehicle ECU to be diagnosed provided by an embodiment of the present application. Figure 3 As shown, the vehicle ECU 300 to be diagnosed includes one or more processors 310 , a memory 320 , a communication interface 330 and one or more programs 321 . The processor 310 is in communication connection with the memory 320 and the communication interface 330 via an internal communication bus.

[0069] The processor 310 is mainly used for:

[0070] Converting the original diagnostic data into first diagnostic data in JSON format according to diagnostic requirements;

[0071] transmitting the first diagnostic data to the diagnostic device, and having the diagnostic device determine a diagnostic function type of the first diagnostic data to obtain a first diagnostic function type;

[0072] determining diagnostic parameters corresponding to the first diagnostic function type according to the first diagnostic data to obtain a first diagnostic parameter set;

[0073] A diagnosis result of the ECU of the vehicle to be diagnosed is determined according to the first diagnostic parameter set.

[0074] The one or more programs 321 are stored in the memory 320 and configured to be executed by the processor 310 . The one or more programs include instructions for executing any step in the following embodiment of the JSON-based vehicle diagnostic method.

[0075] Among them, the processor 310 can be a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. It can implement or execute the various exemplary logic blocks, units and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, and the like. The communication unit can be a communication interface, a transceiver, a transceiver circuit, etc., and the storage unit can be a memory.

[0076] The memory 320 may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. The non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link DRAM (SLDRAM), and direct RAM bus RAM (DR RAM).

[0077] It is understandable that the vehicle ECU 300 to be diagnosed may include more or fewer structural elements than those in the above structural block diagram, for example, a power module, physical buttons, a communication module, etc., which are not limited here.

[0078] After understanding the software and hardware architecture of this application, Figure 4 A JSON-based vehicle diagnostic method in an embodiment of the present application is described. Figure 4 This is a flow chart of a JSON-based vehicle diagnostic method provided in an embodiment of the present application. The method is applied to a diagnostic device and specifically includes the following steps:

[0079] Step S410 , obtaining first diagnostic data transmitted by the ECU of the vehicle to be diagnosed; the first diagnostic data is converted by the ECU of the vehicle to be diagnosed into diagnostic data in JSON format according to diagnostic requirements by converting original diagnostic data.

[0080] Diagnostic requirements can include reading fault codes, reading data streams, clearing fault codes, or writing configuration codes, among other diagnostic operations, without limitation. Upon receiving a diagnostic request from the diagnostic device, the ECU of the vehicle to be diagnosed parses the request to determine the specific diagnostic function requirements. It then extracts, organizes, and converts the raw diagnostic data stored internally into diagnostic data that conforms to the JSON specification.

[0081] Raw diagnostic data is stored in the vehicle's ECU in byte form. This byte data is associated with the operating status and parameter information of various vehicle components. For example, data such as engine speed, coolant temperature, and vehicle speed are each represented by a specific byte or byte combination. During the conversion process, the ECU extracts and interprets the raw byte data based on the requirements of different diagnostic functions. For example, when reading fault codes, the ECU reads the corresponding byte data from the fault code storage area, converts it into a readable fault code and fault description, and presents it as a key-value pair in JSON format. For example, "DtcCode" as a key corresponds to a specific fault code value; "DtcText" as a key corresponds to a detailed fault description.

[0082] Specifically, when the ECU receives a request from the diagnostic device to read the vehicle engine coolant temperature, the request is presented in JSON format, including key information such as "kind" as "request", "function" as "readDataStream", and "item" as "coolantTemperature". After receiving the request, the ECU first parses the JSON data to identify the "readDataStream" function and the "coolantTemperature" data item requirements. Next, the ECU obtains the raw byte data corresponding to the coolant temperature from the internally stored sensor data area. The raw byte data is parsed into a decimal value of 85 (unit is ℃). Subsequently, the ECU constructs response data in JSON format, sets "kind" to "answer", "function" to "readDataStream", and the "result" array contains an object with "item" as "coolantTemperature", "value" as "85", and "unit" as "℃". That is, the first diagnostic data finally generated is:

[0083]

[0084] It's important to note that when converting raw diagnostic data into JSON format, the ECU must ensure data accuracy and integrity. To ensure data accuracy, the ECU verifies the raw byte data. If verification fails, it generates an error message and returns it to the diagnostic device in JSON format, allowing the device to promptly identify any data anomalies. Regarding data integrity, for complex diagnostic data, such as data stream read requests containing multiple data items, the ECU strictly adheres to JSON's array and nested object structure specifications, organizing all relevant data completely within a single JSON data block to prevent data loss or omission.

[0085] Step S420: Determine the diagnostic function type of the first diagnostic data to obtain a first diagnostic function type.

[0086] Determining the first diagnostic function type primarily relies on parsing and identifying specific key values ​​in the JSON data. In the JSON data structure, the "function" key is the primary identifier, and its corresponding value can be used to identify the specific type of the diagnostic function.

[0087] Specifically, upon receiving the first diagnostic data from the vehicle's ECU, the diagnostic device first parses it. For example, if the first diagnostic data is {"kind":"answer","function":"readDtc","DtcCode":"P0301","DtcText":"Cylinder 1 Misfire"}, the diagnostic device uses JSON parsing rules and reads the corresponding value "readDtc" under the "function" key. By identifying this value, the diagnostic device determines that the diagnostic function type corresponding to this diagnostic data is read fault codes.

[0088] It's important to note that when determining the first diagnostic function type, the diagnostic device must strictly adhere to JSON data parsing standards to ensure accurate reading and identification of the "function" key value. If there are errors in the JSON data format, such as a missing "function" key or its corresponding value not matching the predefined diagnostic function type identifier, the diagnostic device should promptly display an error message. This prevents misjudgments of diagnostic functions due to data formatting issues and ensures the accuracy and reliability of the vehicle diagnostic process.

[0089] In a possible embodiment, determining the diagnostic function type of the first diagnostic data to obtain the first diagnostic function type specifically includes the following steps:

[0090] 421. Analyze the first diagnostic data to obtain second diagnostic data.

[0091] 422. Determine the diagnostic function data in the second diagnostic data based on a preset diagnostic function identifier to obtain first diagnostic function data;

[0092] 423. Classify the first diagnostic function data according to a preset classification rule to obtain the first diagnostic function type.

[0093] The first diagnostic data is presented in JSON format, and its communication follows the transmission specifications of the KWP2000 protocol. During the parsing process, key information fields need to be extracted in sequence based on the hierarchical structure of the JSON data. In vehicle diagnostic communication scenarios, the first diagnostic data typically contains response information to the diagnostic request, such as the diagnostic service ID, parameter values, status code, etc. During parsing, the integrity of the JSON data is first verified to check whether it contains required key-value pairs such as "kind", "function", and "result". If the data is incomplete, the error handling mechanism will be triggered, an error code will be generated, and the parsing process will be terminated.

[0094] Among them, the preset diagnostic function identifier is a set of predefined mapping relationships that correspond the diagnostic service ID to the specific diagnostic function type. These identifiers are based on the provisions of the ISO14229 standard and the KWP2000 protocol, covering common diagnostic functions such as reading fault codes (0x19), clearing fault codes (0x14), reading data items (0x22), and writing configuration codes (0x2E). When determining the diagnostic function data, the diagnostic service ID must be extracted from the second diagnostic data and matched with the preset identifier. The diagnostic service ID is usually located in a specific position in the JSON data. For example, in some implementations, the service ID may be nested in an object in the "result" array. By traversing the "result" array, find the object containing the service ID and extract its value.

[0095] Pre-set classification rules categorize diagnostic data into different types based on the business logic and technical characteristics of diagnostic functions. These classification rules consider multiple dimensions, such as data flow direction (read / write operations), operation targets (fault codes / data flows / configuration parameters), and security levels (normal operations / secure access). By comprehensively analyzing these dimensions, accurate classification of diagnostic functions is achieved.

[0096] Specifically, the classification process utilizes machine learning methods, such as random forest algorithms or decision tree algorithms (not specifically defined here), to gradually determine the type of the first diagnostic function data based on its characteristics. For example, the data flow direction is first determined: if the service ID corresponds to a read operation (such as 0x19 or 0x22), the operation object is further determined. If it is a write operation (such as 0x2E), it is classified as a configuration function. For a read operation, if the service ID is 0x19, it is directly classified as "Read DTC." The classification rules can be customized based on the specific vehicle model and diagnostic requirements. For example, some vehicles may have unique diagnostic service IDs, requiring corresponding mappings to be added to the classification rules. After classification, a clear identifier for the first diagnostic function type is generated, such as "READ_DTC," "CLEAR_DTC," or "READ_DATA_STREAM," for subsequent diagnostic process control and result display.

[0097] In a possible embodiment, parsing the first diagnostic data to obtain the second diagnostic data specifically includes the following steps:

[0098] 4211. Segment the first diagnostic data according to the JSON structure to obtain a first segmented set; the first segmented set includes multiple relatively independent data blocks;

[0099] 4212. Perform semantic analysis on the first diagnostic data to obtain a first semantic analysis result.

[0100] 4213. Perform key-value pair identification on the first segmentation set according to the first semantic analysis result to obtain a second key-value pair set;

[0101] 4214. Parse the second key-value pair set based on a preset JSON format parsing rule to obtain the second diagnostic data.

[0102] Among them, the first diagnostic data is presented in JSON format, and its structure contains nested key-value pairs and arrays. The grammatical segmentation process is based on the grammatical rules of JSON and uses a recursive descent analysis method to decompose the complete JSON text into multiple relatively independent data blocks. First, the parser first identifies the outermost structure of the JSON text and determines whether it is an object ({}) or an array ([]). For object structures, each key-value pair is separated by a comma; for array structures, each element is separated by a comma. When processing nested structures, the parser will recursively perform the same segmentation operation on each sub-object or sub-array.

[0103] Semantic analysis interprets the meaning of each key-value pair in the JSON data. This process focuses not only on the syntactic structure of the data but, more importantly, on understanding the actual diagnostic significance represented by the data. The semantic analyzer maintains a predefined dictionary containing various diagnostic service IDs and parameter IDs defined in the protocol, along with their corresponding semantic descriptions. During analysis, the parser first identifies key semantic identifiers in the JSON data, such as the value corresponding to the "function" key, to determine the type of diagnostic operation being performed. For example, if "function": "readDataStream" is detected, its semantics are marked as a "data stream read operation." For each element in the "result" array, the parser further analyzes the key-value pairs within it. For example, the value corresponding to the "item" key represents the specific diagnostic parameter name, and the value corresponding to the "value" key represents the actual measured value of that parameter. Semantic analysis also includes validation of data types and value ranges. For example, for the engine speed parameter, the parser verifies that its value is a valid numeric type and within a reasonable range (e.g., 0-10,000 rpm). If an abnormal value is detected, the parser will log a warning message to provide reference for subsequent data processing. The key-value pair identification process extracts key-value pairs with practical diagnostic significance from the first segmentation set based on the semantic analysis results. This process needs to resolve the nested structures and complex mapping relationships that may exist in JSON data to ensure that each key-value pair can be accurately identified and classified.

[0104] Specifically, each data block in the first segmented set is first traversed and, based on the semantic analysis results, is determined to be a valid key-value pair. For nested structures, each sub-data block is recursively processed to extract the key-value pairs within. During the recognition process, particular attention is paid to key parameters. For example, when reading a fault code, key-value pairs such as the fault code number (e.g., "DtcCode":"P0123") and the fault description (e.g., "DtcText":"Throttle Position Sensor Circuit Voltage High") are specifically extracted. This method converts the raw JSON data into a structured set of key-value pairs, facilitating subsequent parsing and processing. Next, each value in the second set of key-value pairs is type-converted. For example, a string value (e.g., "1500") is converted to an integer, and a hexadecimal string (e.g., "0xFF") is converted to its corresponding numeric value. For parameters containing units, the parser performs unit conversion, standardizing data in different units to standard units. The validity and integrity of each parameter are then verified. For example, required parameters are checked for presence and values ​​within a reasonable range. If illegal data is found, it will be processed according to the preset strategy, such as ignoring invalid data, recording error logs, or returning error codes.

[0105] Step S430 : determining diagnostic parameters corresponding to the first diagnostic function type according to the first diagnostic data to obtain a first diagnostic parameter set.

[0106] Among them, diagnostic parameters are key data that reflect the operating status of various systems and components of the vehicle, and are also the core of the accurate execution and analysis of diagnostic operations. The parameters exist in the first diagnostic data in the form of key-value pairs. The key names follow specific naming conventions and intuitively reflect the meaning of the parameters; the values ​​are the actual parameter data, which may be numeric values, strings, or other data types.

[0107] Specifically, when the first diagnostic function type is to read fault codes, the portion of the first diagnostic data related to the fault code is first parsed. In a JSON data structure, there are usually dedicated fields for storing fault code information, such as "DtcCode" for the fault code number, "DtcText" for the fault code description, and "DtcStatus" for the fault code status (such as current existence, historical existence, etc.).

[0108] In a possible embodiment, before determining the diagnostic parameters corresponding to the first diagnostic function type according to the first diagnostic data to obtain the first diagnostic parameter set, the following steps are specifically included:

[0109] 431. Construct string data in JSON format according to the first diagnostic function type to obtain first string data, and send the first string data to the ECU of the vehicle to be diagnosed;

[0110] 432. Receive a diagnostic response from the ECU of the vehicle to be diagnosed in response to the first character string data, and obtain a diagnostic parameter identification set of the ECU of the vehicle to be diagnosed;

[0111] 433. Determining the diagnostic parameters corresponding to the first diagnostic function type according to the first diagnostic data to obtain a first diagnostic parameter set specifically includes the following steps:

[0112] 4331. Determine the diagnostic parameters corresponding to the first diagnostic function type based on the first diagnostic data and the diagnostic parameter identification set to obtain the first diagnostic parameter set.

[0113] The JSON data contains key information such as the diagnostic service ID and parameter ID to identify the specific diagnostic function performed by the ECU. For example, when the first diagnostic function type is to read fault codes, the constructed JSON string data may be as follows:

[0114]

[0115] "function":"readDtc" specifies the diagnostic function type, while "dtcFormatIdentifier" and "dtcStatusMask" are the parameters required to read fault codes. Once constructed, this JSON string is sent via the K-line to the ECU of the vehicle being diagnosed.

[0116] Among them, after receiving the diagnostic request, the ECU will perform the corresponding diagnostic operation according to the request content and return a reply containing the diagnostic parameter identification. The diagnostic parameter identification set is a set of information used to identify the diagnostic parameters, usually including parameter ID, parameter name, data type, etc. These identification information are crucial for the subsequent accurate parsing of the diagnostic parameters. The diagnostic response of the ECU is also presented in JSON format. When processing the first diagnostic data, first search for the corresponding key-value pair in the first diagnostic data based on the parameter ID or name in the diagnostic parameter identification set. For example, in the above-mentioned reply to reading the fault code, according to the diagnostic parameter identification set dtcId, dtcDescription, and dtcStatus, the specific information of each fault code is extracted from the dtcList array to form the first diagnostic parameter set.

[0117] Step S440: determining a diagnosis result of the vehicle ECU to be diagnosed according to the first diagnostic parameter set.

[0118] The first diagnostic parameter set includes various diagnostic parameters obtained from the vehicle's ECU. These parameters are key to assessing the vehicle's condition. Determining the diagnostic result requires comprehensive analysis of all data in the parameter set and comparison with pre-set standard parameter ranges and a fault signature library. The diagnostic result can be presented in the form of a fault code, fault description, or performance evaluation indicator, though this is not limited here. This diagnostic result provides direct guidance for vehicle maintenance.

[0119] The preset standard parameter ranges are parameter thresholds set based on vehicle design specifications and normal operating conditions, used to determine whether parameters are within the normal range. For example, the normal range for engine coolant temperature is typically 60°C-105°C. If the coolant temperature in the parameter set falls outside this range, it may indicate a cooling system fault. The fault signature library stores characteristic patterns of various known faults. By comparing the parameter set with the fault signature library, potential faults can be quickly located.

[0120] Specifically, when the first diagnostic parameter set corresponds to the Read DTC function, the system first analyzes the DTC information within the parameter set. For example, if the parameter set contains the DTC "P0171," the system searches the fault signature database for the corresponding fault description (e.g., "System Lean (Cylinder Bank 1)") and performs a comprehensive analysis based on other relevant parameters. If the oxygen sensor data indicates a positive long-term fuel correction value (e.g., +15%), exceeding the normal range (typically ±10%), this further confirms the System Lean fault diagnosis. If the first diagnostic parameter set corresponds to the Read Data Item function, the system compares each parameter value against the standard range. For example, if the engine speed in the parameter set is 1200 rpm at idle, while the standard idle range is 750-900 rpm, the idle speed is considered too high. The system then further checks the parameters of related components, such as the throttle position sensor and idle speed control valve, to determine the root cause of the fault. For the Write Configuration Code function, the diagnostic results primarily focus on whether the configuration code was successfully written and the system feedback after the write. The system checks the write status code (such as "success" or "failure") in the parameter set and verifies that the relevant configuration parameters have been updated to the expected values. If the write fails, the system analyzes the error code (such as "Insufficient Permissions" or "Parameter Format Error") and generates corresponding troubleshooting suggestions.

[0121] In a possible embodiment, determining the diagnostic result of the vehicle ECU to be diagnosed according to the first diagnostic parameter set specifically includes the following steps:

[0122] 441. Classify each diagnostic parameter in the first diagnostic parameter set to obtain a first classified parameter set;

[0123] 442. Obtain a threshold value corresponding to each category parameter in the first classification parameter set to obtain a first threshold value set;

[0124] 443. Compare the first classification parameter set with each category parameter corresponding to the first threshold set to obtain a first comparison result set;

[0125] 444. Determine a diagnosis result of the ECU of the vehicle to be diagnosed based on a preset mapping rule and the first comparison result set.

[0126] The classification process categorizes parameters into different categories based on their business logic and technical characteristics. For example, engine-related parameters can be categorized into power performance (e.g., engine speed, torque), temperature (e.g., coolant temperature, oil temperature), and pressure (e.g., fuel pressure, oil pressure); chassis-related parameters can be categorized into braking system and suspension system categories. This classification transforms the original parameter set into a structured, categorized parameter set, facilitating subsequent threshold comparison and result analysis. The thresholds corresponding to each category are reference ranges set based on vehicle design standards, industry specifications, and actual usage experience. These thresholds typically include the boundaries of normal, warning, and fault ranges. There are two main methods for acquiring thresholds: static configuration and dynamic learning. Static configuration involves loading preset standard thresholds into memory during system initialization. Dynamic learning involves the system adaptively adjusting thresholds based on the vehicle's historical operating data and operating environment. For example, for certain parameters (e.g., battery voltage), the system dynamically adjusts the threshold range based on vehicle age and ambient temperature. The comparison process compares the actual value of each categorized parameter against the corresponding threshold to determine the state range in which the parameter value falls.

[0127] Based on expert fault diagnosis knowledge and machine learning algorithms, the system comprehensively considers abnormalities in multiple parameters to infer possible fault causes and solutions. Specifically, mapping rules are implemented using a combination of decision trees and a rule engine. For complex faults, the mapping rules consider the temporal and causal relationships between parameters to improve diagnostic accuracy. Mapping rules are continuously updated and optimized to adapt to new vehicle models and fault modes.

[0128] For the same example as above, please refer to Figure 5 , Figure 5 This is a flowchart of another JSON-based vehicle diagnostic method provided in an embodiment of the present application. The method is applied to the ECU of a vehicle to be diagnosed and specifically includes the following steps:

[0129] Step S510 : Converting the original diagnostic data into first diagnostic data in JSON format according to diagnostic requirements.

[0130] Raw diagnostic data refers to the underlying data stored within the vehicle's ECU. It typically exists in binary or byte stream form and adheres to specific communication protocols (such as KWP2000 and ISO14229). The conversion process parses this raw data based on diagnostic requirements and reconstructs it into structured data that conforms to the JSON format. The diagnostic requirements determine which raw data to extract and how to organize it, such as reading fault codes, data streams, or performing special functional tests.

[0131] The JSON format offers excellent readability and scalability, making it suitable for transmission and parsing across different systems. The conversion process must ensure the semantic integrity of the original data while adhering to the predefined JSON data schema, which defines the data's hierarchical structure, field naming conventions, and data type mappings. For example, this schema converts raw byte data into human-readable strings or numeric values.

[0132] Specifically, when the diagnostic requirement is to read fault codes, the raw diagnostic data returned by the ECU may contain multiple fault code records, each of which consists of a status byte, a fault code number, and additional information. The conversion process first parses the status byte to determine the fault type (such as current fault or historical fault), then converts the fault code number into a standard format, and extracts additional information (such as the number of fault occurrences or freeze frame data). The following example illustrates this: if the diagnostic requirement is to write a configuration code, the conversion process needs to encapsulate the configuration parameters entered by the user into request data in JSON format. For example, to set the communication baud rate of the ECU:

[0133]

[0134] In a possible embodiment, converting the original diagnostic data into first diagnostic data in JSON format according to the diagnostic requirements specifically includes the following steps:

[0135] 511. Determine a diagnostic operation type according to the diagnostic requirement to obtain a first diagnostic operation type; the first diagnostic operation type includes at least one of: reading a fault code, clearing a fault code, reading a data item, and writing a configuration code;

[0136] 512. Obtain diagnostic data corresponding to the first diagnostic operation type according to the original diagnostic data to obtain first diagnostic operation type data;

[0137] 513. Construct data for the first diagnostic operation type and the first diagnostic operation type data according to a preset JSON format construction rule to obtain first diagnostic data.

[0138] Diagnostic requirements are typically presented in the form of standardized diagnostic requests, including key identifying information such as function codes or service IDs. When determining the first diagnostic operation type, the system first parses the function code in the diagnostic requirement and maps it to a predefined set of operation types. Pre-defined JSON format construction rules define how to organize diagnostic operation types and corresponding diagnostic data into structured data that conforms to the JSON specification. These rules ensure that the generated JSON data has a uniform format, facilitating subsequent parsing and processing.

[0139] Specifically, the construction process first determines the top-level structure of the JSON data, which usually includes fields such as "kind" (identifying the message type, such as "answer" for a response message), "function" (identifying the diagnostic function type, such as "readDtc"), and "result" (containing specific diagnostic data). First, the data is type-converted and format-checked to ensure that the generated JSON data complies with the specifications. For example, convert numerical data into string format, add unit information to each data item, and add necessary description fields for complex data structures. In addition, for some special cases (such as missing or incorrect data), the system will add corresponding error identifiers and prompt information to the JSON data according to preset rules for subsequent processing.

[0140] In a possible embodiment, constructing the first diagnostic operation type and the first diagnostic operation type data according to a preset JSON format construction rule to obtain the first diagnostic data specifically includes the following steps:

[0141] S131. Determine a JSON diagnostic operation key set corresponding to the first diagnostic operation type to obtain a first diagnostic key set.

[0142] S132. Determine data corresponding to each key in the first diagnosis key set based on the first operation type data to obtain a first diagnosis value set;

[0143] S133. Match each key in the first diagnostic key set with the corresponding value in the first diagnostic value set to obtain a first key-value pair set;

[0144] S134. Encapsulate the first key-value pair set according to the JSON format construction rules to obtain the first diagnostic data.

[0145] Among them, the key set of the JSON diagnostic operation is a predefined set of key names used to identify each field in the JSON data structure. The process of determining the first diagnostic key set is to search for the corresponding key name set from the preset mapping table based on the first diagnostic operation type. For example, when the first diagnostic operation type is "read fault code", the corresponding first diagnostic key set may include: "kind", "function", "dtcList", "dtcCode", "dtcStatus", "occurrenceCount", etc. These key names define the name and meaning of each data item in the JSON data. For example, "dtcList" represents the fault code list, and "dtcCode" represents the specific fault code number. Among them, the first operation type data is data related to the first diagnostic operation type extracted from the original diagnostic data. The process of determining the first diagnostic value set is to map each key in the first diagnostic key set to a specific value in the first operation type data.

[0146] For each key, the corresponding value is extracted from the first operation type data according to preset parsing rules. For example, for the key "dtcCode," the system extracts the fault code number (such as "P0123") from the first operation type data; for the key "occurrenceCount," the system extracts the number of occurrences of that fault code (such as "5"). If a key does not have a corresponding value in the first operation type data, the system assigns a default value (such as "null" or an empty string) according to preset default value rules. The matching process combines each key in the first diagnostic key set with its corresponding value in the first diagnostic value set to form a key-value pair. This process ensures that each key has a unique corresponding value, forming a complete set of key-value pairs. JSON format construction rules then define how to organize this set of key-value pairs into a complete data structure that conforms to the JSON specification. The encapsulation process includes determining the hierarchical structure of the JSON data, adding necessary nested relationships, and performing data type conversions. Finally, the top-level structure of the JSON data is determined based on the first diagnostic operation type. After the first diagnostic data is encapsulated in JSON format, it is transmitted to the diagnostic device via a specific communication protocol. The transmission process must ensure data integrity and real-time performance, using standard interfaces such as K-line (ISO9141-2, ISO14230) or CAN bus (ISO15765-4) for data exchange. After receiving the data, the diagnostic device must identify the diagnostic function type based on the specific identification field in the JSON structure.

[0147] Identifying the diagnostic function type relies on key identifiers within the JSON data, such as the value of the "function" field. This field explicitly indicates the type of diagnostic operation being performed, such as "readDtc" for reading a fault code, "readDataStream" for reading a data stream, or "clearDtc" for clearing a fault code. The diagnostic device parses the value of this field and, in conjunction with a pre-defined function type mapping table, determines the corresponding first diagnostic function type. Through this mapping, "readDataStream" is converted to the corresponding function type description, "read data stream," resulting in the first diagnostic function type.

[0148] Step S520 : transmitting the first diagnostic data to the diagnostic device, and having the diagnostic device determine the diagnostic function type of the first diagnostic data to obtain a first diagnostic function type.

[0149] Among them, the first diagnostic data is stored in JSON format, which includes the response information of the diagnostic request. The key to determining the diagnostic parameter set is to accurately extract the data fields related to the specific diagnostic function type from the JSON structure. Different diagnostic function types (such as reading fault codes, reading data streams, etc.) correspond to different parameter extraction rules, which are mapped to the JSON data model. Diagnostic parameters exist in a specific level of JSON data in the form of key-value pairs. For example, for the function of reading fault codes, key parameters include fault code number (DTC Code), fault status (Status), number of fault occurrences (OccurrenceCount), etc.; for the function of reading data streams, parameters may include engine speed (RPM), coolant temperature (CoolantTemperature), vehicle speed (Vehicle Speed), etc.

[0150] Step S530 : determining diagnostic parameters corresponding to the first diagnostic function type according to the first diagnostic data to obtain a first diagnostic parameter set.

[0151] Key parameters are accurately extracted from the structured first diagnostic data based on predefined JSON data model mappings. Different diagnostic function types (such as read fault codes, read data streams, and clear fault codes) correspond to specific parameter extraction rules. These rules define the parameter's location, data type, and mapping logic within the JSON hierarchy. For the read fault code function, the system first locates the "dtcList" node under the "result" field in the JSON data and extracts parameters such as the fault code number (DTCCode), fault status (e.g., current fault or past fault), fault occurrence count, and freeze frame data. Each fault code record follows a predefined key-value pair format. For example, "DTCCode" maps to a standard fault code string (e.g., "P0123"), and "occurrenceCount" maps to a numeric value representing the fault occurrence count. For the read data stream function, the system traverses the data stream parameter set under the "result" hierarchy and extracts real-time data based on predefined parameter identifiers (e.g., "engineSpeed" for engine speed and "coolantTemp" for coolant temperature). During the parameter extraction process, the system adheres to a strict data validation mechanism. If data is missing or formatted incorrectly, error indicators (such as a "null" value or error message) are added according to pre-set rules to ensure the integrity and reliability of the parameter set. For complex diagnostic functions (such as writing configuration codes), parameter extraction requires contextual analysis combined with business logic to ensure the semantic correctness of configuration parameters (such as communication baud rate and function switch status).

[0152] Step S540: determining a diagnosis result of the ECU of the vehicle to be diagnosed according to the first diagnostic parameter set.

[0153] Determining the diagnostic result requires comprehensive analysis of all data within the parameter set and comparison with pre-set standard parameter ranges and a fault signature library. The diagnostic result can be presented as a fault code, fault description, performance evaluation metrics, and more, providing direct guidance for vehicle maintenance. Furthermore, the pre-set standard parameter ranges are parameter thresholds set based on vehicle design specifications and normal operating conditions, used to determine whether the parameters are within the normal range.

[0154] Specifically, when the first diagnostic parameter set corresponds to the Read DTC function, the system first parses the DTC information within the parameter set. If the first diagnostic parameter set corresponds to the Read Data Item function, each parameter value is compared against the standard range. For example, if the engine speed in the parameter set is 1200 rpm at idle, while the standard idle range is 750-900 rpm, the system is considered to be idling too high. The system then further checks the parameters of related components, such as the throttle position sensor and idle speed control valve, to determine the root cause of the fault. For the Write Configuration Code function, the diagnostic results primarily focus on whether the configuration code was successfully written and the system feedback after the write. The system checks the write status code in the parameter set (e.g., "success" or "failure") and verifies that the relevant configuration parameters have been updated to the expected values. If the write fails, the system analyzes the error code (e.g., "Insufficient Permissions," "Parameter Format Error," etc.) and generates appropriate troubleshooting suggestions.

[0155] It's important to note that the correlation and logic between parameters are considered when determining diagnostic results. For example, when multiple parameters are abnormal simultaneously, the system determines whether these anomalies are caused by the same fault or the coexistence of multiple independent faults. Furthermore, for some complex faults, the system combines historical diagnostic data and vehicle maintenance records for comprehensive analysis to improve diagnostic accuracy. Through this systematic analysis approach, the system can extract valuable information from the initial diagnostic parameter set, providing comprehensive and accurate diagnostic results for the vehicle ECU being diagnosed, thereby facilitating efficient vehicle repair and maintenance.

[0156] For easier understanding, see Figure 6 , Figure 6 This is a timing diagram of a JSON-based vehicle diagnostic method provided by an application embodiment. It can be seen that Figure 6 The interaction process between the diagnostic equipment and the ECU of the vehicle to be diagnosed is demonstrated.

[0157] First, the diagnostic device, as the initiator of the diagnostic request, sends a diagnostic request in a JSON-formatted message. This request contains specific vehicle diagnostic requirements, such as reading fault codes, clearing fault codes, reading data items, writing configuration codes, and other diagnostic operation types. These requests constitute the starting signal for the vehicle diagnostic process. Next, after receiving the diagnostic request from the diagnostic device, the ECU of the vehicle to be diagnosed enters the diagnostic function format determination phase. This process determines the diagnostic function format based on the diagnostic request, specifies the specific diagnostic operation type, and then requests the vehicle's diagnostic data items from the ECU to be diagnosed.

[0158] After receiving the request from the JSON-formatted diagnostic message, the ECU of the vehicle being diagnosed will diagnose the vehicle's diagnostic function items. Based on its stored diagnostic logic and data, the ECU will check and analyze relevant vehicle functions, such as checking for engine control system faults and the normality of various sensor data. After completing the diagnosis, the ECU will return the diagnostic data items to the JSON-formatted diagnostic message.

[0159] Finally, after receiving the returned diagnostic data items, the diagnostic device enters the JSON-formatted diagnostic data construction phase. It organizes and encapsulates the diagnostic data items according to pre-set JSON format construction rules, converting them into diagnostic data that conforms to the JSON format specification. This structured data format facilitates subsequent transmission and processing. The JSON-formatted diagnostic message transmits the constructed JSON-formatted diagnostic data to the diagnostic device. After receiving the data, the diagnostic device can view the diagnostic results. The diagnostic device parses and analyzes the JSON-formatted diagnostic data, presenting the diagnostic information to the operator in an intuitive manner, such as by displaying fault codes, fault descriptions, and data values. This helps the operator understand the specific vehicle condition and provides a basis for subsequent repairs and treatment.

[0160] Throughout the interaction process, JSON-formatted diagnostic messages serve as the key hub for information exchange, coordinating the transmission and processing of information between the diagnostic device and the vehicle ECU being diagnosed. They accurately convey the diagnostic device's requests to the vehicle ECU and, at the same time, normalize the data returned by the vehicle ECU before transmitting it to the diagnostic device. The vehicle ECU being diagnosed provides the vehicle diagnostic data and performs the diagnostic operations, performing the requested diagnosis and returning accurate data. The diagnostic device, acting as both the initiator and the receiver of the final results, enables both the initiation of vehicle diagnostic requests and the review of the results. This interactive process, through the coordinated collaboration of all parties involved, enables efficient processing and accurate transmission of vehicle diagnostic data, providing solid technical support for vehicle fault diagnosis and repair.

[0161] As can be seen, by executing the above-described embodiment of the JSON-based vehicle diagnostic method, first diagnostic data transmitted by the ECU of the vehicle to be diagnosed is obtained, where the first diagnostic data is converted by the ECU of the vehicle to be diagnosed into JSON-formatted diagnostic data based on diagnostic requirements. Next, the diagnostic function type of the first diagnostic data is determined to obtain a first diagnostic function type. Then, diagnostic parameters corresponding to the first diagnostic function type are determined based on the first diagnostic data to obtain a first diagnostic parameter set. Finally, a diagnostic result of the ECU of the vehicle to be diagnosed is determined based on the first diagnostic parameter set. This improves the readability of diagnostic messages and diagnostic efficiency during the vehicle diagnostic process.

[0162] The above mainly introduces the scheme of the embodiment of the present application from the perspective of the execution process on the method side. It can be understood that in order to realize the above functions, the diagnostic equipment and the ECU of the vehicle to be diagnosed include hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should easily realize that, in combination with the units and algorithm steps of each example described in the embodiment provided in this article, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0163] The embodiment of the present application can divide the diagnostic equipment and the vehicle ECU to be diagnosed into functional units according to the above method example. For example, each functional unit can be divided according to each function, or two or more functions can be integrated into one processing unit. The above integrated unit can be implemented in the form of hardware or in the form of software functional units. It should be noted that the division of units in the embodiment of the present application is schematic and is only a logical functional division. There may be other division methods in actual implementation.

[0164] In the case of dividing each functional module into corresponding functional modules, Figure 7 This is a block diagram of the functional modules of a JSON-based vehicle diagnostic device provided in an embodiment of the present application. The JSON-based vehicle diagnostic device 700 is applied to a diagnostic device and includes:

[0165] The receiving module 710 is configured to obtain first diagnostic data transmitted by the ECU of the vehicle to be diagnosed; the first diagnostic data is converted by the ECU of the vehicle to be diagnosed into diagnostic data in JSON format according to diagnostic requirements;

[0166] A determination module 720 is configured to determine a diagnostic function type of the first diagnostic data to obtain a first diagnostic function type;

[0167] The determination module 720 is further configured to determine the diagnostic parameters corresponding to the first diagnostic function type according to the first diagnostic data, to obtain a first diagnostic parameter set.

[0168] The control module 730 is configured to determine a diagnosis result of the vehicle ECU to be diagnosed according to the first diagnostic parameter set.

[0169] In a possible embodiment, the determining module 720, in determining the diagnostic function type of the first diagnostic data to obtain the first diagnostic function type, is specifically configured to:

[0170] parsing the first diagnostic data to obtain second diagnostic data;

[0171] determining the diagnostic function data in the second diagnostic data based on a preset diagnostic function identifier to obtain first diagnostic function data;

[0172] The first diagnostic function data is classified according to a preset classification rule to obtain the first diagnostic function type.

[0173] In a possible embodiment, the determining module 720, in parsing the first diagnostic data to obtain the second diagnostic data, is specifically configured to:

[0174] Segmenting the first diagnostic data according to the JSON structure to obtain a first segmentation set; the first segmentation set includes a plurality of relatively independent data blocks;

[0175] Performing semantic analysis on the first diagnostic data to obtain a first semantic analysis result;

[0176] Performing key-value pair identification on the first segmentation set according to the first semantic analysis result to obtain a second key-value pair set;

[0177] The second key-value pair set is parsed based on a preset JSON format parsing rule to obtain the second diagnostic data.

[0178] In a possible embodiment, before determining the diagnostic parameters corresponding to the first diagnostic function type according to the first diagnostic data to obtain the first diagnostic parameter set, the receiving module 710 is specifically configured to:

[0179] Constructing string data in JSON format according to the first diagnostic function type to obtain first string data, and sending the first string data to the ECU of the vehicle to be diagnosed;

[0180] receiving a diagnostic response from the ECU of the vehicle to be diagnosed in response to the first character string data, and obtaining a diagnostic parameter identification set of the ECU of the vehicle to be diagnosed;

[0181] In determining the diagnostic parameters corresponding to the first diagnostic function type according to the first diagnostic data to obtain the first diagnostic parameter set, the determining module 720 is specifically configured to:

[0182] The diagnostic parameters corresponding to the first diagnostic function type are determined according to the first diagnostic data and the diagnostic parameter identification set to obtain the first diagnostic parameter set.

[0183] In a possible embodiment, the control module 730 is specifically configured to determine the diagnostic result of the vehicle ECU to be diagnosed according to the first diagnostic parameter set:

[0184] classifying each diagnostic parameter in the first diagnostic parameter set to obtain a first classified parameter set;

[0185] Obtaining a threshold value corresponding to each category parameter in the first classification parameter set to obtain a first threshold value set;

[0186] Comparing the first classification parameter set with each category parameter corresponding to the first threshold set to obtain a first comparison result set;

[0187] The diagnosis result of the vehicle ECU to be diagnosed is determined based on a preset mapping rule and the first comparison result set.

[0188] It should be noted that the specific implementation of each operation can adopt the corresponding description of the above-mentioned JSON-based vehicle diagnostic method embodiment, which will not be repeated here.

[0189] For the same example as above, please refer to Figure 8 , Figure 8 This is a functional module block diagram of another JSON-based vehicle diagnostic device provided in an embodiment of the present application. The another JSON-based vehicle diagnostic device 800 is applied to a vehicle ECU to be diagnosed, and the device includes:

[0190] A control unit 810 is configured to convert the original diagnostic data into first diagnostic data in JSON format according to diagnostic requirements;

[0191] A sending unit 820 is configured to transmit the first diagnostic data to the diagnostic device, and the diagnostic device determines the diagnostic function type of the first diagnostic data to obtain a first diagnostic function type;

[0192] a determining unit 830 configured to determine diagnostic parameters corresponding to the first diagnostic function type according to the first diagnostic data to obtain a first diagnostic parameter set;

[0193] The control unit 810 is further configured to determine a diagnosis result of the ECU of the vehicle to be diagnosed based on the first diagnostic parameter set.

[0194] In a possible embodiment, the control unit 810, in converting the original diagnostic data into the first diagnostic data in JSON format according to the diagnostic requirement, is specifically configured to:

[0195] Determine a diagnostic operation type according to the diagnostic requirement to obtain a first diagnostic operation type; the first diagnostic operation type includes at least one of: reading a fault code, clearing a fault code, reading a data item, and writing a configuration code;

[0196] acquiring diagnostic data corresponding to the first diagnostic operation type according to the original diagnostic data to obtain first diagnostic operation type data;

[0197] The first diagnostic operation type and the first diagnostic operation type data are constructed according to a preset JSON format construction rule to obtain first diagnostic data.

[0198] In a possible embodiment, the control unit 810 constructs the first diagnostic operation type and the first diagnostic operation type data according to a preset JSON format construction rule to obtain the first diagnostic data, specifically for:

[0199] Determine a key set of the JSON diagnostic operation corresponding to the first diagnostic operation type to obtain a first diagnostic key set;

[0200] determining data corresponding to each key in the first diagnosis key set according to the first operation type data to obtain a first diagnosis value set;

[0201] Matching the corresponding value of each key in the first diagnostic key set in the first diagnostic value set to obtain a first key-value pair set;

[0202] The first key-value pair set is encapsulated according to the JSON format construction rules to obtain the first diagnostic data.

[0203] It should be noted that the specific functional implementation of the vehicle diagnostic device 800 based on JSON can be found in the above Figure 5 The description of another JSON-based vehicle diagnostic method shown in the figure, for example, the sending unit 820 is used to implement the relevant content of executing S520, and the control unit 840 is used to implement the relevant content of executing S540, which will not be described in detail. The various units or modules in the JSON-based vehicle diagnostic device 800 can be individually or completely merged into one or several other units or modules to form a composition, or some (some) of the units or modules can be further divided into multiple functionally smaller units or modules to form a composition, which can achieve the same operation without affecting the realization of the technical effects of the embodiments of the present invention. The above-mentioned units or modules are divided based on logical functions. In actual applications, the functions of one unit (or module) are implemented by multiple units (or modules), or the functions of multiple units (or modules) are implemented by one unit (or module).

[0204] As can be seen, the first diagnostic data transmitted by the ECU of the vehicle to be diagnosed is obtained. The ECU of the vehicle to be diagnosed converts the raw diagnostic data into diagnostic data in JSON format based on diagnostic requirements. Next, the diagnostic function type of the first diagnostic data is determined to obtain a first diagnostic function type. Then, diagnostic parameters corresponding to the first diagnostic function type are determined based on the first diagnostic data to obtain a first diagnostic parameter set. Finally, a diagnostic result for the vehicle to be diagnosed ECU is determined based on the first diagnostic parameter set. This replaces the byte message transmission used in traditional vehicle diagnostics by using the JSON format. JSON uses a key-value pair format, with multiple key-value pairs added to distinguish different information. The key describes the meaning of a data item, and the value is the value of that item. This makes the information exchanged directly readable, resulting in clearer and more concise results, thereby improving the readability of diagnostic messages. Furthermore, diagnostic messages in JSON format directly transmit the parameters returned by the vehicle to be diagnosed ECU, eliminating the need for parsing the data exchanged between the diagnostic device and the vehicle ECU, thereby improving diagnostic efficiency.

[0205] The embodiment of the present application also provides a JSON-based vehicle diagnostic system, which includes a diagnostic device and a vehicle ECU to be diagnosed, wherein the diagnostic device can execute the following Figure 4 The JSON-based vehicle diagnosis method shown in the figure can be used by the ECU of the vehicle to be diagnosed to execute the following Figure 5 Another JSON-based vehicle diagnostic method is shown.

[0206] An embodiment of the present application also provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program for electronic data exchange, and the computer program enables a computer to execute part or all of the steps of any method described in the above method embodiments, and the above computer includes a diagnostic device or a vehicle ECU to be diagnosed.

[0207] The present application also provides a computer program product comprising a non-transitory computer-readable storage medium storing a computer program, wherein the computer program is operable to cause a computer to perform some or all of the steps of any of the methods described in the above method embodiments. The computer program product may be a software installation package, and the computer may include a diagnostic device or a vehicle ECU to be diagnosed.

[0208] It should be noted that, for the above-mentioned various embodiments, for the sake of simplicity of description, they are all expressed as a series of action combinations. Those skilled in the art should know that this application is not limited by the order of the actions described, because some steps in the embodiments of the present application can be performed in other orders or simultaneously. In addition, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions, steps, modules or units involved are not necessarily required by the embodiments of the present application.

[0209] In the above embodiments, the embodiments of the present application have different focuses on the description of each embodiment. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0210] Those skilled in the art will appreciate that all or part of the process steps in the above-described method embodiments can be implemented by a computer program instructing the relevant hardware. The program can be stored in a computer-readable storage medium, and when executed, the program can include the process steps in the above-described method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

[0211] The steps of the method or algorithm described in the embodiments of the present application can be implemented in hardware or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, which can be stored in RAM, flash memory, ROM, EPROM, electrically erasable programmable read-only memory (EEPROM), registers, hard disks, mobile hard disks, CD-ROMs, or any other form of storage medium well known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be an integral part of the processor. The processor and storage medium can be located in an ASIC. In addition, the ASIC can be located in a terminal device or a management device. Of course, the processor and storage medium can also be present in a terminal device or a management device as discrete components.

[0212] Those skilled in the art should be aware that in one or more of the above examples, the functions described in the embodiments of the present application can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiments of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, a computer, a server, or a data center via a wired computer, a server, or a data center. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or a data center that includes one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a digital video disc (DVD)), or a semiconductor medium (e.g., a solid-state drive (SSD)).

[0213] The modules / units included in the various devices and products described in the above embodiments may be software modules / units, hardware modules / units, or partially software modules / units and partially hardware modules / units. For the various devices and products applied to or integrated into terminal devices, the modules / units included therein may all be implemented using hardware such as circuits. Different modules / units may be located in the same component (e.g., a chip, circuit module, etc.) or different components within the terminal device. Alternatively, at least some modules / units may be implemented using software programs that run on a processor integrated within the terminal device, and the remaining (if any) modules / units may be implemented using hardware such as circuits.

[0214] The specific implementation methods described above further illustrate the purpose, technical solutions and beneficial effects of the embodiments of the present application. It should be understood that the above description is only a specific implementation method of the embodiments of the present application and is not intended to limit the scope of protection of the embodiments of the present application. Any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solutions of the embodiments of the present application should be included in the scope of protection of the embodiments of the present application.

Claims

1. A vehicle diagnostic method based on JSON, characterized in that: Applied to diagnostic equipment, the method comprises: Acquire first diagnostic data transmitted by the ECU of the vehicle to be diagnosed; the first diagnostic data is converted by the ECU of the vehicle to be diagnosed into diagnostic data in JSON format according to diagnostic requirements; determining a diagnostic function type of the first diagnostic data to obtain a first diagnostic function type; determining diagnostic parameters corresponding to the first diagnostic function type according to the first diagnostic data to obtain a first diagnostic parameter set; A diagnosis result of the vehicle ECU to be diagnosed is determined according to the first diagnostic parameter set.

2. The method according to claim 1, wherein The determining the diagnostic function type of the first diagnostic data to obtain the first diagnostic function type includes: parsing the first diagnostic data to obtain second diagnostic data; determining the diagnostic function data in the second diagnostic data based on a preset diagnostic function identifier to obtain first diagnostic function data; The first diagnostic function data is classified according to a preset classification rule to obtain the first diagnostic function type.

3. The method according to claim 2, wherein The parsing of the first diagnostic data to obtain second diagnostic data includes: Segmenting the first diagnostic data according to the JSON structure to obtain a first segmentation set; the first segmentation set includes a plurality of relatively independent data blocks; Performing semantic analysis on the first diagnostic data to obtain a first semantic analysis result; Performing key-value pair identification on the first segmentation set according to the first semantic analysis result to obtain a second key-value pair set; The second key-value pair set is parsed based on a preset JSON format parsing rule to obtain the second diagnostic data.

4. The method according to claim 1, wherein Before determining the diagnostic parameters corresponding to the first diagnostic function type according to the first diagnostic data to obtain a first diagnostic parameter set, the method includes: Constructing string data in JSON format according to the first diagnostic function type to obtain first string data, and sending the first string data to the ECU of the vehicle to be diagnosed; receiving a diagnostic response from the ECU of the vehicle to be diagnosed in response to the first character string data, and obtaining a diagnostic parameter identification set of the ECU of the vehicle to be diagnosed; The determining, based on the first diagnostic data, diagnostic parameters corresponding to the first diagnostic function type to obtain a first diagnostic parameter set includes: The diagnostic parameters corresponding to the first diagnostic function type are determined according to the first diagnostic data and the diagnostic parameter identification set to obtain the first diagnostic parameter set.

5. The method according to any one of claims 1 to 3, wherein Determining the diagnostic result of the vehicle ECU to be diagnosed according to the first diagnostic parameter set includes: classifying each diagnostic parameter in the first diagnostic parameter set to obtain a first classified parameter set; Obtaining a threshold value corresponding to each category parameter in the first classification parameter set to obtain a first threshold value set; Comparing the first classification parameter set with each category parameter corresponding to the first threshold set to obtain a first comparison result set; The diagnosis result of the vehicle ECU to be diagnosed is determined based on a preset mapping rule and the first comparison result set.

6. A vehicle diagnostic method based on JSON, characterized in that: Applied to a vehicle ECU to be diagnosed, the method includes: Converting the original diagnostic data into first diagnostic data in JSON format according to diagnostic requirements; transmitting the first diagnostic data to the diagnostic device, and having the diagnostic device determine a diagnostic function type of the first diagnostic data to obtain a first diagnostic function type; determining diagnostic parameters corresponding to the first diagnostic function type according to the first diagnostic data to obtain a first diagnostic parameter set; A diagnosis result of the ECU of the vehicle to be diagnosed is determined according to the first diagnostic parameter set.

7. The method according to claim 6, wherein The converting of the original diagnostic data into first diagnostic data in JSON format according to the diagnostic requirements includes: Determine a diagnostic operation type according to the diagnostic requirement to obtain a first diagnostic operation type; the first diagnostic operation type includes at least one of: reading a fault code, clearing a fault code, reading a data item, and writing a configuration code; acquiring diagnostic data corresponding to the first diagnostic operation type according to the original diagnostic data to obtain first diagnostic operation type data; The first diagnostic operation type and the first diagnostic operation type data are constructed according to a preset JSON format construction rule to obtain first diagnostic data.

8. The method according to claim 7, wherein The step of constructing the first diagnostic operation type and the first diagnostic operation type data according to a preset JSON format construction rule to obtain the first diagnostic data includes: Determine a key set of the JSON diagnostic operation corresponding to the first diagnostic operation type to obtain a first diagnostic key set; determining data corresponding to each key in the first diagnosis key set according to the first operation type data to obtain a first diagnosis value set; Matching the corresponding value of each key in the first diagnostic key set in the first diagnostic value set to obtain a first key-value pair set; The first key-value pair set is encapsulated according to the JSON format construction rules to obtain the first diagnostic data.

9. A vehicle diagnostic device based on JSON, characterized in that: Applied to diagnostic equipment, the device comprises: A receiving module is configured to obtain first diagnostic data transmitted by the ECU of the vehicle to be diagnosed; the first diagnostic data is converted by the ECU of the vehicle to be diagnosed into diagnostic data in JSON format according to diagnostic requirements; a determining module, configured to determine a diagnostic function type of the first diagnostic data to obtain a first diagnostic function type; a determination module, further configured to determine diagnostic parameters corresponding to the first diagnostic function type based on the first diagnostic data, to obtain a first diagnostic parameter set; A control module is used to determine a diagnosis result of the vehicle ECU to be diagnosed based on the first diagnostic parameter set.

10. A vehicle diagnostic device based on JSON, characterized in that: Applied to a vehicle ECU to be diagnosed, the device comprises: A control unit, configured to convert the original diagnostic data into first diagnostic data in JSON format according to diagnostic requirements; a sending unit, configured to transmit the first diagnostic data to the diagnostic device, and the diagnostic device determines the diagnostic function type of the first diagnostic data to obtain a first diagnostic function type; a determining unit, configured to determine diagnostic parameters corresponding to the first diagnostic function type according to the first diagnostic data, to obtain a first diagnostic parameter set; The control unit is further configured to determine a diagnosis result of the ECU of the vehicle to be diagnosed based on the first diagnostic parameter set.

Images