Fault recording method and device based on vehicle-mounted diagnostic software and storage medium

Abstract

The invention provides a fault recording method and device based on vehicle-mounted diagnostic software and a storage medium, and is applied to diagnostic equipment, and the fault recording method based on the vehicle-mounted diagnostic software comprises the steps: obtaining fault diagnosis information of a target vehicle, and generating a first fault log according to the fault diagnosis information, the first fault log is a blank fault log, the first fault log comprises a first blank area and a second blank area, preset first information is stored in the first blank area of the first fault log, fault diagnosis information is stored in the second blank area of the first fault log, and a target fault log is obtained, the first information is used for positioning the fault diagnosis information. By executing the method provided by the embodiment of the invention, when the vehicle fault occurs, the fault recording efficiency of the vehicle-mounted diagnostic software can be improved.

Description

Technical Field

[0001] This application relates to the field of intelligent vehicle technology, and in particular to a method, device and storage medium for recording faults based on on-board diagnostic software. Background Technology

[0002] With the rapid development of the automotive industry, vehicles are becoming increasingly integrated and intelligent, making on-board diagnostic software play an increasingly important role. Currently, in the fault recording and troubleshooting process, developers rely on business logic faults in key diagnostic log files uploaded by customers to locate problems. However, this approach is inefficient and ineffective. Furthermore, because existing on-board software fails to synchronously record contextual information such as threads, memory snapshots, and related service call chains, it is difficult to reproduce the faults, resulting in insufficient accuracy and low efficiency in fault diagnosis.

[0003] Therefore, improving the efficiency of fault recording by on-board diagnostic software when vehicle malfunctions occur is an urgent issue that needs to be addressed. Summary of the Invention

[0004] This application provides a method, device, and storage medium for recording faults based on on-board diagnostic software, which improves the fault recording efficiency of on-board diagnostic software when a vehicle fault occurs.

[0005] In a first aspect, embodiments of this application provide a method for recording faults based on on-board diagnostic software, applied to diagnostic equipment, the method comprising:

[0006] Obtain fault diagnosis information for the target vehicle;

[0007] A first fault log is generated based on the fault diagnosis information; the first fault log is a blank fault log; the first fault log includes a first blank area and a second blank area.

[0008] The preset first information is stored in the first blank area of ​​the first fault log, and the fault diagnosis information is stored in the second blank area of ​​the first fault log to obtain the target fault log; the first information is used to locate the fault diagnosis information.

[0009] Secondly, embodiments of this application provide a fault recording device based on vehicle diagnostic software, utilizing diagnostic equipment. The device includes: an acquisition unit, a control unit, and a recording unit, wherein:

[0010] The acquisition unit is used to acquire fault diagnosis information of the target vehicle;

[0011] The control unit is configured to generate a first fault log based on the fault diagnosis information; the first fault log is a blank fault log; the first fault log includes a first blank area and a second blank area.

[0012] The recording unit is used to store preset first information in the first blank area of ​​the first fault log and store the fault diagnosis information in the second blank area of ​​the first fault log to obtain the target fault log; the first information is used to locate the fault diagnosis information.

[0013] Thirdly, embodiments of this application provide a diagnostic device, including 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 programs include instructions for performing steps in any method of the first aspect of this application.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program for electronic data interchange, wherein the computer program causes a computer to perform some or all of the steps described in any method of the first aspect of this application.

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

[0016] By implementing the embodiments of this application, fault diagnosis information of the target vehicle is obtained, and a first fault log is generated based on the fault diagnosis information. The first fault log is a blank fault log, comprising a first blank area and a second blank area. Preset first information is stored in the first blank area of ​​the first fault log, and fault diagnosis information is stored in the second blank area of ​​the first fault log, resulting in a target fault log. The first information is used to locate the fault diagnosis information. By executing the method provided in the embodiments of this application, the fault recording efficiency of on-board diagnostic software can be improved when a vehicle fault occurs. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is an architecture diagram of a fault recording system based on vehicle diagnostic software provided in an embodiment of this application;

[0019] Figure 2 This is a schematic diagram of the structure of a diagnostic device provided in an embodiment of this application;

[0020] Figure 3 This is a flowchart illustrating a method for recording faults based on vehicle diagnostic software, as provided in an embodiment of this application.

[0021] Figure 4 This is a flowchart illustrating another method for recording faults based on on-board diagnostic software provided in an embodiment of this application;

[0022] Figure 5 This is a schematic diagram of a fault recording scenario provided in an embodiment of this application;

[0023] Figure 6 This is a schematic diagram of another fault recording scenario provided in an embodiment of this application;

[0024] Figure 7 This is a flowchart illustrating the process of recording diagnostic steps using on-board diagnostic software, as provided in an embodiment of this application.

[0025] Figure 8 This is a block diagram of the functional modules of a fault recording device based on vehicle diagnostic software provided in an embodiment of this application. Detailed Implementation

[0026] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0027] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0028] It should be understood that the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document indicates that the preceding and following related objects are in an "or" relationship. In the embodiments of this application, "multiple" refers to two or more.

[0029] In the embodiments of this application, "at least one item" or its similar expression refers to any combination of these items, including any combination of a single item or a plurality of items. "One or more" means one or more, while "multiple" means two or more. For example, "at least one item" of a, b, or c can represent the following seven cases: a, b, c; a and b; a and c; b and c; a, b, and c. Each of a, b, and c can be an element or a set containing one or more elements.

[0030] In this application, the term "connection" refers to various connection methods, such as direct connection or indirect connection, to achieve communication between devices. This application does not impose any limitations on this.

[0031] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0032] With the rapid development of the automotive industry, the integration and intelligence of vehicles are increasing, making on-board diagnostic software play an increasingly important role. In the fault recording and troubleshooting process of existing on-board diagnostic software, developers rely on business logic faults in key diagnostic log files uploaded by customers to locate problems. However, when a fault occurs and the diagnostic equipment malfunctions, the diagnostic logs only record key information, not a complete and detailed record of the entire business logic. This lack of context means that critical context data such as thread states, memory snapshots, and related service call chains are not recorded synchronously when a fault occurs, making it difficult to reproduce the problem and limiting troubleshooting efficiency.

