Vehicle fault duration confirmation method, device, equipment and storage medium

Abstract

The application discloses a vehicle fault duration confirmation method and device, equipment and storage medium, relates to the vehicle state analysis technical field, and the method comprises the following steps: defining the fault of each module of the vehicle based on a preset identifier, and obtaining fault information according to the preset identifier corresponding to the current module when the module is faulty; periodically collecting the whole vehicle data and all fault information of the vehicle and uploading to the background server, and the background server carries out the whole vehicle data and fault information buffering; based on the comparison between the current uploaded all fault information and the fault information buffered in the background server, and the uploading time of the whole vehicle data, the start and end time of the fault is determined. The application can confirm the continuous duration of the fault reported by the automobile, analyze the fault occurrence time, frequency and continuous duration, and facilitate the orderly management of the fault.

Description

Technical Field

[0001] This application relates to the field of vehicle condition analysis technology, specifically to a method, apparatus, device, and storage medium for confirming vehicle fault duration. Background Technology

[0002] With the development of automotive electronics, intelligence, and information technology, the number of vehicle controllers is constantly increasing, the functional logic is becoming more complex, and the amount of interactive information between systems is also gradually increasing, making the timing and operating conditions of occasional vehicle faults more complex. Currently, fault diagnosis mainly relies on obtaining the corresponding diagnostic codes to analyze the fault; therefore, the collection of vehicle fault information is crucial. However, current methods for collecting vehicle fault information generally only involve storing the collected fault information in a database, performing only the most basic recording operations.

[0003] Therefore, the current method of collecting and processing vehicle fault information has the following problems: it only records information and does not support engineers to quickly analyze and locate faults; all faults are sorted by time, resulting in chaos and disorder when multiple vehicles have multiple faults at the same time; and it is impossible to quickly locate the start time and duration of the fault. Summary of the Invention

[0004] This application provides a method, apparatus, device, and storage medium for confirming the duration of vehicle faults, which can confirm the duration of faults reported by vehicles, analyze the time of occurrence, frequency, and duration of faults, and facilitate the orderly management of faults.

[0005] In a first aspect, embodiments of this application provide a method for confirming the duration of a vehicle malfunction, the method comprising:

[0006] The faults of each module of the vehicle are defined based on preset identifiers, and when a module fails, the fault information is obtained according to the preset identifier corresponding to the current module.

[0007] The system periodically collects vehicle data and all fault information and uploads it to the backend server, which then caches the vehicle data and fault information.

[0008] Based on a comparison between all currently uploaded fault information and the fault information cached on the backend server, as well as the upload time of the vehicle data, the start and end times of the fault are determined.

[0009] In conjunction with the first aspect, in one implementation, the start and end times of the fault are determined based on a comparison between all currently uploaded fault information and the fault information cached by the backend server, as well as the upload time of the whole vehicle data. The comparison between the currently uploaded fault information and the fault information cached by the backend server includes a comparison between a single fault information in the currently uploaded fault information and the fault information cached by the backend server, as well as a comparison between all currently uploaded fault information as a whole and the fault information cached by the backend server.

[0010] In conjunction with the first aspect, in one implementation method, the comparison between a single fault information in the currently uploaded fault information and the fault information cached by the backend server specifically includes:

[0011] Each individual fault message from all currently uploaded fault messages is compared with all fault messages cached on the backend server in turn:

[0012] If the current fault information already exists on the backend server, then discard the current fault information;

[0013] If the current fault information does not exist on the backend server, then the current fault information will be cached on the backend server, and the current time information will be appended to the current fault information.

[0014] In conjunction with the first aspect, in one implementation method, the comparison between all currently uploaded fault information and the fault information cached by the backend server specifically includes:

[0015] The entire cached fault information on the backend server is compared with the entire currently uploaded fault information to determine if any fault information not currently uploaded exists on the backend server.

[0016] If not, no action will be taken;

[0017] If so, retrieve the fault information from the backend server that is not currently uploaded, and compare the time information attached to that fault information with the current time:

[0018] - When the time difference is greater than the set time, determine whether there is vehicle data uploaded within the preset time before the current time. If it exists, it means that the fault corresponding to the fault information has ended. The time information attached to the fault information is taken as the occurrence time of the fault corresponding to the fault information, and the current time is taken as the end time of the fault corresponding to the fault information. If it does not exist, the fault information is discarded.

