Fault recording methods, devices, vehicles and storage media

Abstract

This application provides a fault recording method, apparatus, vehicle, and storage medium. The method, applied in the vehicle field, includes: acquiring fault diagnostic data corresponding to a fault type identifier in the vehicle; identifying unreported fault data based on the fault diagnostic data; determining the group number of the unreported fault data and its fault status storage location in a network management message based on the fault type identifier of the unreported fault data; writing the group number to the group number storage location in the network management message; determining the value of the fault status storage location as a first preset value; and reporting the fault status in a network management message. This method can identify unreported fault data that needs to be reported from the diagnostic fault data and report the fault diagnostic data using a network management message, improving the convenience of reporting and enabling timely recording of vehicle faults.

Description

Technical Field

[0001] This application relates to the field of vehicles, and more particularly to fault recording methods, devices, vehicles, and storage media. Background Technology

[0002] DTC stands for Diagnostic Trouble Code. Various systems and components in a vehicle are equipped with sensors and controllers to monitor and control their operating status. When a system or component malfunctions, the corresponding controller generates a specific fault code to indicate what the problem is. Reading diagnostic fault codes on a vehicle typically requires specialized diagnostic tools, such as OBD scanning tools or automotive diagnostic tools. These tools connect to the vehicle's diagnostic interface to access the vehicle's ECU (Engine Control Unit) or other controllers to obtain the fault codes and data stored therein.

[0003] Using a diagnostic tool in conjunction with UDS service to read the vehicle's current and historical faults through diagnostic protocols not only relies on diagnostic equipment but also cannot record the time when the fault occurred, making it inconvenient to remotely troubleshoot with engineers. Summary of the Invention

[0004] This application provides a fault recording method, apparatus, vehicle, and storage medium, aiming to reduce reliance on diagnostic equipment and improve the efficiency of engineers in troubleshooting. The technical solution is as follows:

[0005] Firstly, embodiments of this specification provide a fault recording method, including:

[0006] Acquire fault diagnosis data from the vehicle corresponding to the fault type identifier; the fault type identifier is used to indicate the fault detection type.

[0007] Based on the fault diagnosis data, it was confirmed that no fault data was reported;

[0008] Based on the fault type identifier of the unreported fault data, the group number of the unreported fault data and the fault status storage location in the network management message are confirmed.

[0009] Write the group number into the group number storage location in the network management message, set the value of the fault status storage location to a first preset value, and report the network management message; the first preset value is used to indicate that the fault type corresponding to the fault status storage location is a fault status.

[0010] Secondly, embodiments of this specification provide a fault recording device, comprising:

[0011] The acquisition module is used to acquire fault diagnosis data in the vehicle corresponding to the fault type identifier; the fault type identifier is used to indicate the fault detection type.

[0012] The confirmation module is used to confirm, based on the fault diagnosis data, that no fault data has been reported.

[0013] The location confirmation module is used to confirm the group number of the unreported fault data and the fault status storage location in the network management message based on the fault type identifier of the unreported fault data.

[0014] The message generation module is used to write the group number into the group number storage location in the network management message, determine the value of the fault status storage location as a first preset value, and report the network management message; the first preset value is used to indicate that the fault type identifier corresponding to the fault status storage location is a fault status.

[0015] Thirdly, embodiments of this specification provide a vehicle, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the steps of the method described above.

[0016] Fourthly, embodiments of this specification provide a computer-readable storage medium storing a computer program that, when executed, performs the steps of the method described above.

[0017] In the embodiments of this specification, fault diagnosis data corresponding to the fault type identifier in the vehicle is obtained. Based on the fault diagnosis data, unreported fault data is identified. According to the fault type identifier of the unreported fault data, the group number of the unreported fault data and its fault status storage location in the network management message are determined. The group number is written to the group number storage location in the network management message, and the value of the fault status storage location is set as a first preset value. The network management message is then reported. This method can identify unreported fault data from the diagnostic fault data and report the fault diagnosis data using network management messages, improving the convenience of reporting and enabling timely recording of vehicle faults. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of a scenario for a fault recording method provided in an embodiment of this specification;

[0019] Figure 2 This is a flowchart illustrating a fault recording method provided in an embodiment of this specification;

[0020] Figure 3 This is a flowchart illustrating a fault recording method provided in an embodiment of this specification;

[0021] Figure 4 This is a schematic diagram illustrating an example of a fault recording method provided in the embodiments of this specification;

[0022] Figure 5 This is a schematic diagram of the structure of a fault recording device provided in the embodiments of this specification;

[0023] Figure 6 This is a structural schematic diagram of a vehicle provided in the embodiments of this specification. Detailed Implementation

[0024] The technical solutions in this application will now be described clearly and in detail with reference to the accompanying drawings. In the description of the embodiments in this specification, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments in this specification, "multiple" refers to two or more than two.

[0025] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0026] Figure 1 This is a schematic diagram of a fault recording method provided in the embodiments of this specification.