[0033] To address the aforementioned problems, this application provides a method, apparatus, and storage medium for recording faults based on on-board diagnostic software, applied to diagnostic equipment. The method includes: acquiring fault diagnosis information of a target vehicle; generating a first fault log based on the fault diagnosis information, wherein the first fault log is a blank fault log, including a first blank area and a second blank area; storing preset first information in the first blank area of ​​the first fault log; and storing fault diagnosis information in the second blank area of ​​the first fault log to obtain a target fault log. The first information is used to locate the fault diagnosis information. By executing the method provided in this application, the fault recording efficiency of on-board diagnostic software can be improved when a vehicle fault occurs.

[0034] The following is combined with Figure 1 The architecture of a fault recording system based on vehicle diagnostic software, as described in this application embodiment, is as follows: Figure 1 This is an architecture diagram of a fault recording system based on vehicle diagnostic software provided in an embodiment of this application. The fault recording system 100 based on vehicle diagnostic software includes a diagnostic device 110 and a vehicle to be diagnosed 120.

[0035] The diagnostic device 110 includes a diagnostic device APP 111 and a vehicle communication interface 112. The diagnostic device 110 is used to diagnose vehicle faults, collect, process, and store fault-related information, providing support for vehicle fault diagnosis and analysis. As the core interactive terminal of the system, the diagnostic device 110 can be implemented using various intelligent terminal devices, such as professional automotive diagnostic instruments or smartphones with diagnostic functions. It establishes a data interaction channel with the vehicle to be diagnosed 120 through the vehicle communication interface 112, and uses the diagnostic device APP 111 to complete fault diagnosis logic execution, data processing, and human-machine interaction.

[0036] The diagnostic device APP111, serving as the functional carrier of the diagnostic device 110, is used for fault diagnosis. The diagnostic device APP111 has the following functions: First, a diagnostic command sending function, capable of sending precise diagnostic request commands to the vehicle to be diagnosed 120 according to preset diagnostic procedures and protocol specifications; Second, a data receiving and parsing function, decoding and parsing the received raw data from the vehicle to be diagnosed 120, such as binary fault codes and sensor values, converting them into readable information with actual physical meaning; Third, a fault diagnosis and analysis function, based on the parsed data, combined with built-in fault diagnosis algorithms and a fault knowledge base, analyzing and judging whether the vehicle has a fault, the severity of the fault, and the possible causes of the fault, generating a detailed and accurate fault diagnosis report; Finally, a data storage and management function, storing various types of data generated during the diagnostic process, including raw collected data, parsed data, and diagnostic results, locally according to a certain storage structure and data format, while supporting operations such as querying, retrieving, and exporting stored data, facilitating subsequent fault tracing and analysis.

[0037] The vehicle communication interface 112 serves as the data exchange point between the diagnostic device 110 and the vehicle 120 to be diagnosed. The vehicle communication interface 112 has a connection structure physically adapted to vehicle diagnostic interfaces (such as OBD-II interfaces), ensuring a stable physical connection. Common interface types include CAN bus interfaces and K-line interfaces, with different interface types corresponding to different vehicle communication protocols and data transmission rates. From a software perspective, the vehicle communication interface 112 needs to have a built-in communication protocol parsing and conversion module. This module can encapsulate and convert the instructions sent by the diagnostic device APP 111 according to a vehicle-recognizable protocol format, and simultaneously convert the raw data fed back by the vehicle into a format that the diagnostic device APP 111 can parse and process, thus achieving data interaction adaptation between the diagnostic device and the vehicle. Furthermore, the vehicle communication interface 112 also has data verification and error correction functions. During data transmission, it verifies the transmitted data. When data errors or loss are detected, it can automatically trigger a retransmission mechanism or error correction algorithm to ensure the accuracy and integrity of data transmission, providing a reliable data transmission environment for fault diagnosis.

[0038] Among them, the vehicle to be diagnosed 120 serves as the source of fault data. Its on-board diagnostic system (OBD) and other components can monitor the operating status of various systems in the vehicle in real time. When a fault or abnormality is detected, corresponding fault data is generated and awaits collection and analysis by the diagnostic equipment 110.

[0039] In one possible embodiment, when the vehicle 120 to be diagnosed has a potential fault or requires periodic diagnostics, the diagnostic device 110 establishes a communication connection with the vehicle 120 through the vehicle communication interface 112. The vehicle communication interface 112 conforms to relevant vehicle communication standards and protocols, such as ISO 15765 and SAE J1939, ensuring the compatibility and stability of data transmission between the diagnostic device and the vehicle. The diagnostic device APP 111 sends a diagnostic request command to the vehicle 120. After receiving the command, the vehicle 120 collects operating parameters and fault codes from various vehicle systems (such as the engine system, braking system, and electrical system) and feeds this information back to the diagnostic device APP 111 through the vehicle communication interface 112. The diagnostic device APP 111 parses and processes the received data, identifies key information such as the fault type and fault location, and generates a fault diagnosis result. Based on preset logic, it can store the fault-related information locally or perform further interactive operations, such as uploading to a cloud server or synchronizing to a vehicle management platform, providing a basis for vehicle repair and maintenance decisions. After completing fault diagnosis and generating fault diagnosis information (such as the first fault code, vehicle identification number, vehicle communication interface information, etc.), the diagnostic device APP111 stores the relevant information in the fault log according to the system's preset fault recording rules. During the storage process, the diagnostic device APP111 works collaboratively with the hardware resources and software environment of the diagnostic device 110. Simultaneously, the diagnostic device APP111 can also interact with the vehicle communication interface 112 to obtain real-time vehicle status data, which is used to supplement or verify the fault log information, ensuring the accuracy and timeliness of the fault records. After the fault log is stored, the diagnostic device APP111 can, according to user needs or system settings, synchronize the fault log to the on-board storage system of the vehicle to be diagnosed 120 via the vehicle communication interface 112, or upload it to a remote vehicle management server, realizing multi-terminal sharing and collaborative management of fault information, providing data support for long-term vehicle operation and maintenance and fault trend analysis.

[0040] As can be seen, through the coordinated operation of the diagnostic device APP 111 and the vehicle communication interface 112, the diagnostic device 110 can efficiently interact with the vehicle 120 to be diagnosed, completing the diagnosis of vehicle faults and related log recording. Through this system architecture, the system can achieve accurate diagnosis of vehicle faults and improve the efficiency of recording vehicle fault information.