[0019] - No action will be taken if the time difference is not greater than the set time.

[0020] In conjunction with the first aspect, in one implementation, the step of defining faults for each module of the vehicle based on preset identifiers, and obtaining fault information according to the preset identifier corresponding to the current module when a module fails, specifically includes:

[0021] The faults of each module of the vehicle are defined based on preset identifiers, which include assembly name, system source address, suspicious parameter code, failure mode identifier and fault name;

[0022] The system monitors the fault information of each module in real time using sensors. When a module is faulty, the sensors on the current module report the preset identifier corresponding to the current module, thus generating fault information.

[0023] In conjunction with the first aspect, in one implementation method,

[0024] All vehicle fault information is periodically collected via Tbox and uploaded to the backend server;

[0025] The Tbox communicates with the backend server via TCP, and a response mechanism and a retransmission mechanism are established between the Tbox and the backend server.

[0026] The response mechanism requires the backend server to return a status value for any data sent by Tbox.

[0027] The retransmission mechanism is that when data transmission between Tbox and the backend server fails, Tbox will continue to transmit data at a fixed period.

[0028] In conjunction with the first aspect, in one implementation, the backend server receives and caches the uploaded fault information. For each cached fault information, the fault information is identified by the SIM card number, system source address, suspicious parameter code, and failure mode identifier, and recorded as a key.

[0029] Secondly, embodiments of this application also provide a vehicle fault duration confirmation device, the vehicle fault duration confirmation device comprising:

[0030] The definition unit is used to define the faults of each module of the vehicle based on preset identifiers, and to obtain fault information according to the preset identifiers corresponding to the current module when a module fails.

[0031] The data acquisition unit is used to periodically collect vehicle data and all fault information and upload them to the backend server, which in turn drives the backend server to cache the vehicle data and fault information.

[0032] The execution unit is used to determine the start and end times of a fault based on a comparison between all currently uploaded fault information and the fault information cached by the backend server, as well as the upload time of the vehicle data.

[0033] Thirdly, this application also provides a vehicle fault duration confirmation device, which includes a processor, a memory, and a vehicle fault duration confirmation program stored in the memory and executable by the processor. When the vehicle fault duration confirmation program is executed by the processor, it implements the steps of the vehicle fault duration confirmation method described above.

[0034] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a vehicle fault duration confirmation program, wherein when the vehicle fault duration confirmation program is executed by a processor, it implements the steps of the vehicle fault duration confirmation method described above.

[0035] The beneficial effects of the technical solutions provided in this application include:

[0036] By defining faults for each module of the vehicle based on preset identifiers, and obtaining fault information according to the preset identifier corresponding to the current module when a module fails, the system periodically collects vehicle data and all fault information and uploads it to the backend server. The backend server caches the vehicle data and fault information. Then, by comparing all currently uploaded fault information with the fault information cached on the backend server, and considering the upload time of the vehicle data, the start and end times of the fault are determined. This is used to confirm the duration of the faults reported by the vehicle, analyze the time of occurrence, frequency, and duration of the fault, facilitate orderly fault management, and prepare in advance for subsequent fault cause localization and impact assessment. Attached Figure Description

[0037] Figure 1 This is a flowchart illustrating the method for confirming vehicle malfunction duration in this application;

[0038] Figure 2 This is a schematic diagram of the functional modules of the vehicle fault duration confirmation device of this application.

[0039] Figure 3 This is a schematic diagram of the hardware structure of the vehicle malfunction duration confirmation device for this application. Detailed Implementation

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

[0041] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0042] In the first aspect, embodiments of this application provide a method for confirming the duration of vehicle faults, used to confirm the duration of faults reported by vehicles, in order to analyze the time, frequency and duration of fault occurrence, and to prepare in advance for subsequent fault cause location and impact assessment.

[0043] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating the method for confirming vehicle malfunction duration in this application. Figure 1 As shown, the methods for confirming vehicle fault duration include:

[0044] S1: Define the faults of each module of the vehicle based on the preset identifier, and obtain the fault information according to the preset identifier corresponding to the current module when the module fails;

