Vehicle fault data management method and device based on fault classification and cloud cooperation

Abstract

This application discloses a vehicle fault data management method and apparatus based on fault classification and cloud collaboration. The method includes: in response to the triggering of a vehicle fault event, acquiring the current fault code and a corresponding fault data snapshot at the time of the fault occurrence; querying the vehicle's local index cache, and determining whether to store the fault data snapshot based on the storage flag corresponding to the current fault code recorded in the index cache; if so, determining a target compression strategy from multiple compression strategies based on the importance level corresponding to the current fault code recorded in the index cache, compressing the fault data snapshot, generating a compressed data packet, associating it with the identifier of the current fault code, and storing it in the vehicle's on-board storage; recording the index information of the current fault code, which is used to retrieve the corresponding fault description information from the cloud. This application enables efficient management of vehicle fault data and optimizes the utilization efficiency of on-board storage resources.

Description

Technical Field

[0001] This application relates to the field of data processing technology, specifically to a vehicle fault data management method and apparatus based on fault classification and cloud collaboration. Background Technology

[0002] Modern vehicles are equipped with on-board diagnostic systems. When a malfunction is detected, the system automatically generates a corresponding fault code and simultaneously collects vehicle operating parameters at the time of the fault, forming a fault data snapshot. This snapshot typically includes key operating parameters such as engine speed, vehicle speed, and coolant temperature, serving as crucial data for subsequent vehicle fault diagnosis and repair analysis. Given the limited onboard storage resources, the efficient storage management of fault codes and their corresponding fault data snapshots directly impacts the utilization of these resources and significantly influences the subsequent fault diagnosis process.

[0003] Currently, the industry uses a non-discriminatory approach to store and manage vehicle fault data. After a vehicle fault event is triggered, a corresponding fault data snapshot is simultaneously saved for all faults. Furthermore, all fault data snapshots that need to be stored are processed uniformly, resulting in a large amount of fault data indiscriminately occupying onboard storage resources, thus causing unnecessary consumption of storage resources. It is evident that the existing technology for storing and managing vehicle fault data suffers from low utilization efficiency of onboard storage resources and excessive storage burden, making it difficult to adapt to the actual needs of vehicle fault data management with limited onboard storage resources.

[0004] The preceding description is intended to provide general background information and does not necessarily constitute prior art. Summary of the Invention

[0005] This application provides a vehicle fault data management method and apparatus based on fault classification and cloud collaboration, which can achieve efficient management of vehicle fault data and optimize the utilization efficiency of on-board storage resources.

[0006] In a first aspect, embodiments of this application provide a vehicle fault data management method based on fault classification and cloud collaboration, including: In response to a vehicle malfunction event, obtain the current fault code and a snapshot of the corresponding fault data at the time of the fault occurrence; Query the vehicle's local index cache, and determine whether it is necessary to store the fault data snapshot based on the storage flag corresponding to the current fault code recorded in the index cache; If the storage flag indicates that storage is required, then according to the importance level corresponding to the current fault code recorded in the index cache, a target compression strategy is determined from a variety of preset compression strategies, and the target compression strategy is used to compress the fault data snapshot to generate a compressed data packet. The compressed data packet and the identifier of the current fault code are associated and stored in the vehicle's on-board storage, and the index information of the current fault code is recorded. The index information is used to obtain the corresponding fault description information from the cloud.

[0007] Furthermore, in some embodiments of this application, the fault data snapshot includes at least one of engine speed, vehicle speed, coolant temperature, intake pressure, throttle opening, and oxygen sensor voltage.

[0008] Furthermore, in some embodiments of this application, before querying the local index cache of the vehicle, the method further includes: Obtain the core mapping data of the fault classification mapping table from the cloud server; the core mapping data includes at least one of the following: fault code number, importance level corresponding to the fault code number, and storage flag corresponding to the fault code number. The core mapping data is parsed according to a preset binary format and stored in the vehicle's local non-volatile memory to form the index cache.

[0009] The preset binary format data structure is as follows: each fault code entry occupies a fixed length of byte space, the byte space is divided into multiple bit fields, and the multiple bit fields are used to store the fault code number, the importance level corresponding to the fault code number, and the storage flag corresponding to the fault code number, respectively.

[0010] Furthermore, in some embodiments of this application, obtaining the core mapping data of the fault classification mapping table from the cloud server includes: The vehicle sends the current version information of the locally stored index cache to the cloud server. The system receives the current version information from the cloud server and compares it with the latest version information stored in the cloud. If the current version information is inconsistent with the latest version information, the cloud server sends an incremental update data packet based on the difference to the vehicle; The vehicle receives and parses the incremental update data packet, and uses the incremental update data packet to update the locally stored index cache.

[0011] Furthermore, in some embodiments of this application, determining a target compression strategy from a set of preset compression strategies based on the importance level corresponding to the current fault code recorded in the index cache includes: Parse the index cache to obtain the importance level corresponding to the current fault code; If the importance level is the first preset level, then the target compression strategy is determined to be a lossless compression strategy; If the importance level is the second preset level, then the target compression strategy is determined to be a hybrid compression strategy; the hybrid compression strategy is used to retain the key parameter set in the fault data snapshot without loss, to perform precision trimming on the non-key parameter set in the fault data snapshot, and to compress the precision-trimmed non-key parameter set and the losslessly retained key parameter set.

[0012] Furthermore, in some embodiments of this application, the rules for dividing the key parameter set and the non-key parameter set are uniformly defined by the cloud server and synchronized to the vehicle's local machine along with the core mapping data; Furthermore, in some embodiments of this application, the precision trimming specifically involves converting floating-point parameters into integer parameters according to a preset number of bits to retain.

[0013] Furthermore, in some embodiments of this application, the method further includes: If the storage flag indicates that storage is not required, the fault data snapshot is discarded, and only the code of the current fault code is recorded.

[0014] Furthermore, in some embodiments of this application, after associating and storing the compressed data packet and the identifier of the current fault code in the vehicle memory, and recording the index information of the current fault code, the method further includes: Receive fault read requests from diagnostic equipment; In response to the fault reading request, the code of the current fault code, the compressed data packet, and the index information are sent to the diagnostic device; The diagnostic device sends a fault description retrieval request to the cloud server based on the index information; The diagnostic device receives the structured fault description text returned by the cloud server and displays the structured fault description text.

[0015] Furthermore, in some embodiments of this application, the method further includes: When the diagnostic device is detected to be unable to connect to the cloud server, the diagnostic device displays a locally stored simple fault message or indicates that it is currently in offline mode.

[0016] Furthermore, in some embodiments of this application, the method further includes: Monitor the remaining storage space of the vehicle-mounted storage device, and trigger a storage space cleanup process when the remaining storage space is lower than a preset threshold; In response to the storage space organization process, all compressed data packets stored in the vehicle storage are scanned to obtain the importance level and storage timestamp of each compressed data packet. Based on the principle of prioritizing deletion based on the lowest priority and longest storage time, the compressed data packets to be deleted are determined from all the compressed data packets. Delete the compressed data packets to be deleted, and retain a preset number of the most recent compressed data packets with the highest importance level without deleting them.

[0017] Furthermore, in some embodiments of this application, the method further includes: When the compressed data packet is stored in the vehicle-mounted storage, a corresponding checksum is generated based on the content of the compressed data packet; The verification code is associated with the compressed data packet and stored in the vehicle-mounted storage. When reading the compressed data packet from the vehicle-mounted storage, the checksum of the compressed data packet is recalculated and compared with the checksum stored in association; If the comparison results are inconsistent, the compressed data packet is determined to be corrupted, and the storage block occupied by the compressed data packet in the vehicle's on-board memory is marked as unusable.

[0018] Secondly, embodiments of this application provide a vehicle fault data management device based on fault classification and cloud collaboration, comprising: The acquisition module is used to acquire the current fault code and the corresponding fault data snapshot at the time of the fault occurrence in response to the triggering of a vehicle fault event. The query module is used to query the vehicle's local index cache and determine whether it is necessary to store the fault data snapshot based on the storage flag corresponding to the current fault code recorded in the index cache. The compression module is used to, if the storage flag indicates that storage is required, determine a target compression strategy from a variety of preset compression strategies according to the importance level corresponding to the current fault code recorded in the index cache, and use the target compression strategy to compress the fault data snapshot to generate a compressed data packet. The storage module is used to associate and store the compressed data packet and the identifier of the current fault code in the vehicle memory, and to record the index information of the current fault code. The index information is used to obtain the corresponding fault description information from the cloud.

[0019] This application provides a vehicle fault data management method and apparatus based on fault classification and cloud collaboration. After a vehicle fault event is triggered, the fault code and corresponding fault data snapshot are first obtained. Then, the storage flag of the local index cache is used to determine whether to store the snapshot, realizing on-demand storage of fault data snapshots. This avoids the indiscriminate storage of all fault-related snapshot data, which would otherwise lead to the ineffective occupation of vehicle storage resources and reduce redundant data storage from the source. Then, for the snapshots that need to be stored, the corresponding target compression strategy is matched according to the importance level of the fault code to generate compressed data packets. While retaining the data required for fault diagnosis, the storage volume of fault data snapshots is effectively reduced, further reducing the storage load of the vehicle storage device. At the same time, the compressed data packets and fault code identifiers are associated and stored, and only the index information used to obtain the fault description from the cloud is recorded, rather than storing the fault description-related content locally. This significantly reduces the amount of stored data on the vehicle side and optimizes the utilization of vehicle storage resources. In summary, this application achieves efficient management of vehicle fault data by storing vehicle fault data snapshots on demand and compressing them hierarchically, and by associating them with fault code identifiers and cloud index information. This improves the utilization efficiency of on-board storage resources and ensures the effective storage of fault codes and corresponding fault data snapshots, providing reliable data support for vehicle fault diagnosis. Attached Figure Description

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