[0041] The following is combined with Figure 2 The electronic devices in the embodiments of this application will be described. Figure 2 This is a schematic diagram of the structure of a diagnostic device provided in an embodiment of this application, such as... Figure 2As 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.

[0042] 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, cells, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computational functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc. The communication unit can be a communication interface, a transceiver, a transceiver circuit, etc., and the storage unit can be a memory.

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

[0044] 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 221 include instructions for performing any step in one of the following data processing method embodiments.

[0045] It is understood that the diagnostic device 200 may include more or fewer structural elements than those shown in the block diagram above, such as a power module, physical buttons, a Wi-Fi module, a speaker, a Bluetooth module, sensors, a display module, etc., without limitation. It is understood that the diagnostic device may be equipped with... Figure 1 The architecture of a fault recording system based on vehicle diagnostic software is described above.

[0046] After understanding the software and hardware architecture of this application, the following will be combined with... Figure 3 This application describes a method for recording faults based on on-board diagnostic software. Figure 3 This is a flowchart illustrating a method for recording faults based on on-board diagnostic software, provided in an embodiment of this application. The method specifically includes the following steps:

[0047] Step S310: Obtain fault diagnosis information for the target vehicle.

[0048] The fault diagnosis information refers to the key data generated by the diagnostic equipment during the fault diagnosis of the target vehicle, used to reproduce the fault scenario and locate the root cause of the anomaly. This information includes: timestamps, the execution time of each diagnostic step, accurate to the millisecond level, used to construct the time sequence of the fault occurrence; diagnostic function descriptions, the specific types of diagnostic operations performed, such as reading fault codes, writing vehicle configuration (VIN), and calibrating vehicle electronic control unit (ECU) parameters; ECU communication identifiers: request IDs and response IDs of interactions with the ECU during the diagnostic process, used to locate the communication link; diagnostic data, instruction data sent to the ECU and response data received, stored in byte stream format; service call chain parameters, the input parameters (such as configuration parameters, VIN codes) and output parameters (such as operation results, fault code details) associated with the diagnostic service, containing key contextual information; and runtime status data, thread states and memory snapshots captured synchronously when the fault occurs, used to analyze the system environment when the program malfunctions, etc., which are not limited here.

[0049] The diagnostic equipment obtains fault diagnosis information in the following ways. First, when the diagnostic app detects a vehicle diagnostic anomaly (such as communication timeout or uncleared fault codes), it triggers a log recording mechanism. At this time, the diagnostic equipment establishes a connection with the vehicle controller local area network (CAN) through the vehicle communication interface (VCI) and sends a diagnostic request to the target ECU based on the ISO15118 or ISO14229 diagnostic protocol.

[0050] It should be noted that the acquisition of the fault diagnosis information follows the "abnormal triggering" principle: during the normal diagnostic process, the log recording function is turned off by default to reduce storage overhead; recording is only initiated when a diagnostic abnormality is detected (such as three consecutive failures to read fault codes), through dynamically preset trigger conditions, to avoid meaningless data accumulation. Simultaneously, sensitive information such as the ECU system ID and diagnostic data is processed during data acquisition to ensure vehicle communication security.

[0051] Step S320: Generate a first fault log based on the fault diagnosis information; the first fault log is a blank fault log; the first fault log includes a first blank area and a second blank area.

[0052] The first fault log is a structured log file created by the diagnostic equipment when it detects a vehicle diagnostic anomaly. Its physical storage format follows these rules: the first line of the file is fixed as the current system date in the format 20XXMMDD (e.g., 20250626), used to identify the log generation time; the first blank area is used to store diagnostic context data, including log record flags, thread states, memory snapshots, and service call chain parameters, providing environmental information for fault location; the second blank area is used to store the main body of fault diagnostic information, including timestamps, diagnostic function descriptions, EC communication IDs, and transmitted and received data, forming a time-series record of the fault phenomenon.

[0053] Specifically, the process of generating the first fault log is as follows: When the diagnostic APP detects an abnormal trigger condition (such as communication timeout or fault code not being cleared), the following operations are performed: A log file is created, generating a new file debug.log in the specified storage path. If the file already exists, it is renamed according to the timestamp. The date is written to the first line, and the current system time is obtained and written to the first line of the file in YYYYMMDD format, for example, 20250626. At the same time, the flag bits are initialized, and the log control flag BOOLg_bWritelog=FALSE is written to the beginning of the file, which disables the recording function by default. Then, two logical areas are defined by the file pointer offset. The space from the end of the first line to the beginning of the file is the first blank area, reserved for context data. The remaining space is the second blank area, used to store diagnostic process data.

[0054] It should be noted that a blank fault log refers to a file that is not filled with specific diagnostic data during generation, but has pre-set structured information (first line date, flag bits), and is not a physically blank file. This design satisfies the need for quick log time location and achieves structured data storage through logical area division. When g_bWritelog is TRUE, the diagnostic device writes context data such as thread status and memory snapshots to the first area in millisecond-level time sequence, and writes diagnostic function execution records to the second area, forming a complete fault reproduction chain. In addition, the log file adopts a hybrid binary and text storage format. Key data (such as ECU communication ID) is stored as a hexadecimal byte stream, and diagnostic function descriptions are stored as ASCII text, balancing data accuracy and readability.

[0055] With the above Figure 3 The embodiments shown are consistent; please refer to [link / reference]. Figure 4 , Figure 4 This is a flowchart illustrating another method for recording faults based on on-board diagnostic software provided in this application embodiment. The step of generating a first fault log based on the fault diagnosis information specifically includes the following steps:

[0056] S410. Determine the date information corresponding to the fault diagnosis information;

[0057] S420. The date information is converted according to a preset recording rule to obtain a first date;

[0058] S430, Obtain the fault log template;

[0059] S440. Write the first date into the fault log template to obtain the first fault log.