[0045] Furthermore, in one embodiment, faults of each module of the vehicle are defined based on preset identifiers, and when a module fails, fault information is obtained according to the preset identifier corresponding to the current module, specifically including:

[0046] S101: Define the faults of each module of the vehicle based on preset identifiers, wherein the preset identifiers include assembly name, system source address, suspicious parameter code, failure mode identifier and fault name;

[0047] S102: Based on the sensors on each module, the fault information of the module is monitored in real time. When a module has a fault, the sensor on the current module reports the preset identifier corresponding to the current module to form fault information.

[0048] Specifically, during vehicle power-on, when a module in the vehicle malfunctions, it reports the assembly name, system source address (faultAddr), suspicious parameter code (SPN), failure mode identifier (FAM), and fault name based on preset identifiers, forming fault information. While a module is faulty, the corresponding sensors will continue reporting fault information until the fault disappears.

[0049] The fault definitions for each module in this application are shown in Table 1 below.

[0050] Table 1 Examples of Fault Definitions

[0051] engine 0x00 171 9 Ambient air temperature - update speed anomaly gearbox 0x03 33 3 Clutch position sensor short-circuited to power supply PEPS 0x34 521316 7 The central control antenna is short-circuited to ground. Vehicle controller 0x31 168 18 Battery voltage signal below line

[0052] S2: The system periodically collects vehicle data and all fault information and uploads it to the backend server, which then caches the vehicle data and fault information. Specifically, the Tbox (Vehicle Information and Positioning Transmission System) periodically collects all vehicle fault information and uploads it to the backend server. The Tbox and the backend server communicate via TCP (Transmission Control Protocol), and an acknowledgment mechanism and a retransmission mechanism are established between them. The acknowledgment mechanism requires the backend server to return a status value for any data sent by the Tbox. The retransmission mechanism ensures that when data transmission between the Tbox and the backend server fails, the Tbox continues to send data at a fixed period.

[0053] In one possible implementation, the Tbox collects vehicle-wide data and fault information reported by all sensors at a fixed 1-minute interval and uploads it to the backend server. The Tbox uses TCP instead of UDP to improve transmission reliability. Furthermore, to prevent packet loss, a response mechanism is established between the Tbox and the backend server; the backend server must return a status value for any message sent by the Tbox, and will retransmit if the Tbox does not receive it. To prevent data transmission failure due to poor network conditions caused by the IoT SIM card, the Tbox has a retransmission mechanism; failed data transmissions will be continuously sent at fixed intervals.

[0054] The backend server receives and caches the uploaded fault information. For each cached fault information, the fault information is identified by the SIM card (user identification card) number, system source address, suspicious parameter code, and failure mode identifier, and recorded as a key.

[0055] S3: Based on the comparison between all currently uploaded fault information and the fault information cached by the backend server, as well as the upload time of the whole vehicle data, determine the start and end time of the fault.

[0056] In this application, the start and end times of the fault are determined based on the comparison between all currently uploaded fault information and the fault information cached by the backend server, as well as the upload time of the whole vehicle data. The comparison between the currently uploaded fault information and the fault information cached by the backend server includes the comparison between a single fault information in the currently uploaded fault information and the fault information cached by the backend server, as well as the comparison between all currently uploaded fault information as a whole and the fault information cached by the backend server.

[0057] This involves comparing a single fault information currently uploaded by the vehicle with the fault information of the same vehicle cached on the backend server, and comparing all the fault information currently uploaded by the vehicle as a whole with the fault information of the same vehicle cached on the backend server.

[0058] Furthermore, the comparison between individual fault information in the currently uploaded fault information and the fault information cached by the backend server specifically includes:

[0059] Each individual fault message from all currently uploaded fault messages is compared with all fault messages cached on the backend server in turn:

[0060] If the current fault information already exists on the backend server, then discard the current fault information;

[0061] If the current fault information does not exist on the backend server, then the current fault information will be cached on the backend server, and the current time information will be appended to the current fault information.

[0062] Furthermore, the comparison between all currently uploaded fault information and the fault information cached on the backend server specifically includes:

[0063] The entire cached fault information on the backend server is compared with the entire currently uploaded fault information to determine if any fault information not currently uploaded exists on the backend server.

[0064] If not, no action will be taken;