[0021] Figure 1 This is an application environment diagram of the vehicle fault data management method based on fault classification and cloud collaboration provided in the embodiments of this application; Figure 2 This is a flowchart illustrating the vehicle fault data management method based on fault classification and cloud collaboration provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of a vehicle fault data management device based on fault classification and cloud collaboration provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0022] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of systems and methods consistent with those detailed in the appended claims or with some aspects of this application.

[0023] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover descriptions such as non-exclusive inclusion, so that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, components, features, and elements with the same names in different embodiments of this application may have the same meaning or different meanings, the specific meaning of which must be determined by its interpretation in that specific embodiment or further in conjunction with the context of that specific embodiment.

[0024] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0025] In the following description, the use of suffixes such as "module," "part," or "unit" to denote elements is solely for the purpose of illustrative purposes and has no specific meaning in itself. Therefore, "module," "part," or "unit" may be used interchangeably.

[0026] To address the aforementioned technical problems and overcome the shortcomings of existing technologies, this application provides a vehicle fault data management method and apparatus based on fault classification and cloud collaboration, which can achieve efficient management of vehicle fault data and optimize the utilization efficiency of on-board storage resources.

[0027] Figure 1 This is an application environment diagram of a vehicle fault data management method based on fault classification and cloud collaboration in one embodiment. (Refer to...) Figure 1This vehicle fault data management method based on fault classification and cloud collaboration is applied to a vehicle fault data management system based on fault classification and cloud collaboration. The system includes a terminal 110 and a server 120. The terminal 110 and server 120 are connected via a network. The terminal 110 can be a desktop terminal or a mobile terminal; the mobile terminal can be at least one of a mobile phone, tablet, or laptop. The server 120 can be a standalone server or a server cluster consisting of multiple servers. Server 120 is configured to execute the aforementioned vehicle fault data management method based on fault classification and cloud collaboration, including: in response to the triggering of a vehicle fault event, obtaining the current fault code and a snapshot of the fault data at the time of the fault occurrence; querying the vehicle's local index cache, and determining whether to store the fault data snapshot based on the storage flag corresponding to the current fault code recorded in the index cache; if the storage flag indicates that storage is required, determining the target compression strategy from a variety of preset compression strategies based on the importance level corresponding to the current fault code recorded in the index cache, and using the target compression strategy to compress the fault data snapshot to generate a compressed data packet; associating the compressed data packet with the identifier of the current fault code and storing it in the vehicle's on-board storage, and recording the index information of the current fault code, which is used to obtain the corresponding fault description information from the cloud.

[0028] Please see Figure 2 , Figure 2 This is a flowchart illustrating a vehicle fault data management method based on fault classification and cloud collaboration, according to an embodiment of this application. This embodiment primarily uses the application of this vehicle fault data management method based on fault classification and cloud collaboration to a server as an example for illustration. Specifically, the vehicle fault data management method based on fault classification and cloud collaboration provided in this embodiment may include the following steps: S1. In response to the triggering of a vehicle malfunction event, obtain the current fault code and a snapshot of the corresponding fault data at the time of the fault occurrence; further, in some embodiments, the fault data snapshot includes at least one of engine speed, vehicle speed, coolant temperature, intake pressure, throttle opening and oxygen sensor voltage.

[0029] Specifically, in step S1, the onboard electronic control unit monitors the operating status of various vehicle systems in real time. When it detects that vehicle operating parameters exceed normal thresholds, components malfunction, or communication is abnormal, a vehicle fault event is triggered, and a unique current fault code matching the fault event is generated. At the moment the fault event is triggered, the vehicle's operating data is accurately captured to form a fault data snapshot. The fault data snapshot is the vehicle's operating condition data at the moment the fault occurs, including at least one of engine speed, vehicle speed, coolant temperature, intake pressure, throttle opening, and oxygen sensor voltage. This data serves as the core data for reconstructing the fault scenario and conducting fault diagnosis. It should be noted that the fault data snapshot in this embodiment can also be understood as frozen frame data. When the vehicle detects a fault, a frozen frame mechanism is triggered to save snapshots of multiple ECU (Electronic Control Unit) data streams at the moment the fault occurs, such as engine speed, vehicle speed, coolant temperature, and oxygen sensor voltage, to assist in repair and diagnosis.

[0030] For example, when the vehicle's electronic control unit detects a misfire in cylinder 1 of the engine, it triggers a fault event, generates the current fault code P0301, and captures a snapshot of the fault data at that moment, which includes data such as engine speed 3000 r / min, vehicle speed 85 km / h, coolant temperature 92℃, intake pressure 68 kPa, throttle opening 38%, and oxygen sensor voltage 0.82V.

[0031] S2. Query the vehicle's local index cache, and determine whether it is necessary to store a fault data snapshot based on the storage flag corresponding to the current fault code recorded in the index cache; Specifically, for step S2, the vehicle-mounted terminal pre-stores an index cache, which records the correspondence between each fault code and a storage flag. The storage flag is the sole basis for determining whether to store the corresponding fault data snapshot. When the current fault code is obtained, the vehicle diagnostic module quickly searches the local index cache, accurately matches the storage flag corresponding to the fault code, and makes a judgment on whether to store the current fault data snapshot based on the indication result of the storage flag.

[0032] For example, the storage flag corresponding to fault code P0301 recorded in the local index cache is "need to be stored", and the storage flag corresponding to fault code U0155 (loss of communication with the ABS module) is "no need to be stored". When the vehicle terminal obtains fault code P0301, it determines that its fault data snapshot needs to be stored. When it obtains fault code U0155, it determines that its fault data snapshot does not need to be stored.

[0033] S3. If the storage flag indicates that storage is required, then based on the importance level corresponding to the current fault code recorded in the index cache, the target compression strategy is determined from a variety of preset compression strategies, and the target compression strategy is used to compress the fault data snapshot to generate a compressed data packet. Specifically, for step S3, the local index cache records the importance level corresponding to each fault code, and the vehicle terminal is pre-configured with multiple compression strategies matching different importance levels. When it is determined that a fault data snapshot needs to be stored based on the storage flag, the importance level corresponding to the current fault code is first retrieved from the local index cache, and then a unique target compression strategy is determined from the preset multiple compression strategies based on the level. Subsequently, the original fault data snapshot is compressed according to the target compression strategy. While retaining the core data required for fault diagnosis, the snapshot data is optimized to finally generate a smaller compressed data packet.

[0034] For example, fault code P0301 corresponds to a high priority level. The vehicle terminal presets the target compression strategy for this level as a lossless compression strategy. This strategy is used to process the original fault data snapshot of P0301, preserving all snapshot data while compressing it to generate the corresponding compressed data packet. If a fault code corresponds to a medium priority level, its matching target compression strategy is a hybrid compression strategy. This strategy is used to retain the key parameters in its fault data snapshot without loss, trim the precision of non-key parameters, and then compress it to generate the corresponding compressed data packet.

[0035] S4. The compressed data packet and the identifier of the current fault code are associated and stored in the vehicle's on-board storage, and the index information of the current fault code is recorded. The index information is used to obtain the corresponding fault description information from the cloud. Specifically, in step S4, after compressing the fault data snapshot, the generated compressed data packet is bound to the unique identifier of the current fault code to ensure a one-to-one correspondence. Then, the bound compressed data packet and the fault code identifier are stored together in the vehicle's non-volatile memory to ensure the stability and relevance of data storage. Simultaneously, only the index information corresponding to the fault code is recorded on the vehicle's end. This index information serves as the exclusive matching basis for the fault description information in the cloud. The vehicle's end does not store any specific fault description text; the fault description information corresponding to the current fault code can be retrieved from the cloud later using this index information.

[0036] For example, the unique identifier of fault code P0301 is bound to the corresponding lossless compressed data packet and stored together in the vehicle flash memory. At the same time, the index information corresponding to P0301, desc_id=8876, is recorded on the vehicle. Subsequently, the fault description information matching P0301 can be accurately obtained from the cloud through this index information.

[0037] This embodiment achieves efficient management of vehicle fault data by judging on-demand storage of fault data snapshots and matching compression strategies according to fault importance levels. Then, it associates compressed data packets with fault code identifiers and stores only cloud index information. This reduces redundant data in vehicle storage from the source, effectively reduces the load on vehicle storage, improves storage resource utilization efficiency, and ensures the effective retention of fault codes and corresponding fault data, providing reliable data support for fault diagnosis.

[0038] Furthermore, in some embodiments, the method further includes, before querying the vehicle's local index cache: S201. Obtain the core mapping data of the fault classification mapping table from the cloud server; the core mapping data includes at least one of the following: fault code number, importance level corresponding to the fault code number, and storage flag corresponding to the fault code number. Specifically, for step S201, the cloud server pre-maintains a complete fault classification mapping table, which contains relevant classification management information for various vehicle fault codes. Before building the vehicle local index cache, the vehicle terminal only retrieves the core mapping data from the fault classification mapping table on the cloud server, without obtaining redundant fault descriptions or other information. The core mapping data includes at least one of the following: fault code number, the importance level corresponding to the fault code number, and the storage flag corresponding to the fault code number, which serves as the key basic data for realizing the subsequent fault code classification judgment on the vehicle terminal.

[0039] For example, the fault classification mapping table on the cloud server contains complete information on fault codes P0301, U0155, and B1234. The vehicle terminal only obtains the core mapping data of these fault codes from the cloud, specifically P0301 - high priority - needs to be stored, U0155 - low priority - does not need to be stored, and B1234 - medium priority - needs to be stored. It does not obtain other content such as the natural language description and maintenance suggestions corresponding to these fault codes.