[0060] The date information is derived from the real-time system clock when the vehicle diagnostic system triggers an anomaly, ensuring global consistency of the time base. The preset recording rules enforce the use of the YYYYMMDD year-month-day encoding format (e.g., 20250623). The structured log template employs a layered field design, including: a metadata layer, which reserves fixed storage space for date identifiers, device IDs, and VIN codes; a dynamic data layer, used to predefine binary offsets for fields such as timestamps, ECU communication IDs, and diagnostic commands; and an extension area, used to configure flexible storage space for large data volumes such as thread stacks and memory images.

[0061] Specifically, when the diagnostic device APP starts, it synchronizes the vehicle gateway time via the NTP protocol to ensure that the system clock error is less than 10ms. When the CAN bus returns a diagnostic fault code (DTC) or the ECU response timeout threshold (default 150ms), it is determined to be a diagnostic abnormal event. Then, the year, month, and day data are extracted from the timestamp of the abnormal event, and a date identifier is generated by a format converter. At the same time, a log file named after the date (such as 20250623.log) is created in the log partition stored locally on the device, and the date identifier is written as the first byte. Finally, the pre-compiled log template is loaded from ROM to the file buffer, and the default values ​​of each field are initialized (such as filling in the timestamp).

[0062] Step S330: Store the preset first information in the first blank area of ​​the first fault log, and store the fault diagnosis information in the second blank area of ​​the first fault log to obtain the target fault log; the first information is used to locate the fault diagnosis information.

[0063] In the construction of the target fault log, preset date identifier information is written into the metadata storage area of ​​the first fault log, while fault diagnosis information is stored in the dynamic data recording area to form a complete target fault log. The date identifier information serves as the core positioning benchmark for log timeliness and is stored in the file header using fixed-length binary encoding. It can include standardized year, month, and day data (e.g., 20250623) and cyclic redundancy check codes, which are not limited here. This approach enables fast hash retrieval of daily log files while ensuring storage integrity through a verification mechanism. The dynamic data recording area adopts a chained block storage architecture, organizing data units according to the time sequence of the diagnostic business process. Each data block accurately records millisecond-level timestamps, ECU communication identifiers, diagnostic service types, and original sent and received data packets, and forms a continuous business flow through pointer links. The independent block at the tail captures a snapshot of the key context at the moment of the fault, including thread register states, base address pointers of the heap memory image, and parameter address mapping tables of the service call chain. The two types of storage areas achieve strict spatial isolation through preset physical address offsets to avoid the risk of data overwriting.

[0064] In one possible embodiment, storing the preset first information into the first blank area of ​​the first fault log specifically includes the following steps:

[0065] 331. Obtain the current time of the diagnostic device;

[0066] 332. Determine the first time in the first fault log;

[0067] 333. When the relationship between the first time and the current time meets a preset condition, determine the recording flag of the first fault log;

[0068] 334. Generate log record flag information based on the record flag;

[0069] 335. Store the first information and the log record flag information in the first blank area of ​​the first fault log.

[0070] The first blank area includes three functional segments: a time reference segment, which stores a date identifier in YYYYMMDD format, serving as the core basis for judging log timeliness. This identifier is obtained through the vehicle gateway's global clock synchronization module, maintaining an error range of ±50ms with UTC time to ensure time consistency during multi-ECU collaborative diagnosis; a verification segment, which uses the CRC-32 algorithm to perform cyclic redundancy check on the date identifier, and stores the checksum here. When the check fails (such as data corruption caused by storage medium flipping), the system automatically discards the current log file and recreates it to ensure data integrity; and a flag segment, which includes status flags, device hardware fingerprints (such as the CAN controller MAC address), and reserved extended fields.

[0071] For easier understanding, please refer to Figure 5 , Figure 5 This is a schematic diagram of a fault recording scenario provided in an embodiment of this application. As can be seen, the first blank area records the time, associated log flags, ECU system interaction data, diagnostic data, and service call information, forming a multi-level, multi-dimensional fault diagnosis file. The time field clearly defines the time node of fault occurrence or diagnostic execution, providing a benchmark for fault timing analysis; the log flag (BOOLg_bWritelog=TRUE) serves as a status identifier for the diagnostic process, determining whether fault information triggers the recording logic, ensuring the effective retention of diagnostic data; the request and response of the ECU system ID establishes a communication interaction link between the diagnostic device and the vehicle's electronic control unit, reflecting the underlying communication process of fault diagnosis; the transmitted and received diagnostic data are presented in hexadecimal array form, containing core information such as vehicle operating status parameters and fault characteristic codes; the input and output parameters of associated service calls reconstruct the execution logic and results of the diagnostic function, providing a basis for verifying the accuracy of fault diagnosis and optimizing its functions.

[0072] For easier understanding, please refer to Figure 6 , Figure 6 This is a schematic diagram of another fault recording scenario provided in this application embodiment. As can be seen, the fault recording scenario takes time and log flag as core elements. The time field (time: XXXX, XX, XX) accurately marks the time node when the diagnostic process occurs, serving as the time anchor point for fault diagnosis behavior and providing a basic time sequence basis for subsequent tracing of diagnostic events and analysis of diagnostic frequency. The log flag (BOOLg_bWritelog = FALSE) serves as the control identifier for the diagnostic data recording function, determining whether the data generated during the fault diagnosis process will be written to the log. It is a direct reflection of the diagnostic system's resource management and data storage strategy, thereby reflecting the operating status of the diagnostic system in the specific scenario of "not recording fault data". It complements the recording scenario where the log flag is TRUE, fully presenting the conditional logic of diagnostic data recording.

[0073] In one possible embodiment, after storing the first information and the log record flag information into the first blank area of ​​the first fault log, the method further includes the following steps:

[0074] A1. Obtain the operating information of the diagnostic device; the operating information includes: thread status, memory snapshot, and call chain information;

[0075] A2. Determine the associated service call flag in the call chain information;

[0076] A3. Determine the context information corresponding to the associated service call flag based on the fault diagnosis information to obtain the fault context information;

[0077] A4. Store the fault context information, the thread state, and the memory snapshot in the first blank area of ​​the first fault log.