[0027] For example, such as Figure 1 As shown, when a system or component of a vehicle malfunctions, the OBD (On-Board Diagnostics) system detects and records the corresponding fault data. If the vehicle owner or technician wants to obtain the vehicle's fault data, they need to read these codes using diagnostic tools such as a vehicle diagnostic tool. Vehicle diagnostic tools typically connect to the vehicle via an OBDII interface or a specific interface provided by the vehicle manufacturer, which is inconvenient for users to obtain vehicle fault information in a timely manner and requires reliance on the equipment.

[0028] Based on the above, this specification proposes a fault recording method that can acquire fault diagnosis data in a vehicle corresponding to a fault type identifier. The fault type identifier is used to indicate the clapping detection type. Based on the fault diagnosis data, it is confirmed that no fault data has been reported. Then, based on the fault type identifier of the no-reported fault data, the group number of the no-reported fault data and the fault status storage location in the network management message are confirmed. The group number is written into the group number storage location in the network management message, the value of the fault status storage location is determined as a first preset value, and the network management message is reported. Using this method, when the vehicle's OBD detects a fault in a vehicle system or component, the vehicle processing system (e.g., the electronic control unit) can generate fault diagnostic data corresponding to the fault type identifier, identify unreported fault data that needs to be reported, and update or set the stored data of the network management message based on the fault type identifier of the unreported fault data to obtain a processed network management message. The ECU then sends this network management message to the server, which can then obtain the vehicle's fault data through the network management message. This eliminates the need for additional diagnostic equipment to be connected and debugged on the vehicle, enabling more efficient fault data reporting so that users can perform remote vehicle diagnostics or record vehicle faults in a timely manner.

[0029] The fault recording method provided in this specification will be described in detail below with reference to specific embodiments.

[0030] Figure 2 This is a flowchart illustrating a fault recording method provided in an embodiment of this specification. It should be understood that this method can be applied to... Figure 1 In vehicles, this can specifically be applied to the electronic control unit (ECU) in the vehicle.

[0031] like Figure 2 As shown, the method in the embodiments of this specification may include the following steps S101-S103.

[0032] S101, Obtain fault diagnosis data in the vehicle corresponding to the fault type identifier;

[0033] In one embodiment, a fault type identifier is used to indicate the fault detection type. Fault detection types include the detection and diagnosis of vehicle engines, chassis, body, and accessories, as well as the detection of vehicle exhaust pollutants and noise. After performing the above-mentioned fault detection types, fault diagnosis data corresponding to each fault detection type can be obtained.

[0034] In one feasible implementation, in order to facilitate the recording of vehicle faults, a standard protocol is usually used to record the vehicle fault type as a vehicle fault code. Therefore, in the embodiments of this specification, the fault type identifier can be a vehicle fault code.

[0035] In another feasible implementation, fault type identifiers corresponding to different fault detection types can be manually set. For example, fault detection types can be numbered according to their importance from highest to lowest to obtain fault type identifiers. For instance, if the fault detection type is the transmission system, the fault diagnosis data could be P194600. P194600 indicates a powertrain fault, specifically a fault unique to the vehicle manufacturer, namely fault 46 in the transmission system, and the corresponding fault type identifier could be 167.

[0036] Optionally, the ECU can perform periodic checks on the vehicle at certain intervals to obtain fault diagnosis data. This fault diagnosis data can be the fault diagnosis data acquired at the current moment.

[0037] S102, Based on the fault diagnosis data, confirm that no fault data has been reported;

[0038] In one embodiment, unreported fault data refers to faulty detection results that were not reported to the server. The server can be located in the cloud. It is understood that the fault diagnosis data includes detection results for various fault detection types; those with faults are the parts requiring attention. Therefore, unreported fault data can be identified from the fault diagnosis data.

[0039] S103, Based on the fault type identifier of the unreported fault data, confirm the group number of the unreported fault data and the fault status storage location in the network management message;

[0040] In one embodiment, a fault type identifier corresponding to the unreported fault data is identified in the fault type identifier. For example, if the unreported fault data is engine ignition failure, the corresponding fault type identifier is 2. It is understood that each fault type identifier can be uniquely identified by the group number and fault status storage location recorded in the network management message; that is, the correspondence between the fault type identifier, group number, and fault status storage location can be pre-stored. For example, if the fault type identifier is 2, its group number could be 1, and its fault status storage location could be the 2nd position. Bits can be pre-allocated in the network management message for storing the group number and fault status. The network management message can have multiple fault status storage locations, and the fault status storage location corresponding to the unreported fault data can be one or more of these locations.

[0041] For example, a network management message (NM) typically includes 8 bytes (byte0-byte7), including some empty bytes, with each byte containing 16 bits. Custom information can be set in the empty bytes according to actual needs; therefore, in this embodiment, the empty bytes in the NM message can be used to store fault data. For example, 11 bits can be allocated in the NM message as fault status storage locations, and 5 bits as group number storage locations. Specifically, the binary number composed of bits 7-3 of NM-byte4 serves as the group number, and the largest decimal integer it can represent is 2 to the power of 5 minus 1, which is 31. The group number can represent 32 fault groups from 0 to 31. Bits 2-0 of NM-byte4 (bits 10-8 in the 11-bit fault status storage location) and bit 7-0 of NM-byte6 (bits 7-0 in the 11-bit fault status storage location) are grouped into 11 groups, with each bit corresponding to a fault detection type; that is, each group can store 11 fault detection types. In the prior art, there are 342 fault detection types, while the byte allocation method of the embodiment of this specification can store 352 fault detection types (fault type identifiers), thereby enabling sufficient recording of various faults occurring in the vehicle.