[0040] S202. The core mapping data is parsed and stored in the vehicle's local non-volatile memory according to a preset binary format, forming an index cache. The preset binary format data structure is as follows: each fault code entry occupies a fixed-length byte space, which is divided into multiple bit fields. The multiple bit fields are used to store the fault code number, the importance level corresponding to the fault code number, and the storage flag corresponding to the fault code number, respectively.

[0041] Specifically, in step S202, the vehicle-mounted terminal parses the core mapping data obtained from the cloud, following a preset binary format rule. This rule specifies that each fault code entry occupies a fixed-length byte space, which is pre-divided into multiple independent bit fields. Each bit field has its own dedicated storage purpose, corresponding to the storage of the fault code number, the importance level corresponding to the fault code number, and the storage flag corresponding to the fault code number. After parsing, the processed binary data is stored in the vehicle's local non-volatile memory. This structured and lightweight binary data together form the vehicle-mounted terminal's index cache, providing data support for rapid queries after subsequent fault events are triggered.

[0042] For example, each fault code entry is pre-defined to occupy a fixed byte space of 2 bytes (16 bits). This space is divided into three bit fields: the first 10 bits are the fault code number field, the 11th and 12th bits are the importance level field (01 represents high priority, 10 represents medium priority, and 11 represents low priority), the 13th bit is the storage flag field (1 represents storage required, and 0 represents no storage required), and the remaining 3 bits are reserved. The vehicle terminal will parse the core mapping data of P0301 obtained from the cloud into the corresponding binary data according to this rule, and then store it together with the parsed data of fault codes such as U0155 and B1234 in the vehicle EEPROM to form a local index cache.

[0043] This embodiment obtains only the core mapping data of the fault classification mapping table from the cloud, and then parses and stores it as a local index cache in a binary format with fixed byte bit fields. This constructs a lightweight and structured vehicle-mounted local index cache, which significantly reduces the amount of data stored on the vehicle side, adapts to scenarios with limited vehicle storage resources, improves the query efficiency of fault code related information, and stores the cache in non-volatile memory to ensure data persistence and stability, providing accurate and reliable basic data for subsequent fault classification judgment.

[0044] Furthermore, in some embodiments, step S201, "obtaining the core mapping data of the fault classification mapping table from the cloud server," may specifically include: S2011. Send the current version information of the locally stored index cache to the cloud server via the vehicle; Specifically, in step S2011, the locally stored index cache in the vehicle carries unique version identification information. This version information is used to uniquely identify the current version status of the core mapping data in the local index cache, and can be represented by a version number, version timestamp, etc. The vehicle actively sends the current version information of the index cache to the cloud server through its own network communication module, thereby feeding back the latest data status of the local index cache to the cloud and providing a basis for subsequent version consistency verification.

[0045] For example, if the current version number of the vehicle's local index cache is V1.0, the vehicle will send the information "index cache version number: V1.0" to the cloud server through the vehicle-to-everything (V2X) communication link to inform the cloud of the current version of the local core mapping data.

[0046] S2012. Receive the current version information through the cloud server and compare the current version information with the latest version information stored in the cloud; Specifically, in step S2012, the cloud server receives the current version information of the index cache sent by the vehicle in real time, and at the same time retrieves the latest version information of the core mapping data of the fault classification mapping table maintained in its own background. The two are then compared precisely to determine whether the core mapping data of the local index cache is synchronized with the latest core mapping data in the cloud, thereby determining whether the local index cache of the vehicle needs to be updated.

[0047] For example, after the cloud server receives the V1.0 version information sent by the vehicle, it retrieves the latest version number of the cloud core mapping data, which is V1.1. After comparison, it is confirmed that the vehicle's local version is inconsistent with the latest version on the cloud, and it is determined that the vehicle's local index cache needs to be updated.

[0048] S2013. If the current version information is inconsistent with the latest version information, the cloud server sends an incremental update data packet based on the difference to the vehicle; Specifically, for step S2013, when the cloud server determines that there is a difference between the local version of the vehicle and the latest version on the cloud, it will not send the complete core mapping data to the vehicle. Instead, it will only extract the core mapping data content that differs between the two versions, including the newly added fault code core mapping data, the modified fault code classification or storage flag information, etc., and encapsulate these differences into an incremental update data packet, and then send the incremental update data packet to the corresponding vehicle end through the communication link.

[0049] For example, compared to the vehicle's local version V1.0, the cloud version V1.1 only adds the core mapping data of fault code P1E22 (high priority, needs to be stored), and modifies the storage flag of fault code U0401 (from not needing to store to needing to store). The cloud only encapsulates these two differences into an incremental update data package and sends it to the corresponding vehicle.

[0050] S2014. Receive and parse incremental update data packets through the vehicle, and use the incremental update data packets to update the locally stored index cache; Specifically, in step S2014, the vehicle receives incremental update data packets from the cloud via the network communication module, parses the data packets according to preset parsing rules, and extracts the core mapping data content that differs. Subsequently, the vehicle uses these parsed difference data to perform targeted update operations on the locally stored index cache, adding or modifying only the parts in the cache that differ, without changing the core mapping data that remains unchanged in the cache, thus completing the version upgrade of the local index cache and keeping the local core mapping data synchronized with the latest data in the cloud.

[0051] For example, after the vehicle parses the incremental update data packet, it extracts the newly added core mapping data of P1E22 and the modified core mapping data of U0401. According to the preset binary format, the data of P1E22 is added to the corresponding position in the local index cache. At the same time, the storage flag field information of U0401 in the cache is modified to complete the update of the local index cache from V1.0 to V1.1.

[0052] This embodiment achieves incremental updates to the index cache by having the vehicle send index cache version information to the cloud, the cloud complete version comparison and then only send out differential incremental update data packets, and the vehicle parses and updates the local cache. This significantly reduces the data transmission volume, saves vehicle network bandwidth and traffic, reduces the processing resource consumption of the vehicle terminal, improves cache update efficiency, and ensures that the local core mapping data is synchronized with the latest data in the cloud, so that the basis for fault classification judgment is always accurate and effective.

[0053] Furthermore, in some embodiments, step S3, "determining a target compression strategy from a variety of preset compression strategies based on the importance level corresponding to the current fault code recorded in the index cache," may specifically include: S31. Parse the index cache and obtain the importance level corresponding to the current fault code; Specifically, for step S31, after determining that the fault data snapshot needs to be compressed, the vehicle terminal parses the data in the locally stored index cache, accurately matches the relevant data information of the current fault code from the index cache, and extracts the importance level information that uniquely corresponds to the fault code. This importance level information is the core basis for determining the compression strategy in the future, ensuring that the compression strategy matches the importance of the fault.

[0054] For example, the vehicle terminal parses the local index cache and matches fault code P0301, which corresponds to the first preset importance level, and matches fault code B1234 (seat heating circuit fault), which corresponds to the second preset importance level. The importance level information corresponding to these two types of fault codes is then extracted.

[0055] S32. If the importance level is the first preset level, then the target compression strategy is determined to be a lossless compression strategy; Specifically, for step S32, a dedicated lossless compression strategy is pre-configured for fault codes of the first preset level. The core of this strategy is to fully preserve the original precision and content of all data during the compression process of the fault data snapshot, without performing any form of precision trimming or data deletion, thus ensuring data integrity. When the current fault code importance level obtained through parsing is the first preset level, the lossless compression strategy is directly determined as the target compression strategy for this fault data snapshot processing.

[0056] For example, if the importance level of fault code P0301 is the first preset level, the vehicle terminal directly determines that the target compression strategy for its fault data snapshot is a lossless compression strategy. The original fault data snapshot containing all parameters such as engine speed, vehicle speed, and oxygen sensor voltage is losslessly compressed, and the original values ​​and accuracy of each parameter are completely preserved.

[0057] S33. If the importance level is the second preset level, then the target compression strategy is determined to be a hybrid compression strategy. The hybrid compression strategy is used to retain the key parameter set in the fault data snapshot without loss, to perform precision trimming on the non-key parameter set in the fault data snapshot, and to compress the precision-trimmed non-key parameter set and the losslessly retained key parameter set. Furthermore, in some embodiments, the rules for dividing the key parameter set and non-key parameter set are uniformly defined by the cloud server and synchronized to the vehicle's local machine along with the core mapping data; Furthermore, in some embodiments, precision trimming specifically involves converting floating-point parameters into integer parameters according to a preset number of bits to retain.

[0058] Specifically, for step S33, a hybrid compression strategy is pre-configured for fault codes of the second preset level. When the importance level of the current fault code obtained through parsing is the second preset level, the hybrid compression strategy is determined as the target compression strategy. The execution of this strategy consists of three core steps. First, the data in the fault data snapshot is divided into key parameter sets and non-key parameter sets. The key parameter sets are retained without loss of quality or data processing. The non-key parameter sets are subjected to precision pruning. Then, the non-key parameter sets that have undergone precision pruning and the key parameter sets that have been retained without loss of quality are compressed as a whole to complete the compression of the fault data snapshot.

[0059] The rules for dividing critical and non-critical parameter sets are uniformly formulated by the cloud server. Based on the core diagnostic needs of different types of faults and the actual value of each parameter in restoring the fault occurrence conditions, the cloud will clearly define which parameters in the fault data snapshots corresponding to different fault codes belong to the critical parameter set that must be fully retained and which belong to the non-critical parameter set that can be simplified in terms of precision. This division rule will be synchronized to the vehicle's local machine as part of the core mapping data, along with information such as fault code number, importance level, and storage flag. There is no need for the vehicle to receive the rule data separately, ensuring that the parameter set division standard for the same type of fault code is completely uniform under different vehicles and different operating conditions, and avoiding differences in compression processing results caused by inconsistent division rules.