[0065] If so, retrieve the fault information from the backend server that is not currently uploaded, and compare the time information attached to that fault information with the current time:

[0066] - When the time difference is greater than the set time, determine whether there is vehicle data uploaded within the preset time before the current time. If it exists, it means that the fault corresponding to the fault information has ended. The time information attached to the fault information is taken as the occurrence time of the fault corresponding to the fault information, and the current time is taken as the end time of the fault corresponding to the fault information. If it does not exist, the fault information is discarded.

[0067] - No action will be taken if the time difference is not greater than the set time.

[0068] Specifically, if there is a fault information in the backend server that is not currently uploaded, it means that the fault information has not been reported. The time information attached to the fault information is compared with the current time. If the time difference between the two is greater than 5 minutes, it is determined whether there is vehicle data uploaded within 2 minutes before the current time. If so, it indicates that the fault has ended. The time information attached to the fault information is taken as the occurrence time of the fault corresponding to the fault information, and the current time is taken as the end time of the fault corresponding to the fault information.

[0069] Using the above method, the occurrence and end times of each fault for each vehicle are determined. The end time is defined as: the fault has not been reported for 5 minutes. The reason why the fault was not reported for 5 minutes may be that the vehicle lost power shortly after the fault was reported. It is necessary to wait for the vehicle to be powered back on and observe whether the fault is still reported immediately. If it is reported, then the fault is still ongoing.

[0070] It should be noted that after the vehicle is powered on, the tbox will collect and report information every 1 minute, regardless of whether there is a fault. The only difference is that when there is no fault, the reported information is limited to location and time.

[0071] The vehicle fault duration confirmation method of this application defines faults of each module of the vehicle based on preset identifiers. When a module fails, fault information is obtained according to the preset identifier corresponding to the current module. Then, the vehicle's whole data and all fault information are periodically collected and uploaded to the backend server. The backend server caches the whole data and fault information. Then, based on the comparison between all currently uploaded fault information and the fault information cached by the backend server, as well as the upload time of the whole data, the start and end time of the fault is determined. This is used to confirm the duration of the fault reported by the vehicle, so as to analyze the time of occurrence, frequency and duration of the fault, which facilitates the orderly management of the fault and prepares for subsequent fault cause location and impact assessment.

[0072] Secondly, embodiments of this application also provide a vehicle fault duration confirmation device.

[0073] In one embodiment, reference is made to Figure 2 , Figure 2 This is a schematic diagram of the functional modules of the vehicle fault duration confirmation device of this application. Figure 2 As shown, the vehicle fault duration confirmation device includes a definition unit, a data acquisition unit, and an execution unit.

[0074] The definition unit is used to define the faults of each module of the vehicle based on preset identifiers, and to obtain fault information according to the preset identifier corresponding to the current module when a module fails; the acquisition unit is used to periodically collect the vehicle's whole data and all fault information and upload them to the backend server, driving the backend server to cache the whole data and fault information; the execution unit is used to determine the start and end time of the fault based on the comparison between all currently uploaded fault information and the fault information cached by the backend server, as well as the upload time of the whole data.

[0075] In this application, the start and end times of the fault are determined based on the comparison between all currently uploaded fault information and the fault information cached by the backend server, as well as the upload time of the whole vehicle data. The comparison between the currently uploaded fault information and the fault information cached by the backend server includes the comparison between a single fault information in the currently uploaded fault information and the fault information cached by the backend server, as well as the comparison between all currently uploaded fault information as a whole and the fault information cached by the backend server.

[0076] In this application, the comparison between a single fault information in the currently uploaded fault information and the fault information cached by the backend server specifically includes:

[0077] Each individual fault message from all currently uploaded fault messages is compared with all fault messages cached on the backend server in turn:

[0078] If the current fault information already exists on the backend server, then discard the current fault information;

[0079] If the current fault information does not exist on the backend server, then the current fault information will be cached on the backend server, and the current time information will be appended to the current fault information.

[0080] In this application, the comparison between all currently uploaded fault information and the fault information cached on the backend server specifically includes:

[0081] The entire cached fault information on the backend server is compared with the entire currently uploaded fault information to determine if any fault information not currently uploaded exists on the backend server.

[0082] If not, no action will be taken;