[0078] When a vehicle diagnostic anomaly occurs, this logging method initiates the logging function through dynamically preset trigger conditions. First, the diagnostic app checks the status of the log flag `g_bWritelog`. When a diagnostic anomaly is detected (such as communication timeout or fault code anomaly), the flag is set to TRUE, and a new log file `debug.log` is created. The first line of the file presets the current date (format 20XXMMDD), and the file is divided into a first blank area (storing context data) and a second blank area (storing diagnostic information). Date consistency checks ensure the timeliness of the log file and prevent data corruption caused by recording across days. In the first blank area, thread states, memory snapshots, and input / output parameters of related service call chains are recorded synchronously. For example, the running status of each thread at the time of the fault, binary data of key memory areas, and input parameters (such as VIN codes and configuration parameters) and output results (such as operation status codes) of the diagnostic service are recorded in millisecond-level timestamp order. The second blank area records the diagnostic function description (such as reading fault codes and writing configurations), ECU communication ID (request and response ID), and the sent and received diagnostic data byte streams, forming a complete fault timeline chain.

[0079] This method significantly improves fault location efficiency through a structured log storage mechanism. Developers can quickly correlate abnormal operations in the diagnostic process with contextual data such as thread blocking locations and abnormal memory parameter values ​​recorded in the log files. For example, they can locate parameter errors when writing configurations to an ECU by using a memory snapshot in the first region, and then find the corresponding communication failure record by combining the timestamp in the second region.

[0080] In one possible embodiment, the fault diagnosis information includes: a first fault code, a vehicle identification code, and a vehicle communication interface. Storing the fault diagnosis information in the second blank area of ​​the first fault log specifically includes the following steps:

[0081] 336. Obtain the vehicle attribute information of the target vehicle based on the vehicle identification code;

[0082] 337. Determine the calling interface information corresponding to the first fault code for the vehicle communication interface;

[0083] 338. Obtain the first fault description information of the target vehicle based on the vehicle attribute information and the first fault code;

[0084] 339. Store the first fault description information and the call interface information in the second blank area of ​​the first fault log.

[0085] The Vehicle Identification Number (VIN) serves as the unique identifier for a vehicle and can be read from the onboard ECU using diagnostic equipment or manually entered by the user. The diagnostic app queries the local database or cloud-based vehicle records using the VIN to obtain attribute information matching the target vehicle, including key parameters such as vehicle brand, model, engine model, production date, and chassis number. For example, the VIN code "LSGABC12345678901" can be interpreted as a 2023 gasoline-powered vehicle of a certain brand, with an L4-2.0T engine and a production date of May 2023. The Vehicle Communication Interface (VCI) establishes a communication link with the target ECU via the CAN bus. The interface information is generated based on a preset fault code-interface mapping rule. This mapping rule can be from a database collected and organized by the company, or it can be predicted using traditional machine learning models, or it can be the correlation result output by a deep learning model; no specific limitation is made here. The diagnostic app queries a built-in mapping table (such as the interface correspondence defined by the ISO15118 protocol) based on the type of the first fault code (e.g., P0101 belongs to the engine system) and the fault subsystem to determine the ECU request ID and response ID that interacted with the fault code.

[0086] The fault description information is generated by fusing vehicle attributes and fault code semantics. The diagnostic app first filters the appropriate fault code library based on the vehicle model, then retrieves the standard description corresponding to the first fault code from the library (e.g., "air flow sensor circuit range / performance problem"), and adjusts the description accuracy by combining parameters such as the engine model in the vehicle attributes. The diagnostic app writes the structured data into the second area in timestamp order. First, it records the millisecond-level timestamp, then writes the fault description information (e.g., "2023 XX model 2.0T engine air flow sensor circuit abnormality"), then stores the interface call information (request ID: 0x7DF, response ID: 0x7E8), and finally attaches the transmitted and received diagnostic data byte streams (e.g., sent data [0x02, 0x01, 0x00], received data [0x02, 0x10, 0x05]). All data is stored in rows in the format of "timestamp-fault description-interface information-data frame", which facilitates subsequent location of fault nodes through keyword retrieval or time-series analysis.

[0087] In one possible embodiment, determining the calling interface information corresponding to the first fault code for the vehicle communication interface specifically includes the following steps:

[0088] 3371. Determine the fault type and the fault subsystem in which the first fault code occurred;

[0089] 3372. Based on the preset mapping relationship between fault codes and communication interfaces, the first communication interface corresponding to the fault subsystem is determined by the first fault code;

[0090] 3373. Obtain the first call interface information of the first communication interface, and obtain the second call interface information of the vehicle communication interface;

[0091] 3374. Determine the intersection between the first call interface information and the second call interface information to obtain the call interface information of the vehicle communication interface corresponding to the fault code.

[0092] The first fault code follows the OBD (On-Board Diagnostic) standard encoding rules, with a format of five characters (e.g., P0101). The first character indicates the fault type, and the last four characters identify the specific fault subsystem and fault content. A preset mapping relationship is stored in the diagnostic device's firmware, using a key-value pair structure (fault subsystem → communication interface), and supports dynamic updates via OTA (Over-The-Air) technology. The first calling interface information includes the communication parameters of the ECU corresponding to the fault subsystem, including: physical layer parameters, CAN bus baud rate (e.g., 500kbps), data frame format (standard frame / extended frame), protocol layer parameters, diagnostic service ID, address parameters, request ID, and response ID (e.g., 0x7E8), which are not limited here.

[0093] Specifically, firstly, bus type matching is performed to check whether the VCI supports the bus type of the first communication interface (such as CAN). If it does, proceed to the next step; otherwise, an error code is returned. Next, the baud rate of the first communication interface is compared with the current baud rate of the VCI, and the common supported value of the two is taken (if multiple values ​​exist, the highest compatible baud rate is selected). The required protocol for the first communication interface is then selected from the diagnostic protocols supported by the VCI. Finally, address parameter mapping is performed. If the request ID / response ID of the first communication interface has a corresponding entry in the VCI's address mapping table, the address pair is retained. To illustrate this more clearly, let's take an example: If the fault code is P0300, the first calling interface information is: CAN bus (500kbps), request ID 0x7DF, protocol ISO14229; the second calling interface information is: CAN bus (supports 250kbps / 500kbps), protocol ISO14229 / ISO 15118; the intersection of the first and second calling interfaces is found, and the intersection result is CAN bus (500kbps), request ID 0x7DF, response ID 0x7E8, protocol ISO14229, forming the final calling interface information.