[0060] Precision trimming is performed on non-critical parameter sets. Specifically, it converts floating-point non-critical parameters in the fault data snapshot into integer parameters according to a pre-defined rule for retaining a certain number of digits in the cloud. This rule is also synchronized to the vehicle-mounted device along with the partitioning rules. Different standards can be preset according to the parameter type. For example, parameters such as ambient temperature and battery voltage can be preset to retain an integer number of digits, while some auxiliary detection parameters can be preset to retain one decimal place before being converted to an integer. This trimming method only makes controllable adjustments to the precision of non-critical parameters without deleting the parameters themselves. While significantly reducing the data storage volume, it ensures that non-critical parameters still have basic reference value. Moreover, the trimming process is executed according to preset rules, which is predictable and consistent, and there will be no irregular modification of parameter data.

[0061] For example, fault code B1234 has an importance level of the second preset level, and its target compression strategy is determined to be a hybrid compression strategy. The cloud uniformly defines the key parameter set for this type of fault as throttle opening and intake pressure, and the non-key parameter set as ambient temperature and battery voltage. This classification rule has been synchronized to the vehicle end. When processing the fault data snapshot, the original data of throttle opening 18% and intake pressure 56kPa are retained without loss. The non-key parameter ambient temperature of 25.6℃ (floating point type) is converted to 25 (integer type) according to the preset rule of retaining integer bits, and the battery voltage of 12.3V is converted to 12. Then, the processed key parameter set and non-key parameter set are compressed as a whole.

[0062] This embodiment uses a differentiated compression strategy based on the importance level of the fault codes. For high-level fault data, lossless compression is used to ensure integrity. For medium-level fault data, critical and non-critical parameters are distinguished according to unified cloud rules and mixed compression is performed. Floating-point non-critical parameters are converted to integers as required. While ensuring the core needs of fault diagnosis, this approach ensures the accuracy of high-value fault data diagnosis and effectively reduces the storage volume of medium-level fault data. At the same time, the unified division and trimming rules make the compression process more standardized and scientific.

[0063] Furthermore, in some embodiments, the method further includes: If the storage flag indicates that storage is not required, the fault data snapshot is discarded, and only the code of the current fault code is recorded.

[0064] Specifically, after querying the vehicle's local index cache and obtaining an indication that the storage flag corresponding to the current fault code is "no storage required," the vehicle's onboard unit will not perform any subsequent processing operations such as compression, transfer, or writing to memory on the previously captured fault data snapshot corresponding to that fault code. It will directly discard the fault data snapshot and will not import it into any stage of the onboard storage process, thus preventing such fault data snapshots from occupying onboard storage resources at the source of data processing. For example, if the onboard unit detects a communication fault and generates fault code U0155, after querying the local index cache and determining that the storage flag corresponding to this fault code is "no storage required," the onboard unit will directly discard the captured fault data snapshots corresponding to U0155, such as engine speed, vehicle speed, and coolant temperature, without performing any subsequent processing.

[0065] While discarding fault data snapshots, the vehicle-mounted terminal specifically records and stores the unique code of the current fault code. This fault code is the fundamental core identifier for identifying the type of vehicle fault. The recording process only retains the fault code itself in character or coded form, without any additional operating condition data. This minimizes the storage overhead of such records while retaining the basic fault information. For example, after discarding the fault data snapshot corresponding to fault code U0155, the vehicle-mounted terminal only records the fault code "U0155" in a designated area of ​​the vehicle's memory, without storing any operating condition snapshot data related to this fault, retaining only the basic fault identification information.

[0066] This embodiment avoids low-value, non-core fault condition data from occupying limited on-board storage resources by directly discarding fault data snapshots and recording only fault code codes when the storage flag indicates that storage is not required. This significantly reduces data redundancy in on-board storage, optimizes storage resource utilization efficiency, and retains the core identification identifiers of faults. While achieving lightweight on-board storage, it ensures that basic fault information is not lost, and relevant fault information can still be obtained through fault code codes later.

[0067] Furthermore, in some embodiments, after step S4 "associating and storing the compressed data packet and the identifier of the current fault code in the vehicle memory, and recording the index information of the current fault code", the method further includes: S51. Receive a fault read request from the diagnostic device; Specifically, for step S51, the vehicle-mounted terminal is equipped with a communication interface for external diagnostic equipment, supporting wired or wireless communication connections. Once a valid connection is established between the diagnostic equipment and the vehicle-mounted terminal, the operator initiates a command to read vehicle fault-related data through the diagnostic equipment. This command forms a fault reading request and is sent to the vehicle-mounted terminal. The fault data management module of the vehicle-mounted terminal receives the request in real time and completes the command recognition and preparation work before responding.

[0068] For example, the user establishes a wired connection between the diagnostic tool and the vehicle's OBD interface, clicks the "Read Vehicle Fault Data" button on the diagnostic tool's operation interface, the diagnostic tool generates a fault read request and sends it, and the vehicle's fault data management module successfully receives the request.

[0069] S52. In response to a fault reading request, send the current fault code, compressed data packet, and index information to the diagnostic device; Specifically, in step S52, after receiving the fault reading request, the vehicle-mounted terminal accurately retrieves the current fault code corresponding to the vehicle fault, the fault data snapshot compressed data packet associated with the fault code identifier, and the fault code's unique index information from its local non-volatile memory, ensuring that the three types of data correspond one-to-one without mismatch. Subsequently, the vehicle-mounted terminal sends these three types of core data completely and accurately to the requesting diagnostic equipment through the established communication interface, providing basic data support for subsequent fault diagnosis.

[0070] For example, after receiving a read request, the vehicle-mounted device retrieves the code for fault code P0301, the corresponding lossless compressed data packet, and the associated index information desc_id=8876 from the local Flash memory, and then sends these three types of data synchronously to the connected diagnostic tool through the OBD interface.

[0071] S53. The diagnostic device sends a fault description retrieval request to the cloud server based on the index information; Specifically, in step S53, after receiving the fault code, compressed data packet, and index information sent by the vehicle terminal, the diagnostic device automatically extracts the index information, which is a unique matching identifier for the fault description information in the cloud server. Using this index information as the core basis, the diagnostic device, through its network module, sends a fault description retrieval request to the cloud server. This request may carry compatibility information such as language type and data format to ensure that the cloud server can accurately return fault description content that meets the diagnostic requirements.

[0072] For example, after receiving the index information desc_id=8876, the diagnostic instrument sends a request to the cloud server via wireless network to obtain a fault description carrying the index information and specifying Chinese characters, thereby requesting a matching detailed fault description from the cloud.

[0073] S54. The diagnostic device receives the structured fault description text returned by the cloud server and displays the structured fault description text; Specifically, in step S54, after receiving the fault description retrieval request from the diagnostic device, the cloud server performs precise matching in the cloud fault description database based on the index information in the request, retrieving the corresponding structured fault description text. This text is a standardized and organized set of fault-related information, including a detailed description of the fault, possible causes, and other core diagnostic content. The cloud server returns this structured text to the diagnostic device, which receives it, parses the text, and clearly displays the content on its own interface for operators to view and use.

[0074] For example, the cloud server matches the corresponding structured fault description text based on desc_id=8876: "Cylinder 1 misfire - Possible causes: aging ignition coil, spark plug carbon buildup or malfunction, fuel injector blockage", and returns the text to the diagnostic tool. The diagnostic tool displays the complete content on the screen, providing a reference for technicians to troubleshoot the fault.

[0075] This embodiment achieves a collaborative process where the vehicle-mounted terminal receives a fault reading request and sends fault codes, compressed data packets, and index information. The diagnostic equipment then retrieves and displays structured fault description text from the cloud based on the index information. This eliminates the need for the vehicle-mounted terminal to pre-install a large fault description text library, reducing the amount of data stored in the vehicle and fully leveraging the advantages of cloud-based big data storage. Simultaneously, it allows diagnostic personnel to obtain complete and standardized fault description information, improving fault diagnosis efficiency and forming an efficient collaborative fault data management system among the vehicle-mounted terminal, diagnostic equipment, and the cloud.

[0076] Furthermore, in some embodiments, the vehicle fault data management method based on fault classification and cloud collaboration also includes: When the diagnostic device detects that it cannot connect to the cloud server, the diagnostic device displays a locally stored simple fault message or indicates that it is currently in offline mode.

[0077] Specifically, during the process of sending a fault description retrieval request to the cloud server, the diagnostic device uses its network detection module to monitor the network connection status with the cloud server in real time. The detection scope includes whether the network link is unobstructed, whether the cloud server is reachable, and whether data transmission can proceed normally. This determines whether a valid communication connection can be established with the cloud server, providing connection status information for subsequent fault description retrieval operations. The diagnostic device makes a judgment based on the network connection status detection results. If it detects a network link interruption, no response from the cloud server, or no cloud acknowledgment after data transmission, it clearly determines that it cannot connect to the cloud server. At this time, the diagnostic device will automatically terminate the fault description retrieval request to the cloud server and will no longer attempt invalid network connections. After determining that it cannot connect to the cloud server, the diagnostic device will automatically trigger a preset offline prompt strategy and execute corresponding prompt operations. This operation has two optional forms: the first is to display locally stored simplified fault prompt information on the device display interface. This information is a small amount of basic fault identification content stored locally by the diagnostic device, without detailed fault causes, repair suggestions, etc.; the second is to directly and clearly indicate on the display interface that it is currently in offline mode, informing the operator why a detailed fault description cannot be obtained.