[0083] If so, retrieve the fault information from the backend server that is not currently uploaded, and compare the time information attached to that fault information with the current time:

[0084] - When the time difference is greater than the set time, determine whether there is vehicle data uploaded within the preset time before the current time. If it exists, it means that the fault corresponding to the fault information has ended. The time information attached to the fault information is taken as the occurrence time of the fault corresponding to the fault information, and the current time is taken as the end time of the fault corresponding to the fault information. If it does not exist, the fault information is discarded.

[0085] - No action will be taken if the time difference is not greater than the set time.

[0086] In this application, faults of each module of the vehicle are defined based on preset identifiers, and when a module fails, fault information is obtained according to the preset identifier corresponding to the current module, specifically including:

[0087] The faults of each module of the vehicle are defined based on preset identifiers, which include assembly name, system source address, suspicious parameter code, failure mode identifier and fault name;

[0088] The system monitors the fault information of each module in real time using sensors. When a module is faulty, the sensors on the current module report the preset identifier corresponding to the current module, thus generating fault information.

[0089] In this application, all vehicle fault information is periodically collected via Tbox and uploaded to the backend server;

[0090] The Tbox communicates with the backend server via TCP, and a response mechanism and a retransmission mechanism are established between the Tbox and the backend server.

[0091] The response mechanism requires the backend server to return a status value for any data sent by Tbox.

[0092] The retransmission mechanism is that when data transmission between Tbox and the backend server fails, Tbox will continue to transmit data at a fixed period.

[0093] In this application, the backend server receives and caches the uploaded fault information. For each cached fault information, the fault information is identified by the SIM card number, system source address, suspicious parameter code, and failure mode identifier, and recorded as a key.

[0094] Thirdly, embodiments of this application provide a vehicle fault duration confirmation device, which can be a personal computer (PC), laptop computer, server, or other device with data processing capabilities.

[0095] Reference Figure 3 , Figure 3This is a schematic diagram of the hardware structure of the vehicle fault duration confirmation device involved in the embodiments of this application. In this embodiment, the vehicle fault duration confirmation device may include a processor, a memory, a communication interface, and a communication bus.

[0096] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0097] The communication interface includes input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting internal components of the vehicle fault duration verification device, as well as interfaces used for interconnecting the vehicle fault duration verification device with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0098] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0099] The processor can be a general-purpose processor, which can call the vehicle fault duration confirmation program stored in the memory and execute the vehicle fault duration confirmation method provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the vehicle fault duration confirmation program is called can be referred to in the various embodiments of the vehicle fault duration confirmation method of this application, and will not be repeated here.

[0100] Those skilled in the art will understand that Figure 3 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0101] Fourthly, embodiments of this application also provide a computer-readable storage medium.

[0102] The present application provides a vehicle fault duration confirmation program stored on a computer-readable storage medium, wherein when the vehicle fault duration confirmation program is executed by a processor, it implements the steps of the vehicle fault duration confirmation method described above.

[0103] The method implemented when the vehicle fault duration confirmation procedure is executed can be referred to in various embodiments of the vehicle fault duration confirmation method of this application, and will not be repeated here.

[0104] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0105] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0106] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0107] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0108] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0109] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0110] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for confirming the duration of a vehicle malfunction, characterized in that, The method for confirming the duration of vehicle malfunction includes: The faults of each module of the vehicle are defined based on preset identifiers, and when a module fails, the fault information is obtained according to the preset identifier corresponding to the current module. The system periodically collects vehicle data and all fault information and uploads it to the backend server, which then caches the vehicle data and fault information. Based on the comparison between all currently uploaded fault information and the fault information cached on the backend server, as well as the upload time of the whole vehicle data, the start and end times of the fault are determined. Specifically, the comparison between all currently uploaded fault information and the fault information cached on the backend server includes: The entire cached fault information on the backend server is compared with the entire currently uploaded fault information to determine if any fault information not currently uploaded exists on the backend server. If not, no action will be taken; If so, retrieve the fault information from the backend server that is not currently uploaded, and compare the time information attached to that fault information with the current time: - When the time difference is greater than the set time, determine whether there is vehicle data uploaded within the preset time before the current time. If it exists, it means that the fault corresponding to the fault information has ended. The time information attached to the fault information is taken as the occurrence time of the fault corresponding to the fault information, and the current time is taken as the end time of the fault corresponding to the fault information. If it does not exist, the fault information is discarded. - No action will be taken if the time difference is not greater than the set time.