[0094] In addition, it includes an exception handling mechanism for fault code parsing. This mechanism works as follows: if the first fault code format does not conform to the OBD standard (e.g., length less than 5 digits), the default fault type is "Unknown," the fault subsystem is "General," and a fault code format verification alarm is triggered on the diagnostic device. If there is no record for the corresponding fault subsystem in the mapping table, the default communication interface is selected based on the fault type (e.g., the engine ECU interface is used by default for the powertrain system), and "Use default mapping" is marked in the log. The dynamic adaptation logic for calling interface information is as follows: when the VCI supports multiple baud rates, the highest baud rate matching the first communication interface is prioritized to improve communication efficiency; if there are version differences in the protocols, the lowest compatible version supported by both parties is selected to ensure communication compatibility; for manufacturer-defined fault codes, the mapping table allows manual addition of mapping rules through the diagnostic device's configuration tool to expand system applicability.

[0095] In one possible embodiment, obtaining the first fault description information of the target vehicle based on the vehicle attribute information and the first fault code specifically includes the following steps:

[0096] 3381. Determine the vehicle model in the vehicle attribute information;

[0097] 3382. Query the fault description corresponding to the first fault code from the preset fault code and fault description information database to obtain the second fault description information;

[0098] 3383. Filter out the fault description information corresponding to the vehicle model from the second fault description information to obtain the first fault description information.

[0099] The vehicle model is determined by parsing the Vehicle Identification Number (VIN) or extracting it from the vehicle's electronic file. First, the vehicle model code is parsed from the 10th and 11th digits of the VIN. If VIN decoding fails, the model field is read from the vehicle information stored in the onboard ECU, or manually entered via a diagnostic device's host computer. The vehicle model information must include key elements such as brand, model year, and configuration level. The database uses structured storage and includes the following levels: a basic fault code table, storing standard OBD fault codes (such as P0101) and SAE-defined general descriptions; a manufacturer extended table, storing brand-defined fault codes and their extended descriptions; and a vehicle model adaptation table, establishing a "fault code-vehicle model" mapping relationship and recording differentiated descriptions of the same fault code across different vehicle models. The manufacturer extended table is queried first. If the first fault code is a custom code (e.g., the first digit is "1", "2", or "3"), the brand-specific description is retrieved. If the query fails, the basic fault code table is queried again to obtain the general description. Each query returns a full list of vehicle model adaptation descriptions corresponding to the fault code.

[0100] The database's dynamic update mechanism is as follows: diagnostic equipment obtains fault code description update packages released by the manufacturer via the network and automatically synchronizes them to the vehicle model adaptation table; in addition, the database also supports technicians to add fault description mapping relationships for new vehicle models through host computer tools, such as exclusive fault code descriptions for newly released models of a certain brand.

[0101] For easier understanding, please refer to Figure 7 , Figure 7 This is a flowchart illustrating the process of recording diagnostic steps using on-board diagnostic software, as provided in this embodiment. As can be seen, when a vehicle malfunctions, and the vehicle's ECU (Electronic Control Unit) detects abnormal sensor data, communication link interruption, or system function execution failure, an anomaly identification mechanism is triggered. The diagnostic software determines that a "diagnostic anomaly has occurred" and then initiates the process of "recording information executed throughout the diagnostic process." After identifying the diagnostic anomaly, the information recording function of the diagnostic APP is activated. This function integrates sub-functions such as data acquisition, format conversion, and storage control. Once activated, it can systematically allocate system resources to ensure the complete capture of diagnostic process information.

[0102] Next, a log file named debug.log is created, with preset timestamps and flags, to build a standardized storage medium for diagnostic information. The log file name (debug.log) follows the file management specifications of the diagnostic system for easy identification and retrieval. The preset timestamp field (accurate to year, month, and day) clearly marks diagnostic events with timestamps, serving as the basic metadata for fault sequence analysis and diagnostic frequency statistics. The flag (BOOL g_bWritelog) acts as a control switch for log recording, and will be dynamically assigned values ​​based on the verification results of the diagnostic process, achieving refined management of "recording on demand". If the first line of data in the debug.log file is retrieved, it is compared with the current system time. If the times match, it indicates that the diagnostic process is within the same "time context," and the g_bWritelog flag is set to TRUE, triggering the recording of detailed diagnostic information, including diagnostic steps, function descriptions, and other core content. If the times do not match, the flag is set to FALSE, skipping detailed recording to avoid invalid data storage across time domains and ensure the temporal continuity and data validity of the log file. When the flag is TRUE, the diagnostic software writes the execution actions triggered after the diagnostic anomaly is triggered in a preset format (such as timestamp + step description + function parameters), including ECU communication commands, diagnostic service calls, fault code parsing processes, and other information.

[0103] Finally, after recording the basic diagnostic steps, thread status, memory snapshots, and related service call chain information are recorded synchronously. Thread status data reflects the process scheduling and resource usage of the diagnostic app during runtime, and can be used to troubleshoot operational faults in the diagnostic software itself (such as thread deadlock causing diagnostic interruption). Memory snapshots capture the distribution of memory data at the moment of diagnostic execution, assisting in the analysis of logical errors such as data caching and variable assignment. Related service call chain information (such as the input parameters, output parameters, and call sequence of the diagnostic service) reconstructs the interaction process between the diagnostic function and the vehicle ECU and background services, providing crucial evidence for locating communication faults and service logic vulnerabilities.

[0104] The above Figure 7This paper describes an onboard diagnostic software that records diagnostic steps, enabling precise fault tracing. From the triggering of an anomaly to detailed recording, it completely preserves the diagnostic execution trajectory. Repair personnel can use the logs to trace the vehicle's status and diagnostic process at the time of the fault, quickly locating the root cause and shortening the troubleshooting cycle. Simultaneously, the automation of the diagnostic system and the recording of data such as thread states and memory snapshots provide a basis for performance optimization and vulnerability patching of the diagnostic software, helping to improve the stability and accuracy of the diagnostic system. Furthermore, mechanisms such as time verification and flag control ensure the data quality of the log files, avoiding redundant storage and invalid records, and optimizing the storage resource usage of diagnostic equipment. This process uses abnormal scenarios as a starting point, constructing a standardized system for diagnostic data management through precise process control and comprehensive data capture. This process not only meets the current data tracing needs after vehicle fault diagnosis but also provides underlying support for the continuous optimization of the diagnostic system and the upgrading of intelligent vehicle operation and maintenance through data accumulation and analysis, helping to improve the efficiency of fault recording in vehicle diagnosis.