[0078] For example, when the diagnostic tool sends a fault description retrieval request carrying desc_id=8876, it monitors its network connection to the cloud server in real time through methods such as network heartbeat packet detection and server connection receipt detection. If the diagnostic tool detects that its own wireless network is disconnected, mobile data is not enabled, or no response is received within the timeout period after sending the request to the cloud, it will determine that it cannot connect to the cloud server and terminate the fault description retrieval request. After determining that it cannot connect to the cloud, if the diagnostic tool chooses to display a simple fault message, it will display "P0301: Cylinder 1 misfire (offline simple message)" on the screen; if it chooses to display an offline message, it will display "The current device is in offline mode and cannot connect to the cloud to obtain a detailed fault description. Please check the network connection."

[0079] This embodiment effectively solves the problem of fault information display in offline scenarios by displaying locally stored simple fault prompts or offline mode prompts when the diagnostic equipment detects that it cannot connect to the cloud. This avoids the complete inability to obtain basic fault information due to network problems, ensures the basic operation of vehicle fault diagnosis in offline scenarios, improves the scenario adaptability of fault diagnosis methods, and allows operators to quickly locate network problems, thereby improving the operational experience and execution efficiency of fault diagnosis.

[0080] Furthermore, in some embodiments, the vehicle fault data management method based on fault classification and cloud collaboration also includes: S61. Monitor the remaining storage space of the vehicle's on-board storage device. When the remaining storage space is lower than a preset threshold, trigger the storage space cleanup process. Specifically, for step S61, The vehicle-mounted system monitors the remaining storage capacity of the local memory in real time. This memory is a dedicated non-volatile storage area for storing compressed fault data packets. A storage space threshold is pre-set for this area, which serves as the critical value to trigger storage defragmentation. This threshold can be set based on the total capacity of the vehicle-mounted memory and the needs for storing fault data. When the remaining storage space is detected to be lower than the preset threshold, the vehicle-mounted system automatically triggers the storage defragmentation process, initiating subsequent packet filtering and deletion operations to prevent the inability to store new compressed fault data packets due to running out of storage space.

[0081] For example, the total capacity of the dedicated storage area for vehicle fault data is 512KB, and the preset remaining storage space threshold is 80KB. When the vehicle terminal detects that the remaining storage space in this area is only 75KB, which is lower than the preset threshold, the storage space consolidation process is immediately triggered.

[0082] S62. In response to the storage space reorganization process, scan all compressed data packets stored in the vehicle's on-board storage and obtain the importance level and storage timestamp of each compressed data packet; Specifically, in step S62, after the storage space consolidation process is triggered, the vehicle-mounted terminal performs a comprehensive scan of all fault data compressed data packets stored in the memory. It identifies the unique identifier of each compressed data packet and precisely retrieves two core pieces of information based on this identifier: the importance level of the fault code associated with the data packet and the actual storage timestamp of the data packet. The timestamp accurately records the time the data packet was written to storage. After the scan is complete, the vehicle-mounted terminal establishes a list associating all compressed data packets with their corresponding importance levels and storage timestamps, providing clear data support for subsequent filtering and deletion.

[0083] For example, after the cleanup process is triggered, the vehicle-mounted device scans and finds five compressed data packets stored in the memory, and matches the corresponding information: Packet 1 (P0301, high priority, 2026-03-10 14:20). Packet 2 (B1234, medium priority, 2026-03-09 10:15); Packet 3 (B1056, medium priority, 2026-03-08 09:30); Packet 4 (U0401, medium priority, 2026-03-07 16:45); Packet 5 (B2100, medium priority, 2026-03-06 11:20).

[0084] The above information was then compiled into a related list.

[0085] S63. Based on the principle of prioritizing deletion based on the lowest priority and longest storage time, determine the compressed data packets to be deleted from all compressed data packets; Specifically, for step S63, the vehicle-mounted terminal filters and sorts the organized data packet association list according to the preset principle of "deleting the lowest priority and longest storage time first". First, the importance level is used as the first filtering dimension, and low-priority data packets are listed as the primary filtering scope. If there are no low-priority data packets, medium-priority data packets are filtered, and high-priority data packets are not included in the scope of deletion for the time being. Then, the storage timestamp is used as the second filtering dimension. Within the defined filtering scope, the data packet with the earliest storage time is determined as the compressed data packet to be deleted. If the storage space requirement is still not met after deleting a single data packet, the objects to be deleted are determined in order of the oldest timestamp from the newest.

[0086] For example, if the above principles are applied to filter the 5 data packets, the high-priority data packet 1 will not be included in the deletion range. Among the medium-priority data packets 2-5, the data packet 5 has the longest storage time (2026-03-06 11:20), so data packet 5 will be identified as the compressed data packet to be deleted. If the remaining storage space is still below the threshold after deletion, the second oldest data packet 4 will be identified as the object to be deleted.

[0087] S64. Delete the compressed data packets to be deleted, and retain a preset number of the latest compressed data packets with the highest importance level without deleting them; Specifically, in step S64, the vehicle-mounted terminal performs deletion operations on the corresponding compressed data packets according to the determined list of packets to be deleted, releasing the occupied storage resources. At the same time, throughout the entire sorting process, protection rules are strictly enforced, namely, the number of data packets with the highest importance level to be retained is preset, and from all the data packets with the highest importance level, the preset number of data packets with the latest storage time are selected and locked for protection, ensuring that these data packets will not be included in the scope of deletion, nor will they be deleted due to any sorting operations, thus ensuring the retention of core fault data.

[0088] For example, if the system is set to retain two sets of the latest compressed data packets with the highest importance level, and only one set of high-priority data packets (1) exists in this scan, then the data packet 5 to be deleted is locked and protected; then the deletion operation is performed to remove the data packet 5 to be deleted from the memory, releasing the corresponding storage resources and completing this storage space reorganization.

[0089] This embodiment monitors the remaining space of the vehicle's onboard storage in real time. When the space falls below a preset threshold, it triggers storage cleanup. Data packets to be deleted are selected and deleted based on the principle of prioritizing the lowest priority and the longest storage time, while retaining a preset number of the latest data packets with the highest importance level. This achieves intelligent and refined management of the vehicle's fault data storage space, effectively preventing the storage from being full and unable to store new fault data, freeing up storage resources occupied by low-value old data, and forcibly retaining core fault data to ensure that diagnostic data of critical faults is not mistakenly deleted. This makes the allocation of onboard storage resources more in line with the actual needs of fault diagnosis.

[0090] Furthermore, in some embodiments, the vehicle fault data management method based on fault classification and cloud collaboration also includes: S71. When storing the compressed data packet to the vehicle's on-board storage, a corresponding checksum is generated based on the content of the compressed data packet; Specifically, in step S71, during the process of writing the compressed data packet after fault data processing into the vehicle's on-board storage, the on-board unit will calculate a unique checksum corresponding to the compressed data packet based on the complete data content of the compressed data packet using a preset verification algorithm. This checksum is a unique verification identifier for the integrity of the compressed data packet. The same data content calculated using the same algorithm will yield a fixed checksum. If any changes occur to the data content, the checksum will change accordingly. Commonly used preset verification algorithms can include efficient verification methods such as CRC32.

[0091] For example, when writing the lossless compressed data packet corresponding to fault code P0301 into the vehicle's Flash memory, the vehicle terminal uses the CRC32 check algorithm to calculate all the bytes of the compressed data packet and generate a unique check code 0xA3F1B2C0.

[0092] S72. Associate the checksum with the compressed data packet and store it in the vehicle's on-board storage; Specifically, in step S72, the vehicle-mounted terminal binds the generated check code to the corresponding compressed data packet one-to-one, and uses a structured storage method to write the two together into a designated area of ​​the vehicle-mounted memory. The check code is usually stored in a fixed associated location of the corresponding compressed data packet (such as the end of the data packet or an adjacent storage address) to ensure that the corresponding check code can be retrieved quickly and accurately when the compressed data packet is read later, thus realizing the synchronous storage and retrieval of the check code and the compressed data packet.

[0093] For example, the calculated checksum 0xA3F1B2C0 is stored at the end of the P0301 compressed data packet and written together with the data packet into the dedicated fault data storage partition of the vehicle flash memory, forming an associated storage unit of the compressed data packet and the checksum.

[0094] S73. When reading compressed data packets from the vehicle-mounted storage, recalculate the checksum of the compressed data packets and compare it with the checksum stored in the associated storage; Specifically, for step S73, when the vehicle-mounted terminal needs to read the compressed data packet from the memory (such as in response to a fault reading request from a diagnostic device), it first retrieves the target compressed data packet and its associated stored checksum simultaneously; then, using the same checksum algorithm as when storing, it recalculates the complete content of the compressed data packet being read to obtain a new checksum; finally, it compares the recalculated new checksum with the original associated checksum retrieved from the memory, and determines whether the compressed data packet has been corrupted during storage based on the comparison result.

[0095] For example, when the diagnostic equipment requests to read the fault data of P0301, the vehicle terminal retrieves the compressed data packet of the fault and the original check code 0xA3F1B2C0 stored at the end from the Flash memory, and then recalculates the retrieved compressed data packet using the CRC32 algorithm to obtain a new check code. The new check code is then compared bit by bit with 0xA3F1B2C0.

[0096] S74. If the comparison results are inconsistent, it is determined that the compressed data packet is corrupted, and the storage block occupied by the compressed data packet in the vehicle memory is marked as unusable. Specifically, for step S75, if the comparison result of the recalculated check code and the original associated check code is inconsistent, it indicates that the compressed data packet has suffered data loss or bit flipping during storage due to factors such as memory wear, vehicle voltage fluctuations, and data writing interruption. The vehicle terminal directly determines that the compressed data packet is damaged and cannot be used as a valid basis for fault diagnosis. At the same time, the vehicle terminal will mark the specific storage block occupied by the damaged compressed data packet in the vehicle memory and set it to an unavailable state to prevent new fault data compressed data packets from being written to the damaged block and to prevent the diagnostic equipment from retrieving the damaged data in the block again.