[0042] S104, write the group number into the group number storage location in the network management message, determine the value of the fault status storage location as a first preset value, and report the network management message.

[0043] In one embodiment, the group number corresponding to the fault type identifier of the unreported fault data is written into the group number storage location in the network management message, and the value of the fault status storage location is determined as a first preset value to obtain the network management message to be reported. The first preset value indicates that the fault type identifier corresponding to the fault status storage location is a fault status. The fault status storage location in the network management message can have a default value, for example, a second preset value. When the fault type identifier corresponding to the fault status storage location is a fault status, the value of the fault status storage location can be determined as the first preset value. For example, the first preset value can be 1. Optionally, the value of the fault status storage location in the network management message can also be empty. After the value of the fault status storage location is confirmed based on the unreported fault data, it can be assigned a value, that is, confirmed as the first preset value.

[0044] In ECU wake-up mode, the ECU can continuously send network management messages to the server. When the server receives a network management message containing a fault type identifier, it can determine whether the corresponding fault type identifier is a fault state based on the value of the fault status storage location in the network management message, that is, whether the corresponding fault detection type has a fault. For example, if the value of the second bit in the fault status storage location of the network management message is the first preset value and the group number is 1, then by looking up the corresponding relationship, it can be confirmed that the fault occurring in the vehicle is engine ignition failure.

[0045] Optionally, the server can determine the time of the fault occurrence based on the time the network management message is received. It is understood that the network management message can be generated and sent when the ECU detects a fault, thus allowing the time of fault occurrence to be determined based on the time the network management message is received, thereby enabling the recording of the fault occurrence time.

[0046] In the embodiments of this specification, fault diagnosis data corresponding to the fault type identifier in the vehicle is obtained. Based on the fault diagnosis data, unreported fault data is identified. According to the fault type identifier of the unreported fault data, the group number of the unreported fault data and its fault status storage location in the network management message are determined. The group number is written to the group number storage location in the network management message, and the value of the fault status storage location is set as a first preset value. The network management message is then reported. This method can identify unreported fault data with reporting requirements from the diagnostic fault data and report the unreported fault data using network management messages, improving the convenience of reporting and enabling timely recording of vehicle faults.

[0047] Please see Figure 3 This is a flowchart illustrating a fault recording method provided in an embodiment of this specification. Figure 3 As shown, the method in the embodiments of this specification may include the following steps S201-S210.

[0048] S201, Obtain fault diagnosis data in the vehicle corresponding to the fault type identifier;

[0049] Specifically, please refer to the description of step S101 in the above embodiment of the specification, which will not be repeated here.

[0050] S202, if the fault diagnosis data indicates that the fault type is identified as a fault state, then the fault diagnosis data is confirmed as unreported fault data;

[0051] In one embodiment, if the fault diagnosis data indicates that the fault type identifier is in a fault state, that is, the current detection result of the fault detection type corresponding to the fault type identifier is that a fault exists, then it means that the event of the fault detection type having a fault needs to be reported. In other words, the fault diagnosis data can be treated as unreported fault data. It is understood that the fault diagnosis data can include detection results corresponding to multiple fault type identifiers. Therefore, the presence or absence of a fault type identifier can be confirmed one by one based on the fault diagnosis data to identify the fault type identifier with a fault, and the event of the fault type identifier having a fault can be treated as unreported fault data.

[0052] S203, if the fault diagnosis data indicates that the fault type identifier is in a non-fault state, then confirm whether the fault type identifier has an unreported flag;

[0053] In one embodiment, if the fault diagnosis data indicates that the fault type identifier is in a non-fault state, that is, the current detection result of the fault detection type corresponding to the fault type identifier is that there is no fault, it is necessary to further confirm whether the detection result of this fault detection type in historical fault diagnosis is that there is a fault and it has not been reported, that is, to confirm whether it has an unreported mark. It is understood that since the number of faults reported in a network management message at one time is limited, when the number of fault type identifiers with faults exceeds the number that the network management message can carry, the faults are reported according to their priority, and an unreported mark is added to the fault type identifiers that have not been reported, so that the faults can be reported through network management messages in subsequent rounds, ensuring that the occurrence of faults is not lost.

[0054] S204, if the fault type identifier has an unreported flag, the historical fault data corresponding to the unreported flag is confirmed as unreported fault data;

[0055] In one embodiment, if a fault type identifier has a non-reported flag, it indicates that in the fault diagnosis prior to the currently acquired fault diagnosis data, the fault type identifier was diagnosed as having a fault, but it was not reported via network management messages. Therefore, the historical fault data corresponding to the non-reported flag is obtained as non-reported fault data. When the current fault diagnosis data indicates that the fault type identifier is in a non-fault state, if the fault type identifier has a non-reported flag, meaning it disappeared after a fault occurred, it can be confirmed as non-reported data to report the fault situation at least once.