2. The method for confirming vehicle fault duration as described in claim 1, characterized in that, The start and end times of the faults are determined by comparing all currently uploaded fault information with the fault information cached on the backend server, as well as the upload time of the whole vehicle data. The comparison between the currently uploaded fault information and the fault information cached on the backend server includes the comparison between a single fault information in the currently uploaded fault information and the fault information cached on the backend server, as well as the comparison between all currently uploaded fault information as a whole and the fault information cached on the backend server.

3. The method for confirming vehicle fault duration as described in claim 2, characterized in that, The comparison between a single fault message in the currently uploaded fault information and the fault information cached by the backend server specifically includes: Each individual fault message from all currently uploaded fault messages is compared with all fault messages cached on the backend server in turn: If the current fault information already exists on the backend server, then discard the current fault information; If the current fault information does not exist on the backend server, then the current fault information will be cached on the backend server, and the current time information will be appended to the current fault information.

4. The method for confirming vehicle fault duration as described in claim 1, characterized in that, The process involves defining faults for each vehicle module based on preset identifiers, and obtaining fault information based on the preset identifier corresponding to the current module when a module malfunctions. Specifically, this includes: The faults of each module of the vehicle are defined based on preset identifiers, which include assembly name, system source address, suspicious parameter code, failure mode identifier and fault name; The system monitors the fault information of each module in real time using sensors. When a module is faulty, the sensors on the current module report the preset identifier corresponding to the current module, thus generating fault information.

5. The method for confirming vehicle fault duration as described in claim 1, characterized in that: All vehicle fault information is periodically collected via Tbox and uploaded to the backend server; The Tbox communicates with the backend server via TCP, and a response mechanism and a retransmission mechanism are established between the Tbox and the backend server. The response mechanism requires the backend server to return a status value for any data sent by Tbox. The retransmission mechanism is that when data transmission between Tbox and the backend server fails, Tbox will continue to transmit data at a fixed period.

6. The method for confirming vehicle fault duration as described in claim 1, characterized in that: The backend server receives and caches the uploaded fault information. For each cached fault information, it identifies the fault information with the SIM card number, system source address, suspicious parameter code, and failure mode identifier, and records it as a key.

7. A vehicle fault duration confirmation device, characterized in that, The vehicle fault duration confirmation device includes: The definition unit is used to define the faults of each module of the vehicle based on preset identifiers, and to obtain fault information according to the preset identifiers corresponding to the current module when a module fails. The data acquisition unit is used to periodically collect vehicle data and all fault information and upload them to the backend server, which in turn drives the backend server to cache the vehicle data and fault information. The execution unit is used to determine the start and end times of the fault based on the comparison between all currently uploaded fault information and the fault information cached by the backend server, as well as the upload time of the whole vehicle data. Specifically, the comparison between all currently uploaded fault information and the fault information cached on the backend server includes: The entire cached fault information on the backend server is compared with the entire currently uploaded fault information to determine if any fault information not currently uploaded exists on the backend server. If not, no action will be taken; If so, retrieve the fault information from the backend server that is not currently uploaded, and compare the time information attached to that fault information with the current time: - When the time difference is greater than the set time, determine whether there is vehicle data uploaded within the preset time before the current time. If it exists, it means that the fault corresponding to the fault information has ended. The time information attached to the fault information is taken as the occurrence time of the fault corresponding to the fault information, and the current time is taken as the end time of the fault corresponding to the fault information. If it does not exist, the fault information is discarded. - No action will be taken if the time difference is not greater than the set time.

8. A vehicle fault duration confirmation device, characterized in that, The vehicle fault duration confirmation device includes a processor, a memory, and a vehicle fault duration confirmation program stored in the memory and executable by the processor, wherein when the vehicle fault duration confirmation program is executed by the processor, it implements the steps of the vehicle fault duration confirmation method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a vehicle fault duration confirmation program, wherein when the vehicle fault duration confirmation program is executed by a processor, it implements the steps of the vehicle fault duration confirmation method as described in any one of claims 1 to 6.

Images