[0097] For example, if the recalculated check code is 0xA3F1B2C1, and the comparison result is inconsistent with the original check code 0xA3F1B2C0, the vehicle terminal determines that the compressed data packet corresponding to P0301 is corrupted, and at the same time marks the vehicle Flash memory block 0x002000-0x0020FF occupied by the data packet as unavailable.

[0098] This embodiment constructs a full-process integrity verification mechanism for fault data from storage to retrieval by generating and associating a storage check code when storing compressed data packets, recalculating the check code during retrieval and comparing it with the original check code. If the comparison is inconsistent, the data is determined to be corrupted and the corresponding storage block is marked as unusable. This accurately identifies corrupted fault data, avoids the use of invalid data for diagnosis, and ensures the accuracy and effectiveness of fault diagnosis data. At the same time, it optimizes the block management of the vehicle storage, avoids secondary damage caused by new data being written to corrupted blocks, improves the reliability of vehicle storage fault data, and the entire process is executed automatically without affecting the normal storage and retrieval efficiency of fault data.

[0099] To facilitate understanding of the vehicle fault data management method based on fault classification and cloud collaboration provided in this embodiment, the following will describe the specific implementation process: Step 1: Establish a fault code importance classification system. Maintain a fault code priority mapping table in the cloud, and classify standard OBD-II and manufacturer-defined DTCs according to the following dimensions: Level 1 (High Priority): Faults affecting driving safety, excessive emissions, and power interruption (such as P030 multi-cylinder misfire, P0420 low catalytic efficiency). Level 2 (Medium Priority): Affects comfort or performance but does not compromise safety (e.g., seat heating circuit failure B1234). Level 3 (low priority): intermittent, temporary, communication-related faults (such as U0155 losing communication with the ABS module).

[0100] Each DTC corresponds to a priority label and a flag indicating whether freeze frame storage is enabled.

[0101] Example: P0301 (cylinder 1 misfire) → Level 1, enable freeze frame; U0401 (receive invalid data from TCM) → Level 3, disable freeze frame.

[0102] In specific embodiments, the implementation methods for defining the importance level of fault codes (DTCs) (cloud maintenance) include: Assign an importance level label to each standard or vendor-defined DTC in the cloud-based diagnostic knowledge base, for example: Level 1 (High Priority): Involves critical systems such as safety, emissions, and power interruption (e.g., P0300 multi-cylinder misfire, P0420 low catalytic efficiency, C1201 braking system failure). Level 2 (Medium Priority): Affects driving experience or function but does not endanger safety (such as B1056 air conditioning compressor clutch circuit, U0100 communication loss with ECM). Level 3 (low priority): intermittent, temporary, non-functional alarms (such as U0401 receiving invalid data, B2100 door not closed warning).

[0103] Step 2: The vehicle system receives and parses the DTC.

[0104] When the ECU detects an anomaly and generates a DTC, it temporarily stores the DTC code and the original freeze frame data (several PID data streams) in the RAM buffer; the on-board diagnostic module queries the local cache priority index table (this table only contains the DTC number and priority identifier, and its size is <10KB); if the DTC is not marked as "enable freeze frame", the freeze frame data is directly discarded, and only the DTC code is recorded; If enabled, proceed to the next compression step.

[0105] Step 3: Perform hierarchical compression on high / medium priority frozen frames.

[0106] Level 1: Use lossless compression (such as LZ4) to retain all PID fields and ensure data integrity; Level 2: Employs a hybrid compression method combining lossy and lossless compression. Non-critical PIDs (such as ambient temperature) are pruned in terms of precision (e.g., retaining integer bits); critical PIDs (such as MAP, TPS, RPM) are kept in their original precision; a lightweight compression algorithm (such as Snappy) is used overall; the compressed freeze frame is bound to the DTC index and written to non-volatile memory (such as EEPROM or Flash).

[0107] Step 4: Only the DTC index is stored locally; the description information is provided by the cloud.

[0108] The vehicle system does not store any natural language fault descriptions locally; it only saves the DTC code (such as "P0171") and its corresponding cloud description ID (such as desc_id=8876). When a diagnostic device (such as a repair tablet) reads a DTC: simultaneously obtain the DTC code and freeze frame (if any); request the cloud API GET / fault-desc?code=P0171&lang=zh-CN; The cloud returned a structured description: "System is too lean (Bank1) - Possible causes: vacuum leak, low fuel pressure, oxygen sensor malfunction"; The diagnostic software displays the results dynamically.

[0109] Step 5: When the storage space is full, execute the intelligent overwrite strategy.

[0110] Set the maximum storage limit for frozen frames (e.g., a maximum of 5 sets can be stored). When space is insufficient, prioritize the elimination process: first delete old Level 2 data; retain at least 2 sets of the latest frozen frames from Level 1; if space is still insufficient, prompt "Critical fault data is full, please read in time".

[0111] Take, for example, a 2024 new energy SUV whose power suddenly becomes limited while driving at high speed, causing the engine malfunction light to illuminate on the instrument panel.

[0112] Vehicle system actions: The ECU detected "P0302 – Cylinder 2 misfire" and determined it to be a Level 1 fault; automatically captured the frozen frame: RPM=2800, VSS=95km / h, MAP=65kPa, TPS=35%, coolant temperature=92°C; after using LZ4 lossless compression (original 128 bytes → compressed to 85 bytes), it was written to Flash along with the DTC index; at the same time, the DTC "P0302" and its cloud description ID were recorded.

[0113] Service station diagnosis: The technician connected the diagnostic tool to the vehicle and read DTC "P0302"; the diagnostic tool automatically connected to the network and requested the Chinese description and repair suggestions of the DTC from the cloud; at the same time, it downloaded the decompressed freeze frame data, which showed "the fault occurred when cruising at a constant speed of 95km / h"; based on the data, the technician quickly determined that the ignition coil was worn out, replaced it and cleared the DTC.

[0114] In the traditional way, the system may store multiple frozen frames (invalid data) of U-code communication failures at the same time; tens of thousands of fault descriptions do not need to be pre-installed locally, saving >5MB of storage space; adding fault code descriptions only requires updating the cloud, without upgrading the whole vehicle software.

[0115] For the local lightweight index cache (vehicle side), when the vehicle is activated for the first time via periodic OTA, it downloads and caches a simplified DTC index table from the cloud (containing only DTC number + priority + whether freeze frame is enabled). The index table adopts a compact binary format and its size is controlled between 5 and 15 KB, which is much smaller than the complete description library (usually > 5 MB). It supports incremental updates and only issues changed entries to avoid full replacement.

[0116] The implementation process for real-time hierarchical decision-making during freeze frame generation is as follows: When the ECU detects an anomaly, it generates a DTC (such as P0171) and captures the original freeze frame data (several PID values). The diagnostic module queries the local index table to obtain the priority of the DTC and the "whether to save the freeze frame" flag. If the flag is false (e.g., Level 3), the frozen frame is discarded directly, and only the DTC code is recorded; If the flag is true, the corresponding compression strategy will be executed according to the priority: Level 1: Lossless compression (such as LZ4, Deflate), retaining all original PID precision; Level 2: Hybrid compression of lossy and lossless compression: For non-critical PID controllers (such as ambient temperature and voltage fluctuations), the bit width can be reduced (e.g., float → int8). Maintain the original format for key PIDs (RPM, TPS, MAP); The entire system uses a lightweight compression algorithm (such as Snappy or LZ77); the compressed frozen frames are bound to the DTC index and written to non-volatile memory (such as EEPROM partition).

[0117] For the implementation logic of the intelligent overwrite strategy when storage is full, the maximum storage slot for frozen frames is set (e.g., a maximum of 5 groups); when a new frozen frame needs to be written but there is insufficient space, a tiered eviction process is executed: if (new_frame.level == 1) { / / Prioritize deleting the oldest records from Level 2 or Level 3. delete_oldest_frame_with_level(2 or 3); } else if (new_frame.level == 2) { / / Can only cover Level 2 or 3, not Level 1 delete_oldest_frame_with_level(2 or 3); } / / Level 3 is not saved and requires no processing.

[0118] At the same time, ensure that at least N sets (e.g., N=2) of the latest Level 1 frozen frames are retained.

[0119] Furthermore, when a new model is released or a new DTC is added, only the cloud index table needs to be updated; the changed parts will be automatically synchronized the next time the vehicle is connected to the network (such as adding DTCP1E22→Level1); there is no need to flash the ECU firmware or diagnostic module, realizing "strategy hot update".

[0120] In the hierarchical compression storage mechanism proposed in this solution, ensuring the integrity of frozen frame data is one of the core design goals, especially for high-priority (Level 1) fault scenarios. To achieve this goal, the system employs the following multi-level strategies to ensure the integrity, structural reliability, restoreability, and immutability of critical frozen frames while maintaining "hierarchical" and "compression" principles.

[0121] I. Differentiated processing based on priority: Compress / prune only non-critical data. Level 1 (high priority) frozen frames: no lossy compression or precision reduction is performed; lossless compression algorithms (such as LZ4, Deflate, Zstandard) are used; all original PIDs (parameter identifiers) and their values ​​(such as RPM=2850, VSS=92km / h, MAP=68kPa) are completely preserved; data before and after compression can be completely restored to ensure diagnostic accuracy.