[0056] S205, if the fault type identifier does not have an unreported flag, then confirm that the group number corresponding to the fault diagnosis data is the minimum value in the group number value range;

[0057] In one embodiment, if the fault diagnosis data indicates that the fault type identifier is in a non-fault state and the fault type identifier does not have an unreported flag, then all fault detection types are considered fault-free. A network management message for a fault-free state can be generated. Specifically, the group number corresponding to the fault diagnosis data is determined to be the minimum value within the group number range, for example, it can be 0.

[0058] S206, write the minimum value into the group number storage location in the network management message, determine the values ​​of all fault status storage locations in the network management message as the second preset value, and report the network management message;

[0059] In one embodiment, the minimum value is written into the group number storage location in the network management message, and then the values ​​of all fault status storage locations in the network management message are determined as the second preset value to obtain the network management message and report it. The second preset value is used to indicate that all fault type identifiers are in a non-fault state. For example, the second preset value can be 0.

[0060] S207, Based on the fault type identifier of the unreported fault data and the total number of fault status storage locations in the network management message, confirm the group number of the unreported fault data and its fault status storage location in the network management message;

[0061] In one embodiment, when confirming the group number and fault status storage location, it can be calculated based on the fault type identifier of the unreported fault data and the total number of fault status storage locations in the network management messages. Specifically, the value of the fault type identifier can be divided by the total number of fault status storage locations, and the group number and fault status storage location corresponding to the fault type identifier can be confirmed based on the division result, thereby improving the convenience of confirming the fault status storage location.

[0062] For example, taking the 168th fault (fault type identifier is 168) as an example, the corresponding group number is (167+1)÷11=15 remainder 3, where the group number is 15. Each group has 11 fault status storage locations. Since the fault status storage locations are counted starting from 0, the third bit is the second bit 2.

[0063] S208, Based on the group number, confirm the reporting order of the unreported fault data;

[0064] In one embodiment, after identifying the group number and fault status storage location of each unreported obstacle data, the reporting order of each unreported fault data needs to be determined based on the group number. Specifically, the reporting order of the unreported fault data can be determined in ascending order of group number, that is, the smaller the group number, the higher the reporting priority. It can be understood that in the fault type identifier, the smaller the identifier value, the higher the severity of the fault. Therefore, prioritizing the reporting of faults with smaller group numbers means prioritizing the reporting of more serious faults, so that the server can promptly receive more serious faults existing in the vehicle.

[0065] Taking group numbers starting from 0 as an example, if group 0 has a fault, then group 0 data is reported; if group 0 has no fault, then group 1 data is queried, and so on. If multiple groups of data have faults in the current upload cycle, then in this cycle, the group with the smaller group number is reported first, and the next faulty group data is uploaded in the next upload cycle. If all groups have no faults, then group 0 data is uploaded.

[0066] S209, according to the reporting order, confirm the reporting group number of the current reporting period in the group number, and write the reporting group number into the group number storage location in the network management message;

[0067] In one embodiment, the group number with the shortest current reporting cycle is determined according to the reporting order and used as the reporting group number. This reporting group number is then written into the group number storage location in the network management message. The current reporting cycle refers to the reporting round of the network management message at the current time, and network management messages can be reported according to the reporting cycle pattern.

[0068] For example, if the fault type identifiers for unreported fault data are 1 and 12, and there are 11 fault status storage locations in one group, then fault type identifier 1 is the first position in group 0, and fault type identifier 12 is the first position in group 1. At this time, the group number with the smallest current reporting cycle is 0, so 0 is used as the reporting group number and written into the group number storage location of the network management message.

[0069] S210, confirm the reporting fault type identifier corresponding to the reporting group number, confirm the fault status storage location corresponding to the reporting fault type identifier as the fault status storage location, determine the value of the fault status storage location as a first preset value, and report the network management message.

[0070] In one embodiment, the reporting fault type identifier corresponding to the reporting group number is confirmed, the fault status storage location corresponding to the reporting fault type identifier is confirmed as the fault status storage location, and the value of the fault status storage location is determined as a first preset value before the network management message is reported. It can be understood that after confirming the reporting fault type identifier, the corresponding fault status storage location is the location that needs to be set in the network management message being reported.

[0071] The reported fault type identifier can be one or more. If, based on the fault type identifiers of the unreported fault data, it is determined that there are multiple fault type identifiers for the reporting group number, then multiple fault type identifiers will be reported.

[0072] Optionally, in one embodiment, the method of this specification embodiment may include the following steps S2101-S2102.

[0073] S2101, confirm the unreported group number in the group number, the unreported group number is the group number other than the reported group number in the group number;

[0074] Specifically, among the group numbers corresponding to the unreported fault data, there are also unreported group numbers corresponding to the reported group numbers. Since the unreported fault data indicates the fault type identifiers that exist, these fault type identifiers corresponding to the unreported group numbers need to be marked for subsequent reporting rounds to ensure that the unreported fault data is not lost.

[0075] S2102, Add an unreported flag to the fault type identifier corresponding to the unreported group number.