[0105] As can be seen, the above-described fault recording method based on on-board diagnostic software obtains the fault diagnosis information of the target vehicle, generates a first fault log based on the fault diagnosis information, wherein the first fault log is a blank fault log, and includes a first blank area and a second blank area. Preset first information is stored in the first blank area of ​​the first fault log, and fault diagnosis information is stored in the second blank area of ​​the first fault log, thus obtaining the target fault log. The first information is used to locate the fault diagnosis information. By executing the method provided in this application embodiment, the fault recording efficiency of the on-board diagnostic software can be improved when a vehicle fault occurs.

[0106] The above primarily describes the solutions of the embodiments of this application from the perspective of the method execution process. It is understood that, in order to achieve the above functions, the diagnostic device includes corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the examples described in the embodiments provided herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0107] This application embodiment can divide the electronic device into functional units according to the above method example. For example, each function can be divided into a separate functional unit, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional unit. It should be noted that the unit division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0108] When dividing each function into modules according to its corresponding function. Figure 8 This is a functional module block diagram of a fault recording device based on vehicle diagnostic software provided in an embodiment of this application. The fault recording device 800 based on vehicle diagnostic software includes:

[0109] Acquisition unit 810 is used to acquire fault diagnosis information of the target vehicle;

[0110] The control unit 820 is configured to generate a first fault log based on the fault diagnosis information; the first fault log is a blank fault log; the first fault log includes a first blank area and a second blank area.

[0111] The recording unit 830 is used to store preset first information in the first blank area of ​​the first fault log and store the fault diagnosis information in the second blank area of ​​the first fault log to obtain the target fault log; the first information is used to locate the fault diagnosis information.

[0112] In one possible embodiment, the control unit 820, in generating the first fault log based on the fault diagnosis information, is further configured to:

[0113] Determine the date information corresponding to the fault diagnosis information;

[0114] The date information is converted according to a preset recording rule to obtain a first date;

[0115] Get the fault log template;

[0116] The first date is written into the fault log template to obtain the first fault log.

[0117] In one possible embodiment, the recording unit 830 is specifically configured to: store preset first information in the first blank area of ​​the first fault log.

[0118] Obtain the current time of the diagnostic device;

[0119] Determine the first time in the first fault log;

[0120] When the relationship between the first time and the current time meets a preset condition, the recording flag of the first fault log is determined;

[0121] Log record flag information is generated based on the record flag;

[0122] The first information and the log record flag information are stored in the first blank area of ​​the first fault log.

[0123] In one possible embodiment, after storing the first information and the log recording flag information in the first blank area of ​​the first fault log, the recording unit 830 is further configured to:

[0124] Obtain the operational information of the diagnostic device; the operational information includes: thread status, memory snapshot, and call chain information;

[0125] Determine the associated service call flag in the call chain information;

[0126] Based on the fault diagnosis information, determine the context information corresponding to the associated service call flag to obtain the fault context information;

[0127] The fault context information, the thread state, and the memory snapshot are stored in the first blank area of ​​the first fault log.

[0128] In one possible embodiment, the fault diagnosis information includes: a first fault code, a vehicle identification number, and a vehicle communication interface. Specifically, the recording unit 830, in storing the fault diagnosis information in the second blank area of ​​the first fault log, is used for:

[0129] The vehicle attribute information of the target vehicle is obtained based on the vehicle identification code;

[0130] Determine the calling interface information corresponding to the first fault code for the vehicle communication interface;

[0131] Based on the vehicle attribute information and the first fault code, obtain the first fault description information of the target vehicle;

[0132] The first fault description information and the call interface information are stored in the second blank area of ​​the first fault log.

[0133] In one possible embodiment, the recording unit 830, in determining the calling interface information corresponding to the first fault code of the vehicle communication interface, is specifically used for:

[0134] Determine the fault type and the faulty subsystem in which the first fault code occurred;

[0135] Based on the preset mapping relationship between fault codes and communication interfaces, the first communication interface corresponding to the faulty subsystem is determined by the first fault code;

[0136] Obtain the first call interface information of the first communication interface, and obtain the second call interface information of the vehicle communication interface;

[0137] The intersection between the first call interface information and the second call interface information is determined to obtain the call interface information of the vehicle communication interface corresponding to the fault code.

[0138] In one possible embodiment, the recording unit 830 is specifically used for: obtaining first fault description information of the target vehicle based on the vehicle attribute information and the first fault code;

[0139] Determine the vehicle model from the vehicle attribute information;

[0140] The second fault description information is obtained by querying the fault description corresponding to the first fault code from the preset fault code and fault description information database.

[0141] The first fault description information is obtained by filtering out the fault description information corresponding to the vehicle model from the second fault description information.

[0142] It should be noted that the specific functional implementation of the fault recording device 800 based on the vehicle diagnostic software is described above. Figure 3 The description of a fault recording method based on vehicle diagnostic software, for example, the acquisition unit 810 is used to implement the relevant content of S310, which will not be elaborated further. The various units or modules in the fault recording device 800 based on vehicle diagnostic software can be individually or entirely merged into one or more other units or modules, or some of the units or modules can be further divided into multiple functionally smaller units or modules. This achieves the same operation without affecting the technical effect of the embodiments of the present invention. The above-mentioned units or modules are based on logical function division. In practical applications, the function of one unit (or module) is implemented by multiple units (or modules), or the function of multiple units (or modules) is implemented by one unit (or module).

[0143] As can be seen, the embodiments of this application describe a fault recording device based on on-board diagnostic software, applied to diagnostic equipment. By acquiring fault diagnosis information of a target vehicle, a first fault log is generated based on the fault diagnosis information. The first fault log is a blank fault log, including a first blank area and a second blank area. Preset first information is stored in the first blank area of ​​the first fault log, and fault diagnosis information is stored in the second blank area of ​​the first fault log, resulting in a target fault log. The first information is used to locate the fault diagnosis information. By executing the method provided in the embodiments of this application, the fault recording efficiency of on-board diagnostic software can be improved when a vehicle fault occurs.