[0122] Level 2 (medium priority) freeze frame: Only predefined non-critical PIDs (such as ambient temperature, battery voltage fluctuations) are subject to limited precision trimming; critical power / emission related PIDs (such as throttle opening, oxygen sensor voltage, knock value) retain their original precision; trimming rules are uniformly defined in the cloud and synchronized to the vehicle end to ensure predictability and reversibility (e.g., float→int16, retaining 1 decimal place).

[0123] II. Freeze Frame Structure Standardization + Verification Mechanism Each set of frozen frames is stored in a structured format with metadata and validation fields, for example: struct FreezeFrameRecord { uint32_t dtc_code; / / Fault code (e.g., 0x0171) uint8_tpriority_level; / / Priority (1 / 2 / 3) uint16_t pid_count; / / Number of PIDs included uint8_tcompressed_data[]; / / Compressed PID data stream uint32_t crc32; / / Calculate the CRC32 checksum for the entire record uint64_t timestamp; / / Timestamp of the failure (optional) }; During writing: Calculate the CRC32 or SHA-256 checksum and store it at the end of the record; During reading: First, check the CRC. If it does not match, mark it as "damaged" and do not provide it to diagnostic tools. Optional support for ECC (Error Correction Code) or redundant backup (writing two copies of Level 1 data).

[0124] This prevents data bit flipping or damage caused by Flash wear, voltage fluctuations, etc.

[0125] III. Guarantee of Atomic Writes from Memory to Storage After a freeze frame is generated, it is first compressed and verified in RAM; then written to non-volatile memory using an atomic write or journaling mechanism; this avoids "partially written" dirty data caused by power outages during the write process; some systems use a circular buffer plus a write flag to ensure that only complete records are marked as "valid". Even under extreme conditions (such as the moment of engine shutdown), it can ensure that the triggered freeze frame is completely written to disk.

[0126] IV. Diagnostic Terminal Decompression and Integrity Verification When diagnostic equipment (such as a repair tablet) reads a freeze frame, it first checks the CRC; selects the corresponding decompression algorithm based on priority and compression type; performs an integrity comparison on the Level 1 data (e.g., checks if the required PIDs are complete); if decompression fails or verification fails, it prompts "Freeze frame is corrupted, it is recommended to read other records"; it does not display unreliable data to avoid misleading repair judgments. It prevents the use of incomplete or erroneous freeze frames from the terminal side.

[0127] V. Cloud-based collaborative verification: In advanced diagnostic scenarios, diagnostic devices can upload the hash value of frozen frames to the cloud; the cloud compares the frozen frame patterns of similar historical faults to help determine the rationality of the data; if an anomaly is found (such as RPM=0 but VSS=100km / h), it can prompt "data may be abnormal".

[0128] Taking the integrity guarantee of the P0301 (cylinder 1 misfire) freeze frame as an example, The ECU detected a serious misfire and generated DTCP0301 (Level 1). Capture frozen frames: RPM=3100, VSS=85, TPS=40%, MAP=70, O2S1=0.85V, ... (12 PIDs in total); The system checked the table and confirmed it was Level 1 → lossless LZ4 compression enabled; After compression, the CRC32 value is calculated to be 0xA3F1B2C0. Atomic writing to the frozen frame partition of Flash; During maintenance, the diagnostic tool reads the record, verifies the CRC successfully, and decompresses and restores all 12 PIDs. The technician observed the entire scene: "The fire occurred at 85km / h cruising speed with the throttle valve at 40% opening," pinpointing the ignition coil malfunction.

[0129] In summary, the vehicle fault data management method based on fault classification and cloud collaboration provided in this embodiment achieves efficient management of vehicle fault data by storing and compressing vehicle fault data snapshots on demand and associating them with fault code identifiers and cloud index information. This improves the utilization efficiency of on-board storage resources and ensures the effective storage of fault codes and corresponding fault data snapshots, providing reliable data support for vehicle fault diagnosis.

[0130] It should be understood that, although Figure 2 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 2 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0131] To facilitate better implementation of the vehicle fault data management method based on fault classification and cloud collaboration in this application, this application also provides a vehicle fault data management device based on the aforementioned vehicle fault data management method based on fault classification and cloud collaboration. The meanings of the terms used are the same as in the aforementioned vehicle fault data management method based on fault classification and cloud collaboration, and specific implementation details can be found in the descriptions within the method embodiments.

[0132] Please see Figure 3 , Figure 3 The diagram below illustrates the structure of a vehicle fault data management device based on fault classification and cloud collaboration, as provided in this embodiment. Specifically, this device may include an information acquisition module 201, a query module 202, a compression module 203, and a storage module 204, as follows: The acquisition module 201 is used to acquire the current fault code and the corresponding fault data snapshot at the time of the fault occurrence in response to the triggering of a vehicle fault event; The query module 202 is used to query the vehicle's local index cache and determine whether it is necessary to store a fault data snapshot based on the storage flag corresponding to the current fault code recorded in the index cache. Compression module 203 is used to determine the target compression strategy from a variety of preset compression strategies according to the importance level corresponding to the current fault code recorded in the index cache if the storage flag indicates that storage is required, and to compress the fault data snapshot using the target compression strategy to generate a compressed data packet. The storage module 204 is used to associate and store the compressed data packet and the identifier of the current fault code in the vehicle memory, and to record the index information of the current fault code. The index information is used to retrieve the corresponding fault description information from the cloud.

[0133] Furthermore, in some embodiments, the query module 202 is also used for: Obtain the core mapping data of the fault classification mapping table from the cloud server; the core mapping data includes at least one of the following: fault code number, the importance level corresponding to the fault code number, and the storage flag corresponding to the fault code number. The core mapping data is parsed according to a preset binary format and stored in the vehicle's local non-volatile memory to form an index cache.

[0134] The default binary format data structure is as follows: each fault code entry occupies a fixed length of byte space, which is divided into multiple bit fields. These bit fields are used to store the fault code number, the importance level corresponding to the fault code number, and the storage flag corresponding to the fault code number.

[0135] Furthermore, in some embodiments, the query module 202 is also used for: The vehicle sends the current version information of the locally stored index cache to the cloud server. Receive the current version information from the cloud server and compare it with the latest version information stored in the cloud; If the current version information is inconsistent with the latest version information, the cloud server will send an incremental update data packet based on the difference to the vehicle; The vehicle receives and parses incremental update data packets, and uses these packets to update the locally stored index cache.

[0136] Furthermore, in some embodiments, the compression module 203 is specifically used for: Parse the index cache to obtain the importance level corresponding to the current fault code; If the importance level is the first preset level, then the target compression strategy is determined to be a lossless compression strategy. If the importance level is the second preset level, then the target compression strategy is determined to be a hybrid compression strategy. The hybrid compression strategy is used to retain the key parameter set in the fault data snapshot without loss, to perform precision trimming on the non-key parameter set in the fault data snapshot, and to compress the precision-trimmed non-key parameter set and the losslessly retained key parameter set.

[0137] Furthermore, in some embodiments, the rules for dividing the key parameter set and non-key parameter set are uniformly defined by the cloud server and synchronized to the vehicle's local machine along with the core mapping data; Furthermore, in some embodiments, precision trimming specifically involves converting floating-point parameters into integer parameters according to a preset number of bits to retain.

[0138] Furthermore, in some embodiments, the device further includes a discarding module for: If the storage flag indicates that storage is not required, the fault data snapshot is discarded, and only the code of the current fault code is recorded.

[0139] Furthermore, in some embodiments, the device further includes a diagnostic module, specifically used for: Receive fault read requests from diagnostic equipment; In response to a fault read request, the system sends the current fault code, compressed data packet, and index information to the diagnostic device. The diagnostic equipment sends a fault description retrieval request to the cloud server based on the index information; The diagnostic equipment receives and displays the structured fault description text returned by the cloud server.

[0140] Furthermore, in some embodiments, the apparatus further includes a detection module, specifically used for: When the diagnostic device detects that it cannot connect to the cloud server, the diagnostic device displays a locally stored simple fault message or indicates that it is currently in offline mode.

[0141] Furthermore, in some embodiments, the apparatus further includes a sorting module, specifically used for: Monitor the remaining storage space of the vehicle's onboard storage device. When the remaining storage space is lower than a preset threshold, trigger the storage space defragmentation process. In response to the storage space reorganization process, scan all compressed data packets already stored in the vehicle's on-board storage to obtain the importance level and storage timestamp of each compressed data packet; Based on the principle of prioritizing deletion based on the lowest priority and longest storage time, the compressed data packets to be deleted are determined from all compressed data packets; Delete the compressed data packets to be deleted, and retain a preset number of the most recent compressed data packets with the highest importance level.

[0142] Furthermore, in some embodiments, the apparatus further includes a verification module, specifically used for: When storing the compressed data packet to the vehicle's on-board storage, a corresponding checksum is generated based on the content of the compressed data packet; The verification code is associated with the compressed data packet and stored in the vehicle's on-board storage. When reading compressed data packets from the vehicle's on-board storage, the checksum of the compressed data packets is recalculated and compared with the checksum of the associated storage. If the comparison results are inconsistent, the compressed data packet is determined to be corrupted, and the storage block occupied by the compressed data packet in the vehicle's on-board storage is marked as unusable.

[0143] Specific limitations regarding the vehicle fault data management device based on fault classification and cloud collaboration can be found in the limitations of the vehicle fault data management method based on fault classification and cloud collaboration mentioned above, and will not be repeated here. Each module in the aforementioned vehicle fault data management device based on fault classification and cloud collaboration can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0144] The vehicle fault data management device based on fault classification and cloud collaboration provided in this embodiment achieves efficient management of vehicle fault data by storing and compressing vehicle fault data snapshots on demand and associating them with fault code identifiers and cloud index information. This improves the utilization efficiency of on-board storage resources and ensures the effective storage of fault codes and corresponding fault data snapshots, providing reliable data support for vehicle fault diagnosis.