[0076] Specifically, an unreported flag is added to the fault type identifier corresponding to the unreported group number. It is understood that the fault type identifier corresponding to the unreported group number is a fault type identifier indicating that a fault exists. For example, the fault type identifier and its unreported flag can be stored in memory.

[0077] Optionally, in one embodiment, the method of this specification embodiment may further include the following steps S2053-S2055.

[0078] S2053, Confirm the number of reported fault type identifiers;

[0079] In one embodiment, when generating network management messages, in addition to adding group numbers and fault status, the number of faults can also be added. Specifically, the number of reported fault type identifiers in the current reporting period can be confirmed first. The number of reported fault type identifiers is also the number of faults currently reported.

[0080] S2054, If the number is less than or equal to the reporting threshold, then the number is written into the fault count storage location in the network management message;

[0081] S2055, if the number is greater than the reporting threshold, then the reporting threshold is written into the fault count storage location in the network management message.

[0082] In one embodiment, since the number of free bytes in a network management message is limited, and its records are binary numbers, the decimal numbers it can represent are also limited. Therefore, the reporting threshold can be determined based on the free bytes in the network management message. For example, if there are three free bytes, it can only represent 0-7, meaning the reporting threshold is 7. If the number exceeds the reporting threshold, the reporting threshold is written to the fault count storage location; if the number does not exceed the reporting threshold, the number is written to the fault count storage location. For example, if the number of reported fault type identifiers is 2, then 010 is written to the fault count storage location. By writing the fault count into the network management message, the efficiency of engineers in troubleshooting can be further improved.

[0083] Please see Figure 4 This is a schematic diagram illustrating an example of a fault recording method provided in this specification. Taking the reported fault type identifiers as 13 and 20 as examples, bits 0-7 of byte 6 and bits 0-2 of byte 4 are the fault status storage locations, where a value of 1 indicates a fault status. Bits 3-7 of byte 4 are the group number storage locations (00001 represents group number 1), and bits 8-10 of byte 4 are the fault count storage locations (010 represents fault count 2). This illustrates the content of the network management message.

[0084] In the embodiments of this specification, fault diagnosis data corresponding to the fault type identifier in the vehicle is obtained. If the fault diagnosis data indicates that the fault type identifier is in a fault state, the fault diagnosis data is confirmed as unreported fault data. If the fault diagnosis data indicates that the fault type identifier is in a non-fault state, it is confirmed whether the fault type identifier has an unreported mark. If the fault type identifier has an unreported mark, the historical fault data corresponding to the unreported mark is confirmed as unreported fault data. This ensures that faults that have occurred but disappeared can be reported at least once, achieving a more complete record and report of faults. Furthermore, based on the fault type identifier of the unreported fault data and the total number of fault status storage locations in the network management message, the group number of the unreported fault data and its fault status storage location in the network management message are confirmed. Based on the group number, the reporting order of the unreported fault data is confirmed. Following this reporting order, the reporting group number for the current reporting period is confirmed within the group number, and this reporting group number is written into the group number storage location in the network management message. The reporting fault type identifier corresponding to the reporting group number is confirmed, and the fault status storage location corresponding to the reporting fault type identifier is confirmed as the fault status storage location. The value of this fault status storage location is determined as a first preset value, and the network management message is reported. When the number of unreported faults is large, more serious faults can be reported in a limited way, allowing the server to promptly receive information about more serious faults in vehicles. In addition, writing the fault count into the network management message can further improve the efficiency of engineers in troubleshooting.

[0085] The following will be combined with the appendix Figure 5 This specification provides a detailed description of the fault recording device provided in the embodiments. It should be noted that the appendix... Figure 5 The fault recording device in this manual is used to perform the functions described herein. Figures 2-4 The methods shown in the embodiments are illustrated for ease of explanation, showing only the parts related to the embodiments of this specification. For specific technical details not disclosed, please refer to this specification. Figures 2-4 The example shown.

[0086] Please see Figure 5 This diagram illustrates the structure of a fault recording device provided in an exemplary embodiment of this specification. The fault recording device can be implemented as all or part of a device through software, hardware, or a combination of both. The device 1 includes an acquisition module 11, a confirmation module 12, a location confirmation module 13, and a message generation module 14.

[0087] The acquisition module 11 is used to acquire fault diagnosis data in the vehicle corresponding to the fault type identifier; the fault type identifier is used to indicate the fault detection type.

[0088] Confirmation module 12 is used to confirm, based on the fault diagnosis data, that no fault data has been reported.

[0089] Location confirmation module 13 is used to confirm the group number of the unreported fault data and the fault status storage location in the network management message based on the fault type identifier of the unreported fault data;

[0090] The message generation module 14 is used to write the group number into the group number storage location in the network management message, determine the value of the fault status storage location as a first preset value, and report the network management message; the first preset value is used to indicate that the fault type identifier corresponding to the fault status storage location is a fault status.

[0091] Optionally, the confirmation module 12 is specifically used to confirm that the fault diagnosis data is unreported fault data if the fault diagnosis data indicates that the fault type is identified as a fault state.

