A fault code management method, device, equipment and medium of a vehicle
By configuring function identifier values for vehicle fault code management, the logical aggregation of diagnostic information and the decoupling of physical storage are achieved, solving the problems of high redundancy and excessive storage resource consumption in vehicle fault code management, improving fault diagnosis efficiency and maintainability, and meeting OBD regulatory requirements.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHINA FAW CO LTD
- Filing Date
- 2026-04-15
- Publication Date
- 2026-07-07
Smart Images
Figure CN122346112A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the technical field of automotive intelligence, and in particular to a method, device, equipment and medium for managing vehicle fault codes. Background Technology
[0002] With the accelerated pace of automotive intelligence and electrification, the functional complexity of onboard electronic control units (ECUs) is increasing exponentially. Taking the vehicle control unit (VCU) of new energy vehicles as an example, the number of monitored functions has expanded from 30-50 in traditional fuel vehicles to over 200, and each function must meet or exceed the ISO 26262 functional safety ASIL-B level requirements. Current mainstream diagnostic solutions strictly adhere to the AUTOSAR Classic platform's DEM (Diagnostic Event Manager) specification: each independent monitoring path is defined as a unique Dem_Event and assigned an independent Diagnostic Trouble Code (DTC). When a functional failure occurs, each Dem_Event triggered by each monitoring path generates a complete non-volatile (NV) record and reports it externally through the UDS (Unified Diagnostic Services) diagnostic service. However, the existing technology has the following key problems that urgently need to be solved: (1) High redundancy of diagnostic information and difficulty in locating the root cause of the fault: When a certain functional module fails, multiple related sensors or detection paths may trigger different Dem_Events at the same time, but generate the same DTC code (e.g., P0AA1). When faced with multiple duplicate DTCs displayed by the diagnostic tool, maintenance personnel find it difficult to quickly identify the core fault source and need to check each sensor path one by one, which significantly prolongs the fault diagnosis and maintenance cycle. (2) Excessive consumption of NV storage resources: Each DTC requires an independent NV storage entry (usually each record occupies 32-64 bytes). For a medium-sized controller containing 200-300 DTCs, redundant storage leads to a surge in NV space requirements, which constitutes a substantial bottleneck in embedded environments with limited hardware resources. (3) Risk of OBD regulatory compliance: In traditional solutions, multiple events with the same DTC code but different detection paths are identified as independent faults by OBD scanning tools, which may lead to abnormal accumulation of fault counts, thereby triggering false alarms, function degradation, or even unexpected shutdown. Therefore, how to manage vehicle fault codes has become a technical problem that cannot be ignored. Summary of the Invention
[0003] In view of this, the purpose of this application is to provide a method, device, equipment and medium for managing vehicle fault codes, which realizes the decoupling of logical aggregation and physical storage of diagnostic information, significantly reduces storage overhead while ensuring information integrity, and significantly improves fault diagnosis efficiency and maintainability.
[0004] This application provides a method for managing vehicle fault codes, the method comprising: Configure a corresponding function identifier value for each diagnostic event identifier; among them, diagnostic events that share the same diagnostic fault code and whose function identifier value is greater than the preset value belong to the same function group. Upon receiving a diagnostic event processing request, determine whether the diagnostic event belongs to the functional aggregation mode based on its functional identifier value. If it belongs to the function aggregation mode, only the single diagnostic fault code record corresponding to the function group is stored in the non-volatile memory. Based on the function identifier value, a bitwise OR operation is performed on the real-time status bytes of multiple diagnostic events belonging to the same function group to generate an aggregated status byte. The aggregated status byte is used to characterize the overall health of the function group.
[0005] In one possible implementation, the configuration of the function identifier value is achieved through a static configuration table, which is used to store the mapping relationship between each diagnostic event identifier and the function identifier value; wherein, a function identifier value of 0 indicates a traditional independent storage mode, and a function identifier value greater than 0 indicates a function aggregation mode.
[0006] In one possible implementation, performing a bitwise OR operation on the real-time status bytes of multiple diagnostic events belonging to the same functional group based on the function identifier value to generate an aggregated status byte includes: Query the configuration table based on the function identifier value to obtain a list of diagnostic event identifiers for multiple sub-paths belonging to the same function group; Read the real-time status bytes corresponding to each sub-path diagnostic event sequentially; Initialize the aggregated state variable, perform a bitwise OR operation between the real-time state byte of each sub-path diagnostic event read and a preset mask, and store the result in the aggregated state variable to generate the aggregated state byte.
[0007] In one possible implementation, the step of querying the configuration table based on the function identifier value to obtain a list of multiple sub-path diagnostic event identifiers belonging to the same function group includes: In response to a received unified diagnostic service request, the request parameters are parsed to determine the functional group to be read; Read the fault record corresponding to the function group from the non-volatile memory, and obtain its function identifier value and sub-path statistics; The function identifier value and sub-path statistics are encapsulated in an extended data record and returned.
[0008] In one possible implementation, after generating the aggregated status byte, the fault code management method further includes: In response to a service request to read diagnostic fault codes, multiple diagnostic events belonging to the same functional group are deduplicated based on the function identifier value to ensure that each functional group appears only once in the returned list of diagnostic fault codes.
[0009] In one possible implementation, before reading the fault record corresponding to the function group from the non-volatile memory and obtaining its function identifier value and sub-path statistics, the fault code management method further includes: Before creating a fault record, check whether there is already a fault record in the non-volatile memory that has the same diagnostic fault code as the current diagnostic event and whose function identifier value is greater than 0. If it does not exist, a new fault record is created in the non-volatile memory, and the diagnostic fault code, function identifier value and aggregate status information of the current diagnostic event are written into the fault record.
[0010] In one possible implementation, storing only a single diagnostic fault code record corresponding to the functional group in non-volatile memory includes: During the fault storage creation phase, the stored diagnostic fault code records are traversed. If the diagnostic fault code for the current diagnostic event already exists in non-volatile storage, skip creating a new storage record and update the aggregate state of the function group.
[0011] This application embodiment also provides a vehicle fault code management device, the fault code management device comprising: The configuration module is used to configure the corresponding function identifier value for each diagnostic event identifier; among them, diagnostic events that share the same diagnostic fault code and whose function identifier value is greater than the preset value belong to the same function group. The judgment module is used to determine whether a diagnostic event belongs to the functional aggregation mode based on the functional identifier value of the diagnostic event when a diagnostic event processing request is received. The aggregation module is used to store only a single diagnostic fault code record corresponding to the functional group in non-volatile memory if the function aggregation mode is in use, and to perform a bitwise OR operation on the real-time status bytes of multiple diagnostic events belonging to the same functional group based on the function identifier value to generate an aggregated status byte; the aggregated status byte is used to characterize the overall health of the functional group.
[0012] This application also provides an electronic device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, the steps of the vehicle fault code management method described above are performed.
[0013] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the vehicle fault code management method described above.
[0014] This application provides a vehicle fault code management method, apparatus, device, and medium. The fault code management method includes: configuring a corresponding function identifier value for each diagnostic event identifier; wherein diagnostic events sharing the same diagnostic fault code and whose function identifier values are greater than a preset value belong to the same function group; upon receiving a diagnostic event processing request, determining whether the event belongs to a function aggregation mode based on the function identifier value; if it belongs to a function aggregation mode, storing only a single diagnostic fault code record corresponding to the function group in a non-volatile memory, and performing a bitwise OR operation on the real-time status bytes of multiple diagnostic events belonging to the same function group based on the function identifier value to generate an aggregated status byte; the aggregated status byte is used to characterize the overall health of the function group. This achieves decoupling of logical aggregation and physical storage of diagnostic information, significantly reducing storage overhead while ensuring information integrity, and significantly improving fault diagnosis efficiency and maintainability.
[0015] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description
[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0017] Figure 1 A flowchart illustrating a vehicle fault code management method provided in an embodiment of this application; Figure 2 This is one of the structural schematic diagrams of a vehicle fault code management device provided in an embodiment of this application; Figure 3 A second schematic diagram of a vehicle fault code management device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. Based on the embodiments of this application, every other embodiment obtained by those skilled in the art without inventive effort falls within the scope of protection of this application.
[0019] First, the applicable application scenarios of this application will be introduced. This application can be applied to the technical field of automotive intelligence.
[0020] Research has revealed the following critical issues that urgently need to be addressed: (1) High redundancy of diagnostic information, making it difficult to locate the root cause of the fault: When a certain functional module fails, multiple associated sensors or detection paths may trigger different Dem_Events simultaneously, but generate the same DTC code (e.g., P0AA1). When faced with multiple duplicate DTCs displayed by the diagnostic tool, maintenance personnel find it difficult to quickly identify the core fault source and need to check each sensor path one by one, significantly extending the fault diagnosis and maintenance cycle. (2) Excessive consumption of NV storage resources: Each DTC requires an independent NV storage entry (usually each record occupies 32–64 bytes). For a medium-sized controller containing 200–300 DTCs, redundant storage leads to a surge in NV space requirements, constituting a substantial bottleneck in embedded environments with limited hardware resources. (3) Risk of OBD regulatory compliance: In traditional solutions, multiple events with the same DTC code but different detection paths are identified as independent faults by OBD scanning tools, which may lead to abnormal accumulation of fault counts, thereby triggering false alarms, function degradation, or even unexpected shutdown. Therefore, how to manage vehicle fault codes has become a significant technical issue.
[0021] Based on this, this application provides a vehicle fault code management method that decouples the logical aggregation and physical storage of diagnostic information, significantly reduces storage overhead while ensuring information integrity, and significantly improves fault diagnosis efficiency and maintainability.
[0022] Please see Figure 1 , Figure 1This is a flowchart illustrating a vehicle fault code management method provided in an embodiment of this application. Figure 1 As shown in the figure, the fault code management method provided in this application includes: S101: Configure a corresponding function identifier value for each diagnostic event identifier; among them, diagnostic events that share the same diagnostic fault code and whose function identifier value is greater than the preset value belong to the same function group.
[0023] In this step, a corresponding function identifier value is configured for each diagnostic event identifier.
[0024] In one possible implementation, the configuration of the function identifier value is achieved through a static configuration table, which is used to store the mapping relationship between each diagnostic event identifier and the function identifier value; wherein, a function identifier value of 0 indicates a traditional independent storage mode, and a function identifier value greater than 0 indicates a function aggregation mode.
[0025] S102: Upon receiving a diagnostic event processing request, determine whether the diagnostic event belongs to the functional aggregation mode based on the functional identifier value of the diagnostic event.
[0026] In this step, upon receiving a diagnostic event processing request, it is determined whether the diagnostic event belongs to the functional aggregation mode based on the functional identifier value of the diagnostic event.
[0027] Here, if the function identifier value is greater than 0, it belongs to the function aggregation mode.
[0028] S103: If it is a function aggregation mode, then only a single diagnostic fault code record corresponding to the function group is stored in the non-volatile memory. Based on the function identifier value, a bitwise OR operation is performed on the real-time status bytes of multiple diagnostic events belonging to the same function group to generate an aggregated status byte. The aggregated status byte is used to characterize the overall health of the function group.
[0029] In this step, if it is a function aggregation mode, only a single diagnostic fault code record corresponding to the function group is stored in the non-volatile memory. The real-time status bytes of multiple diagnostic events belonging to the same function group are bitwise ORed according to the function identifier value to generate an aggregated status byte.
[0030] Here, the aggregated status byte is used to characterize the overall health of the functional group.
[0031] In one possible implementation, performing a bitwise OR operation on the real-time status bytes of multiple diagnostic events belonging to the same functional group based on the function identifier value to generate an aggregated status byte includes: A: Query the configuration table based on the function identifier value to obtain a list of diagnostic event identifiers for multiple sub-paths belonging to the same function group.
[0032] Here, the function group association table is queried based on the FID value (Function Identifier value) to obtain the list of sub-path diagnostic event identifiers. The system pre-defines a FunctionGroupMappingTable, where the key is the FID value and the value is a dynamic array consisting of all `Dem_EventId` values associated with that FID. When `StatusOfDTC_Update()` detects the target FID value of the currently pending DTC (e.g., FID=5), the list of function groups corresponding to that FID is obtained through a table lookup operation. Taking the high-voltage insulation detection function of the new energy VCU as an example, the sub-path `Dem_EventId` associated with FID=5 includes: `0x2101` (positive insulation detection), `0x2102` (negative insulation detection), and `0x2103` (insulation detection circuit self-test). This list can be constructed during the DEM initialization phase using a static array or linked list structure and stored in RAM for real-time access.
[0033] B: Read the real-time status bytes corresponding to each sub-path diagnostic event in sequence.
[0034] C: Initialize the aggregated state variable, perform a bitwise OR operation between the real-time state byte of each sub-path diagnostic event read and the preset mask, and store the result in the aggregated state variable to generate the aggregated state byte.
[0035] Here, the aggregated state variable is initialized, the real-time state byte of each sub-path diagnostic event is bitwise ORed with a preset mask, and the result is stored in the aggregated state variable to generate the aggregated state byte.
[0036] The process involves querying the function group association table based on the FID value to obtain a list of all sub-path EventIDs, and then sequentially reading the real-time status bytes (e.g., the Dem_DtcStsByte array) of each sub-path. The aggregated status variable `aggregated_status` is initialized to 0, and a bitwise OR operation is performed on the status byte of each sub-path: `aggregated_status|=(sub_status&DTC_STATUS_MASK)`. A mask is applied to retain valid status bits: `aggregated_status&=DTC_AVAILABILITY_MASK`. The aggregated status value is then written to the corresponding entry in the NV storage, triggering a status change notification and updating the diagnostic instrument interface display.
[0037] In one possible implementation, the step of querying the configuration table based on the function identifier value to obtain a list of multiple sub-path diagnostic event identifiers belonging to the same function group includes: In response to a received unified diagnostic service request, the request parameters are parsed to determine the function group to be read; the fault record corresponding to the function group is read from the non-volatile memory to obtain its function identifier value and sub-path statistics; the function identifier value and sub-path statistics are encapsulated in an extended data record and returned.
[0038] Here, the system receives the UDS0x190x06 service request, parses the request parameters (such as the record number RecNum), and locates the NV storage strip in the corresponding FID group based on RecNum. It reads metadata such as the FID value and number of subpaths from the storage entry and encapsulates extended data records in a standard format: Record 0x04: FID value (1 byte); Records 0x01-0x03: Subpath status counters (1 byte each). The encapsulated extended data is appended to the standard response message, and the complete response data packet is sent to the diagnostic instrument.
[0039] In one possible implementation, after generating the aggregated status byte, the fault code management method further includes: In response to a service request to read diagnostic fault codes, multiple diagnostic events belonging to the same functional group are deduplicated based on the function identifier value to ensure that each functional group appears only once in the returned list of diagnostic fault codes.
[0040] Here, we listen for service requests from UDS0x03 / 0x07 / 0x0A and determine the filtering rules based on the service type (e.g., 0x03 only returns the latest fault). Before the service response, we lock the Dsm_Fid_Storge array, iterate through the NV storage records, and select only the first record of the untagged FID group. We construct a DTC list containing aggregated status codes, append FID extended data records (if the service type supports it), unlock the storage array, and complete the response data transmission.
[0041] In one possible implementation, before reading the fault record corresponding to the function group from the non-volatile memory and obtaining its function identifier value and sub-path statistics, the fault code management method further includes: Before creating a fault record, check whether a fault record with the same diagnostic fault code and a function identifier value greater than 0 already exists in the non-volatile memory. If not, create a new fault record in the non-volatile memory and write the diagnostic fault code, function identifier value, and aggregate status information of the current diagnostic event into the fault record.
[0042] Here, before creating a fault record, it is checked whether a fault record with the same diagnostic fault code as the current diagnostic event and a function identifier value greater than 0 already exists in the non-volatile memory; if not, a new fault record is created in the non-volatile memory, and the diagnostic fault code, function identifier value, and aggregate status information of the current diagnostic event are written into the fault record.
[0043] The process involves accessing the reported DTC flag array Dsm_Fid_Storge in RAM, iterating through the array elements, comparing the DTC code of the current event with the DTC list stored in the array, and if a duplicate DTC is found (Dsm_Fid_Storge[k] == current_dtc), the deduplication flag report_flag is set to 1 and the iteration stops. If no duplicate record is found, report_flag is set to 0 and the storage process continues. When report_flag=0, a free entry is searched in NV storage, and the key information such as the DTC code, FID value, and aggregation status bit of the current event is written to NV storage. The Dsm_Fid_Storge array is then updated to mark the DTC as stored.
[0044] In one possible implementation, storing only a single diagnostic fault code record corresponding to the functional group in non-volatile storage includes: during the fault storage creation phase, traversing the already stored diagnostic fault code records; if the diagnostic fault code of the current diagnostic event already exists in non-volatile storage, skipping the creation of a new storage record and updating the aggregation state of the functional group.
[0045] In a specific implementation, Step 1: Fault Trigger: After the vehicle is submerged in water, the positive electrode insulation resistance drops to 120kΩ, Dem_Event0x2101 sets Dsm_DtcStsByte[0x2101]=0x0F, the negative electrode and circuit path are normal, and the corresponding status byte is 0x50. Step 2: Status Aggregation: The DEM main function periodically calls StatusOfDTC_Update(), detects that Dem_DidNumberTable[0x2101]=5, and executes a while loop aggregation: L_Dsm_DtcStsByte|=0x0F|0x50|0x50=0x5F, and finally Dsm_DtcStsByte[master_P0AA1]=0x5F&0xEF=0x0F (confirmedDTC=1). Step 3: Storage Creation: Upon initial triggering, Dsm_FID_Flag=0, calling FaultStoreCreate() to create a single record, and writing to NV storage: Dsm_NvData.FltStore_VA[0]={DTC=0xP0AA1,Index=0x2101,FaultSt=DEBOUNCED,...}. Subsequent negative or circuit faults will not create new records, only update the status bits. Step 4: Diagnostic Instrument Interaction: Service 0x1902: Returns P0AA1 (0x0F) with only one record, Service 0x1906 (RecNum=0x04): Returns 0x05 (FID value), Service 0x1904 Read Snapshot: Obtains real-time voltage values from three sensors.
[0046] In this application, (1) multi-path diagnostic information aggregation for the same functional failure is achieved: multiple failure events with the same DTC code but different detection paths are grouped together through the FID mechanism, presenting a single failure view to the outside world, while retaining complete path information internally. (2) Storage efficiency is improved while ensuring information integrity: multiple DTCs in the same FID group occupy only one NV storage record, and the status of each sub-path is saved through Extended Data Record, saving more than 30% of storage space. (3) The OBD regulations require uniqueness of failures: the UDS service 0x03 / 0x07 / 0x0A returns a filtered list of unique DTCs to avoid duplicate reports, while the 0x190x06 service provides FID extended data to achieve a balance between regulatory compliance and diagnostic depth.
[0047] This application provides a vehicle fault code management method, which includes: configuring a corresponding function identifier value for each diagnostic event identifier; wherein diagnostic events sharing the same diagnostic fault code and whose function identifier values are greater than a preset value belong to the same function group; upon receiving a diagnostic event processing request, determining whether the event belongs to a function aggregation mode based on the function identifier value; if it belongs to a function aggregation mode, storing only a single diagnostic fault code record corresponding to the function group in a non-volatile memory, and performing a bitwise OR operation on the real-time status bytes of multiple diagnostic events belonging to the same function group based on the function identifier value to generate an aggregated status byte; the aggregated status byte is used to characterize the overall health of the function group. This method achieves decoupling of logical aggregation and physical storage of diagnostic information, significantly reducing storage overhead while ensuring information integrity, and significantly improving fault diagnosis efficiency and maintainability.
[0048] Please see Figure 2 , Figure 3 , Figure 2 This is one of the structural schematic diagrams of a vehicle fault code management device provided in an embodiment of this application; Figure 3 This is a second schematic diagram of a vehicle fault code management device provided in an embodiment of this application. Figure 2 As shown, the fault code management device 200 includes: Configuration module 210 is used to configure a corresponding function identifier value for each diagnostic event identifier; wherein, diagnostic events that share the same diagnostic fault code and whose function identifier value is greater than a preset value belong to the same function group. The judgment module 220 is used to determine whether a diagnostic event belongs to a functional aggregation mode based on the function identifier value of the diagnostic event when a diagnostic event processing request is received. The aggregation module 230 is used to store only a single diagnostic fault code record corresponding to the functional group in the non-volatile memory if it belongs to the functional aggregation mode, and to perform a bitwise OR operation on the real-time status bytes of multiple diagnostic events belonging to the same functional group based on the functional identifier value to generate an aggregated status byte; the aggregated status byte is used to characterize the overall health of the functional group.
[0049] Furthermore, the aggregation module 230 is used to perform a bitwise OR operation on the real-time status bytes of multiple diagnostic events belonging to the same functional group based on the function identifier value, to generate an aggregated status byte: Query the configuration table based on the function identifier value to obtain a list of diagnostic event identifiers for multiple sub-paths belonging to the same function group; Read the real-time status bytes corresponding to each sub-path diagnostic event sequentially; Initialize the aggregated state variable, perform a bitwise OR operation between the real-time state byte of each sub-path diagnostic event read and a preset mask, and store the result in the aggregated state variable to generate the aggregated state byte.
[0050] Furthermore, the aggregation module 230 is used to query the configuration table based on the function identifier value to obtain a list of multiple sub-path diagnostic event identifiers belonging to the same function group: In response to a received unified diagnostic service request, the request parameters are parsed to determine the functional group to be read; Read the fault record corresponding to the function group from the non-volatile memory, and obtain its function identifier value and sub-path statistics; The function identifier value and sub-path statistics are encapsulated in an extended data record and returned.
[0051] Furthermore, such as Figure 3 As shown, the fault code management device 200 also includes a deduplication module 240, which is used for: In response to a service request to read diagnostic fault codes, multiple diagnostic events belonging to the same functional group are deduplicated based on the function identifier value to ensure that each functional group appears only once in the returned list of diagnostic fault codes.
[0052] Furthermore, such as Figure 3 As shown, the fault code management device 200 also includes a creation module 250, which is used for: Before creating a fault record, check whether there is already a fault record in the non-volatile memory that has the same diagnostic fault code as the current diagnostic event and whose function identifier value is greater than 0. If it does not exist, a new fault record is created in the non-volatile memory, and the diagnostic fault code, function identifier value and aggregate status information of the current diagnostic event are written into the fault record.
[0053] Furthermore, the aggregation module 230 is used to store only a single diagnostic fault code record corresponding to the functional group in the non-volatile memory: During the fault storage creation phase, the stored diagnostic fault code records are traversed. If the diagnostic fault code for the current diagnostic event already exists in non-volatile storage, skip creating a new storage record and update the aggregate state of the function group.
[0054] This application provides a vehicle fault code management device, comprising: a configuration module for configuring a corresponding function identifier value for each diagnostic event identifier; wherein diagnostic events sharing the same diagnostic fault code and having a function identifier value greater than a preset value belong to the same function group; a judgment module for determining whether a diagnostic event belongs to a function aggregation mode based on the function identifier value of the diagnostic event when a diagnostic event processing request is received; and an aggregation module for storing only a single diagnostic fault code record corresponding to the function group in a non-volatile memory if it belongs to the function aggregation mode, and performing a bitwise OR operation on the real-time status bytes of multiple diagnostic events belonging to the same function group based on the function identifier value to generate an aggregated status byte; the aggregated status byte is used to characterize the overall health of the function group. This achieves decoupling of logical aggregation and physical storage of diagnostic information, significantly reducing storage overhead while ensuring information integrity, and significantly improving fault diagnosis efficiency and maintainability.
[0055] Please see Figure 4 , Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 4 As shown, the electronic device 400 includes a processor 410, a memory 420, and a bus 430.
[0056] The memory 420 stores machine-readable instructions executable by the processor 410. When the electronic device 400 is running, the processor 410 communicates with the memory 420 via the bus 430. When the machine-readable instructions are executed by the processor 410, they can perform the operations described above. Figure 1 The steps of the vehicle fault code management method in the illustrated method embodiment can be found in the method embodiment for specific implementation, and will not be repeated here.
[0057] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can perform the above-described actions. Figure 1 The steps of the vehicle fault code management method in the illustrated method embodiment can be found in the method embodiment for specific implementation, and will not be repeated here.
[0058] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0059] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the shown or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.
[0060] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0061] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0062] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0063] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The scope of protection of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A method for managing vehicle fault codes, characterized in that, The fault code management method includes: Configure a corresponding function identifier value for each diagnostic event identifier; among them, diagnostic events that share the same diagnostic fault code and whose function identifier value is greater than the preset value belong to the same function group. Upon receiving a diagnostic event processing request, determine whether the diagnostic event belongs to the functional aggregation mode based on its functional identifier value. If it belongs to the function aggregation mode, only the single diagnostic fault code record corresponding to the function group is stored in the non-volatile memory. Based on the function identifier value, a bitwise OR operation is performed on the real-time status bytes of multiple diagnostic events belonging to the same function group to generate an aggregated status byte. The aggregated status byte is used to characterize the overall health of the function group.
2. The fault code management method according to claim 1, characterized in that, The configuration of the function identifier value is achieved through a static configuration table, which is used to store the mapping relationship between each diagnostic event identifier and the function identifier value; wherein, a function identifier value of 0 indicates the traditional independent storage mode, and a function identifier value greater than 0 indicates the function aggregation mode.
3. The fault code management method according to claim 1, characterized in that, The step of performing a bitwise OR operation on the real-time status bytes of multiple diagnostic events belonging to the same functional group based on the function identifier value to generate an aggregated status byte includes: Query the configuration table based on the function identifier value to obtain a list of diagnostic event identifiers for multiple sub-paths belonging to the same function group; Read the real-time status bytes corresponding to each sub-path diagnostic event sequentially; Initialize the aggregated state variable, perform a bitwise OR operation between the real-time state byte of each sub-path diagnostic event read and a preset mask, and store the result in the aggregated state variable to generate the aggregated state byte.
4. The fault code management method according to claim 3, characterized in that, The step of querying the configuration table based on the function identifier value to obtain a list of multiple sub-path diagnostic event identifiers belonging to the same function group includes: In response to a received unified diagnostic service request, the request parameters are parsed to determine the functional group to be read; Read the fault record corresponding to the function group from the non-volatile memory, and obtain its function identifier value and sub-path statistics; The function identifier value and sub-path statistics are encapsulated in an extended data record and returned.
5. The fault code management method according to claim 1, characterized in that, After generating the aggregated status bytes, the fault code management method further includes: In response to a service request to read diagnostic fault codes, multiple diagnostic events belonging to the same functional group are deduplicated based on the function identifier value to ensure that each functional group appears only once in the returned list of diagnostic fault codes.
6. The fault code management method according to claim 1, characterized in that, Before reading the fault record corresponding to the function group from the non-volatile memory and obtaining its function identifier value and sub-path statistics, the fault code management method further includes: Before creating a fault record, check whether there is already a fault record in the non-volatile memory that has the same diagnostic fault code as the current diagnostic event and whose function identifier value is greater than 0. If it does not exist, a new fault record is created in the non-volatile memory, and the diagnostic fault code, function identifier value and aggregate status information of the current diagnostic event are written into the fault record.
7. The fault code management method according to claim 1, characterized in that, The storage of only a single diagnostic fault code record corresponding to the functional group in non-volatile memory includes: During the fault storage creation phase, the stored diagnostic fault code records are traversed. If the diagnostic fault code for the current diagnostic event already exists in non-volatile storage, skip creating a new storage record and update the aggregate state of the function group.
8. A vehicle fault code management device, characterized in that, The fault code management device includes: The configuration module is used to configure the corresponding function identifier value for each diagnostic event identifier; among them, diagnostic events that share the same diagnostic fault code and whose function identifier value is greater than the preset value belong to the same function group. The judgment module is used to determine whether a diagnostic event belongs to the functional aggregation mode based on the functional identifier value of the diagnostic event when a diagnostic event processing request is received. The aggregation module is used to store only a single diagnostic fault code record corresponding to the functional group in non-volatile memory if the function aggregation mode is in use, and to perform a bitwise OR operation on the real-time status bytes of multiple diagnostic events belonging to the same functional group based on the function identifier value to generate an aggregated status byte; the aggregated status byte is used to characterize the overall health of the functional group.
9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. The machine-readable instructions are executed by the processor to perform the steps of the vehicle fault code management method as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the vehicle fault code management method as described in any one of claims 1 to 7.