[0145] Furthermore, embodiments of this application also provide an electronic device, such as... Figure 4 As shown, it illustrates a structural schematic diagram of the electronic device involved in the embodiments of this application, specifically: The electronic device may include components such as a processor 301 with one or more processing cores, a memory 302 with one or more computer-readable storage media, a power supply 303, and an input unit 304. Those skilled in the art will understand that... Figure 4 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein: The processor 301 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines, and performs various functions and processes data by running or executing software programs and / or modules stored in the memory 302, and by calling data stored in the memory 302, thereby providing overall monitoring of the electronic device. Optionally, the processor 301 may include one or more processing cores; preferably, the processor 301 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 301.

[0146] The memory 302 can be used to store software programs and modules. The processor 301 executes various functional applications and vehicle fault data management methods based on fault classification and cloud collaboration by running the software programs and modules stored in the memory 302. The memory 302 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 302 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 302 may also include a memory controller to provide the processor 301 with access to the memory 302.

[0147] The electronic device also includes a power supply 303 that supplies power to various components. Preferably, the power supply 303 can be logically connected to the processor 301 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 303 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0148] The electronic device may also include an input unit 304, which can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0149] Although not shown, the electronic device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 301 in the electronic device loads the executable files corresponding to the processes of one or more applications into the memory 302 according to the following instructions, and the processor 301 runs the applications stored in the memory 302 to realize various functions, as follows: In response to a vehicle malfunction event, the system retrieves the current fault code and a snapshot of the fault data at the time of the fault occurrence. It then queries the vehicle's local index cache and, based on the storage flag corresponding to the current fault code recorded in the cache, determines whether to store the fault data snapshot. If the storage flag indicates that storage is necessary, it selects a target compression strategy from a set of preset compression strategies based on the importance level of the current fault code recorded in the cache. The target compression strategy is then used to compress the fault data snapshot, generating a compressed data packet. This compressed data packet and the identifier of the current fault code are associated and stored in the vehicle's on-board storage. The index information of the current fault code is also recorded; this index information is used to retrieve the corresponding fault description information from the cloud.

[0150] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0151] This application embodiment achieves efficient management of vehicle fault data by storing vehicle fault data snapshots on demand and compressing them hierarchically, and by associating them with fault code identifiers and cloud index information. This improves the utilization efficiency of on-board storage resources and ensures the effective storage of fault codes and corresponding fault data snapshots, providing reliable data support for vehicle fault diagnosis.

[0152] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0153] Therefore, embodiments of this application provide a storage medium storing multiple instructions that can be loaded by a processor to execute steps in any of the vehicle fault data management methods based on fault classification and cloud collaboration provided in embodiments of this application. For example, the instructions can execute the following steps: In response to a vehicle malfunction event, the system retrieves the current fault code and a snapshot of the fault data at the time of the fault occurrence. It then queries the vehicle's local index cache and, based on the storage flag corresponding to the current fault code recorded in the cache, determines whether to store the fault data snapshot. If the storage flag indicates that storage is necessary, it selects a target compression strategy from a set of preset compression strategies based on the importance level of the current fault code recorded in the cache. The target compression strategy is then used to compress the fault data snapshot, generating a compressed data packet. This compressed data packet and the identifier of the current fault code are associated and stored in the vehicle's on-board storage. The index information of the current fault code is also recorded; this index information is used to retrieve the corresponding fault description information from the cloud.

[0154] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0155] The storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0156] Since the instructions stored in the storage medium can execute the steps in any of the vehicle fault data management methods based on fault classification and cloud collaboration provided in the embodiments of this application, the beneficial effects that any of the vehicle fault data management methods based on fault classification and cloud collaboration provided in the embodiments of this application can achieve can be realized. For details, please refer to the previous embodiments, which will not be repeated here.

[0157] The foregoing has provided a detailed description of a vehicle fault data management method and apparatus based on fault classification and cloud collaboration provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A vehicle fault data management method based on fault classification and cloud collaboration, characterized in that, include: In response to a vehicle malfunction event, obtain the current fault code and a snapshot of the corresponding fault data at the time of the fault occurrence; Query the vehicle's local index cache, and determine whether it is necessary to store the fault data snapshot based on the storage flag corresponding to the current fault code recorded in the index cache; If the storage flag indicates that storage is required, then according to the importance level corresponding to the current fault code recorded in the index cache, a target compression strategy is determined from a variety of preset compression strategies, and the target compression strategy is used to compress the fault data snapshot to generate a compressed data packet. The compressed data packet and the identifier of the current fault code are associated and stored in the vehicle's on-board storage, and the index information of the current fault code is recorded. The index information is used to obtain the corresponding fault description information from the cloud.

2. The vehicle fault data management method based on fault classification and cloud collaboration according to claim 1, characterized in that, Before querying the local index cache of the vehicle, the method further includes: Obtain the core mapping data of the fault classification mapping table from the cloud server; the core mapping data includes at least one of the following: fault code number, importance level corresponding to the fault code number, and storage flag corresponding to the fault code number. The core mapping data is parsed according to a preset binary format and stored in the vehicle's local non-volatile memory to form the index cache.

3. The vehicle fault data management method based on fault classification and cloud collaboration according to claim 2, characterized in that, The core mapping data for obtaining the fault classification mapping table from the cloud server includes: The vehicle sends the current version information of the locally stored index cache to the cloud server. The system receives the current version information from the cloud server and compares it with the latest version information stored in the cloud. If the current version information is inconsistent with the latest version information, the cloud server sends an incremental update data packet based on the difference to the vehicle; The vehicle receives and parses the incremental update data packet, and uses the incremental update data packet to update the locally stored index cache.

4. The vehicle fault data management method based on fault classification and cloud collaboration according to claim 1, characterized in that, The step of determining a target compression strategy from a set of preset compression strategies based on the importance level corresponding to the current fault code recorded in the index cache includes: Parse the index cache to obtain the importance level corresponding to the current fault code; If the importance level is the first preset level, then the target compression strategy is determined to be a lossless compression strategy; If the importance level is the second preset level, then the target compression strategy is determined to be a hybrid compression strategy; the hybrid compression strategy is used to retain the key parameter set in the fault data snapshot without loss, to perform precision trimming on the non-key parameter set in the fault data snapshot, and to compress the precision-trimmed non-key parameter set and the losslessly retained key parameter set.

5. The vehicle fault data management method based on fault classification and cloud collaboration according to claim 1, characterized in that, The method further includes: If the storage flag indicates that storage is not required, the fault data snapshot is discarded, and only the code of the current fault code is recorded.

6. The vehicle fault data management method based on fault classification and cloud collaboration according to claim 1, characterized in that, After associating and storing the compressed data packet and the identifier of the current fault code in the vehicle's on-board memory, and recording the index information of the current fault code, the method further includes: Receive fault read requests from diagnostic equipment; In response to the fault reading request, the code of the current fault code, the compressed data packet, and the index information are sent to the diagnostic device; The diagnostic device sends a fault description retrieval request to the cloud server based on the index information; The diagnostic device receives the structured fault description text returned by the cloud server and displays the structured fault description text.

7. The vehicle fault data management method based on fault classification and cloud collaboration according to claim 6, characterized in that, The method further includes: When the diagnostic device is detected to be unable to connect to the cloud server, the diagnostic device displays a locally stored simple fault message or indicates that it is currently in offline mode.

8. The vehicle fault data management method based on fault classification and cloud collaboration according to claim 1, characterized in that, The method further includes: Monitor the remaining storage space of the vehicle-mounted storage device, and trigger a storage space cleanup process when the remaining storage space is lower than a preset threshold; In response to the storage space organization process, all compressed data packets stored in the vehicle storage are scanned to obtain the importance level and storage timestamp of each compressed data packet. Based on the principle of prioritizing deletion based on the lowest priority and longest storage time, the compressed data packets to be deleted are determined from all the compressed data packets. Delete the compressed data packets to be deleted, and retain a preset number of the most recent compressed data packets with the highest importance level without deleting them.

9. The vehicle fault data management method based on fault classification and cloud collaboration according to claim 1, characterized in that, The method further includes: When the compressed data packet is stored in the vehicle-mounted storage, a corresponding checksum is generated based on the content of the compressed data packet; The verification code is associated with the compressed data packet and stored in the vehicle-mounted storage. When reading the compressed data packet from the vehicle-mounted storage, the checksum of the compressed data packet is recalculated and compared with the checksum stored in association; If the comparison results are inconsistent, the compressed data packet is determined to be corrupted, and the storage block occupied by the compressed data packet in the vehicle's on-board memory is marked as unusable.

10. A vehicle fault data management device based on fault classification and cloud collaboration, characterized in that, include: The acquisition module is used to acquire the current fault code and the corresponding fault data snapshot at the time of the fault occurrence in response to the triggering of a vehicle fault event. The query module is used to query the vehicle's local index cache and determine whether it is necessary to store the fault data snapshot based on the storage flag corresponding to the current fault code recorded in the index cache. The compression module is used to, if the storage flag indicates that storage is required, determine a target compression strategy from a variety of preset compression strategies according to the importance level corresponding to the current fault code recorded in the index cache, and use the target compression strategy to compress the fault data snapshot to generate a compressed data packet. The storage module is used to associate and store the compressed data packet and the identifier of the current fault code in the vehicle memory, and to record the index information of the current fault code. The index information is used to obtain the corresponding fault description information from the cloud.

Images