[0092] If the fault diagnosis data indicates that the fault type identifier is in a non-fault state, then confirm whether the fault type identifier has an unreported flag;

[0093] If the fault type identifier has an unreported flag, the historical fault data corresponding to the unreported flag will be confirmed as unreported fault data.

[0094] Optionally, the confirmation module 12 is specifically used to confirm that the group number corresponding to the fault diagnosis data is the minimum value in the range of group number values ​​if the fault type identifier does not have an unreported mark.

[0095] Write the minimum value into the group number storage location in the network management message, determine the values ​​of all fault status storage locations in the network management message as the second preset value, and report the network management message. The second preset value is used to indicate that all fault type identifiers are in a non-fault state.

[0096] Optionally, the location confirmation module 13 is specifically used to confirm the group number of the unreported fault data and the fault status storage location in the network management message based on the fault type identifier of the unreported fault data and the total number of fault status storage locations in the network management message.

[0097] Optionally, there are at least two group numbers, and the message generation module 14 is specifically used to determine the reporting order of the unreported fault data based on the group number;

[0098] Confirm the reporting group number for the current reporting period in the group number according to the reporting order, and write the reporting group number into the group number storage location in the network management message;

[0099] Confirm the reporting fault type identifier corresponding to the reporting group number, confirm the fault status storage location corresponding to the reporting fault type identifier as the fault status storage location, determine the value of the fault status storage location as a first preset value, and report the network management message.

[0100] Optionally, the message generation module 14 is further configured to identify unreported group numbers among the group numbers, wherein the unreported group numbers are group numbers other than the reported group numbers.

[0101] Add an unreported flag to the fault type identifier corresponding to the unreported group number.

[0102] Optionally, the message generation module 14 is also used to confirm the number of reported fault type identifiers;

[0103] If the number is less than or equal to the reporting threshold, then the number is written to the fault count storage location in the network management message;

[0104] If the number is greater than the reporting threshold, then the reporting threshold is written into the fault count storage location in the network management message.

[0105] It should be noted that the fault recording device provided in the above embodiments is only illustrated by the division of the above functional modules when executing the fault recording method. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the fault recording device and the fault recording method embodiments provided in the above embodiments belong to the same concept, and the implementation process is detailed in the method embodiments, which will not be repeated here.

[0106] The embodiment numbers in this specification are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0107] This specification also provides a computer storage medium storing a computer program, which, when executed by a processor, implements the above-described functionality. Figures 2-4 The fault recording method of the illustrated embodiment can be found in the following document for detailed execution process. Figures 2-4 The specific details of the illustrated embodiments will not be elaborated here.

[0108] Please refer to Figure 6 This diagram illustrates the structure of a vehicle provided in an exemplary embodiment of this specification. The vehicle in this specification may include one or more components such as a processor 110, a memory 120, an input device 130, an output device 140, and a bus 150. The processor 110, memory 120, input device 130, and output device 140 may be connected via the bus 150.

[0109] Processor 110 may include one or more processing cores. Processor 110 connects to various parts of the vehicle via various interfaces and lines, and executes various functions of terminal 100 and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 120, and by calling data stored in memory 120. Optionally, processor 110 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). Processor 110 may integrate one or more of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user page, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem may also not be integrated into processor 110 and may be implemented separately using a communication chip.

[0110] The memory 120 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 120 may include non-transitory computer-readable storage medium. The memory 120 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 120 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the various method embodiments described above, etc. The operating system may be the Android system, including systems deeply developed based on the Android system, the iOS system developed by Apple Inc., including systems deeply developed based on the iOS system, or other systems.

[0111] The memory 120 can be divided into operating system space and user space. The operating system runs in the operating system space, while native and third-party applications run in user space. To ensure that different third-party applications can achieve good running performance, the operating system allocates corresponding system resources for each application. However, different application scenarios within the same third-party application have different requirements for system resources. For example, in local resource loading scenarios, third-party applications have high requirements for disk read speed; in animation rendering scenarios, third-party applications have high requirements for GPU performance. Since the operating system and third-party applications are independent of each other, the operating system often cannot promptly perceive the current application scenario of a third-party application, resulting in the operating system's inability to adapt system resources accordingly.

[0112] In order for the operating system to distinguish the specific application scenarios of third-party applications, it is necessary to establish data communication between the third-party applications and the operating system. This would allow the operating system to obtain the current scenario information of the third-party applications at any time, and then perform targeted system resource adaptation based on the current scenario.

[0113] The input device 130 is used to receive input instructions or data, and includes, but is not limited to, a keyboard, mouse, camera, microphone, or touch device. The output device 140 is used to output instructions or data, and includes, but is not limited to, a display device and a speaker. In one example, the input device 130 and the output device 140 can be combined, and the input device 130 and the output device 140 can be a touch display screen.

[0114] The touch display screen can be designed as a full-screen, curved screen, or irregularly shaped screen. It can also be designed as a combination of a full-screen and a curved screen, or a combination of an irregularly shaped screen and a curved screen; however, this specification does not limit the specific design of the embodiments described herein.