[0144] This application also provides a computer-readable storage medium storing a computer program for electronic data interchange, the computer program causing a computer to perform some or all of the steps of any of the methods described in the above method embodiments, the computer including a diagnostic device.

[0145] This application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program 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 diagnostic devices.

[0146] It should be noted that, for the sake of simplicity, the above embodiments are all described as a series of actions. Those skilled in the art should understand that this application is not limited to the described order of actions, as some steps in the embodiments of this application can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions, steps, modules, or units involved are not necessarily essential to the embodiments of this application.

[0147] In the above embodiments, the descriptions of each embodiment in this application have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0148] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above 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.

[0149] The steps of the methods or algorithms described in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in RAM, flash memory, ROM, EPROM, electrically erasable programmable read-only memory (EEPROM), registers, hard disk, portable hard disk, read-only optical disk (CD-ROM), or any other form of storage medium well known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Furthermore, the ASIC can reside in a terminal device or management device. Alternatively, the processor and storage medium can exist as discrete components in the terminal device or management device.

[0150] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in the embodiments of this application can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. 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. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0151] The modules / units included in the various devices and products described in the above embodiments can be software modules / units, hardware modules / units, or a combination of both. For example, for devices and products applied to or integrated into a chip, all modules / units can be implemented using hardware methods such as circuits, or at least some modules / units can be implemented using software programs that run on a processor integrated within the chip, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits. For devices and products applied to or integrated into a chip module, all modules / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components of the chip module, or at least some modules / units can be implemented using hardware methods such as circuits. The implementation is achieved through a software program that runs on a processor integrated within the chip module. The remaining modules / units (if any) can be implemented using hardware methods such as circuits. For various devices and products applied to or integrated into terminal equipment, each of their modules / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components within the terminal equipment. Alternatively, at least some modules / units can be implemented using a software program that runs on a processor integrated within the terminal equipment, while the remaining modules / units (if any) can be implemented using hardware methods such as circuits.

[0152] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the embodiments of this application. It should be understood that the above descriptions are merely specific embodiments of the embodiments of this application and are not intended to limit the protection scope of the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solutions of the embodiments of this application should be included within the protection scope of the embodiments of this application.

Claims

1. A method for recording faults based on vehicle diagnostic software, characterized in that, Applied to diagnostic devices, the method includes: Obtain fault diagnosis information for the target vehicle; A first fault log is generated based on the fault diagnosis information; the first fault log is a blank fault log; the first fault log includes a first blank area and a second blank area. The preset first information is stored in the first blank area of ​​the first fault log, and the fault diagnosis information is stored in the second blank area of ​​the first fault log to obtain the target fault log; the first information is used to locate the fault diagnosis information.

2. The method as described in claim 1, characterized in that, The step of generating a first fault log based on the fault diagnosis information includes: Determine the date information corresponding to the fault diagnosis information; The date information is converted according to a preset recording rule to obtain a first date; Get the fault log template; The first date is written into the fault log template to obtain the first fault log.

3. The method as described in claim 1, characterized in that, The step of storing the preset first information into the first blank area of ​​the first fault log includes: Obtain the current time of the diagnostic device; Determine the first time in the first fault log; When the relationship between the first time and the current time meets a preset condition, the recording flag of the first fault log is determined; Log record flag information is generated based on the record flag; The first information and the log record flag information are stored in the first blank area of ​​the first fault log.

4. The method as described in claim 3, characterized in that, After storing the first information and the log record flag information into the first blank area of ​​the first fault log, the method further includes: Obtain the operational information of the diagnostic device; the operational information includes: thread status, memory snapshot, and call chain information; Determine the associated service call flag in the call chain information; Based on the fault diagnosis information, determine the context information corresponding to the associated service call flag to obtain the fault context information; The fault context information, the thread state, and the memory snapshot are stored in the first blank area of ​​the first fault log.

5. The method according to any one of claims 1-4, characterized in that, The fault diagnosis information includes: a first fault code, a vehicle identification number, and a vehicle communication interface. Storing the fault diagnosis information in the second blank area of ​​the first fault log includes: The vehicle attribute information of the target vehicle is obtained based on the vehicle identification code; Determine the calling interface information corresponding to the first fault code for the vehicle communication interface; Based on the vehicle attribute information and the first fault code, obtain the first fault description information of the target vehicle; The first fault description information and the call interface information are stored in the second blank area of ​​the first fault log.

6. The method as described in claim 5, characterized in that, The step of determining the calling interface information corresponding to the first fault code for the vehicle communication interface includes: Determine the fault type and the faulty subsystem in which the first fault code occurred; Based on the preset mapping relationship between fault codes and communication interfaces, the first communication interface corresponding to the faulty subsystem is determined by the first fault code; Obtain the first call interface information of the first communication interface, and obtain the second call interface information of the vehicle communication interface; The intersection between the first call interface information and the second call interface information is determined to obtain the call interface information of the vehicle communication interface corresponding to the fault code.

7. The method as described in claim 5, characterized in that, The step of obtaining the first fault description information of the target vehicle based on the vehicle attribute information and the first fault code includes: Determine the vehicle model from the vehicle attribute information; The second fault description information is obtained by querying the fault description corresponding to the first fault code from the preset fault code and fault description information database. The first fault description information is obtained by filtering out the fault description information corresponding to the vehicle model from the second fault description information.

8. A fault recording device based on vehicle diagnostic software, characterized in that, Applied to diagnostic equipment, the device includes an acquisition unit, a control unit, and a recording unit, wherein: The acquisition unit is used to acquire fault diagnosis information of the target vehicle; The control unit is configured to generate a first fault log based on the fault diagnosis information; the first fault log is a blank fault log; the first fault log includes a first blank area and a second blank area. The recording unit is used to store preset first information in the first blank area of ​​the first fault log and store the fault diagnosis information in the second blank area of ​​the first fault log to obtain the target fault log; the first information is used to locate the fault diagnosis information.

9. A diagnostic device, characterized in that, include: Processor, memory, communication interface, and one or more programs; The one or more programs are stored in the memory and configured to be executed by the processor, the programs including instructions for performing the steps of the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions that, when executed by a processor, cause the processor to perform the method as described in any one of claims 1-7.

Images