[0115] In addition, those skilled in the art will understand that the vehicle structure shown in the above figures does not constitute a limitation on the vehicle. A vehicle may include more or fewer components than shown, or combine certain components, or have different component arrangements. For example, a vehicle may also include radio frequency circuits, input units, sensors, audio circuits, WiFi modules, power supplies, Bluetooth modules, etc., which will not be described in detail here.

[0116] exist Figure 6 In the vehicle shown, the processor 110 can be used to call computer applications stored in the memory 120 and specifically perform the following operations:

[0117] Acquire fault diagnosis data from the vehicle corresponding to the fault type identifier; the fault type identifier is used to indicate the fault detection type.

[0118] Based on the fault diagnosis data, it was confirmed that no fault data was reported;

[0119] Based on the fault type identifier of the unreported fault data, the group number of the unreported fault data and the fault status storage location in the network management message are confirmed.

[0120] Write the group number into the group number storage location in the network management message, determine the value of the fault status storage location as a first preset value, and report the network management message; the first preset value is used to indicate that the fault type identifier corresponding to the fault status storage location is a fault status.

[0121] In one embodiment, when the processor 110 performs the operation of confirming that no fault data has been reported based on the fault diagnosis data, it specifically performs the following operations:

[0122] If the fault diagnosis data indicates that the fault type is identified as a fault state, then the fault diagnosis data is confirmed to be unreported fault data.

[0123] If the fault diagnosis data indicates that the fault type identifier is in a non-fault state, then confirm whether the fault type identifier has an unreported flag;

[0124] If the fault type identifier has an unreported flag, the historical fault data corresponding to the unreported flag will be confirmed as unreported fault data.

[0125] In one embodiment, the processor 110 may also perform the following operations:

[0126] If the fault type identifier does not have an unreported flag, then the group number corresponding to the fault diagnosis data is confirmed to be the minimum value in the group number value range;

[0127] Write the minimum value into the group number storage location in the network management message, determine the values ​​of all fault status storage locations in the network management message as the second preset value, and report the network management message. The second preset value is used to indicate that all fault type identifiers are in a non-fault state.

[0128] In one embodiment, when the processor 110 executes the fault type identifier based on the unreported fault data to confirm the group number of the unreported fault data and the fault status storage location in the network management message, it specifically performs the following operations:

[0129] Based on the fault type identifier of the unreported fault data and the total number of fault status storage locations in the network management message, the group number of the unreported fault data and its fault status storage location in the network management message are confirmed.

[0130] In one embodiment, there are at least two group numbers. The processor 110 writes the group number to the group number storage location in the network management message, determines the value of the fault status storage location as a first preset value, and reports the network management message. Specifically, it performs the following operations:

[0131] The reporting order of the unreported fault data is confirmed based on the group number;

[0132] Confirm the reporting group number for the current reporting period in the group number according to the reporting order, and write the reporting group number into the group number storage location in the network management message;

[0133] Confirm the reporting fault type identifier corresponding to the reporting group number, confirm the fault status storage location corresponding to the reporting fault type identifier as the fault status storage location, determine the value of the fault status storage location as a first preset value, and report the network management message.

[0134] In one embodiment, after the processor 110 executes the process of confirming the reporting group number of the current reporting period in the group number according to the reporting order and writing the reporting group number into the group number storage location in the network management message, it may also perform the following operations:

[0135] Confirm the unreported group numbers in the group numbers, where the unreported group numbers are group numbers other than the reported group numbers.

[0136] Add an unreported flag to the fault type identifier corresponding to the unreported group number.

[0137] In one embodiment, after determining the value of the fault state storage location as a first preset value, the processor 110 may also perform the following operations:

[0138] Confirm the number of reported fault type identifiers;

[0139] If the number is less than or equal to the reporting threshold, then the number is written to the fault count storage location in the network management message;

[0140] If the number is greater than the reporting threshold, then the reporting threshold is written into the fault count storage location in the network management message.

[0141] In the embodiments of this specification, fault diagnosis data corresponding to the fault type identifier in the vehicle is obtained. Based on the fault diagnosis data, unreported fault data is identified. According to the fault type identifier of the unreported fault data, the group number of the unreported fault data and its fault status storage location in the network management message are determined. The group number is written to the group number storage location in the network management message, and the value of the fault status storage location is set as a first preset value. The network management message is then reported. This method can identify unreported fault data with reporting requirements from the diagnostic fault data and report the unreported fault data using network management messages, improving the convenience of reporting and enabling timely recording of vehicle faults.

[0142] Furthermore, fault diagnosis data corresponding to the fault type identifier in the vehicle is obtained. If the fault diagnosis data indicates that the fault type identifier is in a fault state, the fault diagnosis data is confirmed as unreported fault data. If the fault diagnosis data indicates that the fault type identifier is in a non-fault state, it is confirmed whether the fault type identifier has an unreported mark. If the fault type identifier has an unreported mark, the historical fault data corresponding to the unreported mark is confirmed as unreported fault data. This ensures that faults that have occurred but disappeared can be reported at least once, achieving a more complete record and report of faults. Furthermore, based on the fault type identifier of the unreported fault data and the total number of fault status storage locations in the network management message, the group number of the unreported fault data and its fault status storage location in the network management message are confirmed. Based on the group number, the reporting order of the unreported fault data is confirmed. Following this reporting order, the reporting group number for the current reporting period is confirmed within the group number, and this reporting group number is written into the group number storage location in the network management message. The reporting fault type identifier corresponding to the reporting group number is confirmed, and the fault status storage location corresponding to the reporting fault type identifier is confirmed as the fault status storage location. The value of this fault status storage location is determined as a first preset value, and the network management message is reported. When the number of unreported faults is large, more serious faults can be reported in a limited way, allowing the server to promptly receive information about more serious faults in vehicles. In addition, writing the fault count into the network management message can further improve the efficiency of engineers in troubleshooting.

[0143] Additionally, embodiments of this specification provide a computer program product, which includes a computer program that, when executed by a vehicle's processor, enables the processor to at least perform the functions described above. Figures 2 to 4 The fault recording method provided in the illustrated embodiment.

[0144] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The aforementioned program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0145] The above-disclosed embodiments are merely preferred embodiments of this specification and should not be construed as limiting the scope of this specification. Therefore, any equivalent variations made in accordance with the claims of this specification shall still fall within the scope of this specification.

Claims

1. A fault recording method, characterized in that, The method includes: Acquire fault diagnosis data from the vehicle corresponding to the fault type identifier; the fault type identifier is used to indicate the fault detection type. Based on the fault diagnosis data, it was confirmed that no fault data was reported; Based on the fault type identifier of the unreported fault data, the group number of the unreported fault data and the fault status storage location in the network management message are confirmed, and the group number is at least two; The reporting order of the unreported fault data is confirmed based on the group number; Confirm the reporting group number for the current reporting period in the group number according to the reporting order, and write the reporting group number into the group number storage location in the network management message; Confirm the reporting fault type identifier corresponding to the reporting group number, confirm the fault status storage location corresponding to the reporting fault type identifier as the fault status storage location, determine the value of the fault status storage location as a first preset value, and report the network management message; the first preset value is used to indicate that the fault type identifier corresponding to the fault status storage location is a fault status.

2. The method according to claim 1, characterized in that, The confirmation that no fault data was reported based on the fault diagnosis data includes: If the fault diagnosis data indicates that the fault type is identified as a fault state, then the fault diagnosis data is confirmed to be unreported fault data. If the fault diagnosis data indicates that the fault type identifier is in a non-fault state, then confirm whether the fault type identifier has an unreported flag; If the fault type identifier has an unreported flag, the historical fault data corresponding to the unreported flag will be confirmed as unreported fault data.

3. The method according to claim 2, characterized in that, The method further includes: If the fault type identifier does not have an unreported flag, then the group number corresponding to the fault diagnosis data is confirmed to be the minimum value in the group number value range; Write the minimum value into the group number storage location in the network management message, determine the values ​​of all fault status storage locations in the network management message as the second preset value, and report the network management message. The second preset value is used to indicate that all fault type identifiers are in a non-fault state.

4. The method according to claim 1, characterized in that, The step of determining the group number of the unreported fault data and its storage location in the network management message based on the fault type identifier of the unreported fault data includes: Based on the fault type identifier of the unreported fault data and the total number of fault status storage locations in the network management message, the group number of the unreported fault data and its fault status storage location in the network management message are confirmed.

5. The method according to claim 1, characterized in that, After confirming the reporting group number of the current reporting period in the group number according to the reporting order, and writing the reporting group number into the group number storage location in the network management message, the method further includes: Confirm the unreported group numbers in the group numbers, where the unreported group numbers are group numbers other than the reported group numbers. Add an unreported flag to the fault type identifier corresponding to the unreported group number.

6. The method according to claim 1, characterized in that, After determining the value of the fault state storage location as the first preset value, the method further includes: Confirm the number of reported fault type identifiers; If the number is less than or equal to the reporting threshold, then the number is written to the fault count storage location in the network management message; If the number is greater than the reporting threshold, then the reporting threshold is written into the fault count storage location in the network management message.

7. A fault recording device, characterized in that, The device includes: The acquisition module is used to acquire fault diagnosis data in the vehicle corresponding to the fault type identifier; the fault type identifier is used to indicate the fault detection type. The confirmation module is used to confirm, based on the fault diagnosis data, that no fault data has been reported. The location confirmation module is used to confirm the group number of the unreported fault data and the fault status storage location in the network management message based on the fault type identifier of the unreported fault data, wherein the group number is at least two; The message generation module is used to confirm the reporting order of the unreported fault data based on the group number; confirm the reporting group number of the current reporting period in the group number according to the reporting order, and write the reporting group number into the group number storage location in the network management message; confirm the reporting fault type identifier corresponding to the reporting group number, confirm the fault status storage location corresponding to the reporting fault type identifier as the fault status storage location, determine the value of the fault status storage location as a first preset value, and report the network management message; the first preset value is used to indicate that the fault type identifier corresponding to the fault status storage location is a fault status.

8. A vehicle, characterized in that, The vehicle includes a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the steps of the method as claimed in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the method as described in any one of claims 1 to 6.

Images