Method, device, electronic device and readable storage medium for storing diagnostic events

Abstract

The present application provides a storage method, device, electronic device and readable storage medium for diagnostic events. The method includes: when the status of the diagnostic event reported by the received diagnostic application is a pre-fault state or a pre-normal state, the diagnostic event is de-jittered and then the diagnostic fault code is updated according to the status of the diagnostic event; after obtaining the updated diagnostic fault code, the storage condition of the memory is evaluated according to the updated diagnostic fault code; when the memory meets the storage requirements of the diagnostic event, the flag data of the diagnostic fault code corresponding to the event storage entry triggering mode corresponding to the diagnostic event is judged to be true according to the event storage entry triggering mode corresponding to the diagnostic event; if the flag data is true, the diagnostic fault code and its corresponding event-related information are stored in the memory using the event retention mode. The technical solution of the present application can improve the accuracy and efficiency of storing data in the process of vehicle fault diagnosis.

Description

Technical Field

[0001] The present application relates to the field of intelligent driving technology, and in particular to a method, device, electronic device and readable storage medium for storing diagnostic events. Background Art

[0002] With the continuous development of modern automobile technology, the application of on-board electronic control systems in vehicles is becoming more and more extensive. These systems include engine control units, transmission control units, brake control units, airbag control units, etc. These control units monitor various parts of the vehicle in real time through sensors and actuators, and control them according to preset algorithms.

[0003] Due to the complex structure of vehicles and the interconnectedness of various systems, it is difficult to avoid the occurrence of faults. In a large amount of fault data, there may be false alarms and erroneous processing of fault diagnosis events due to signal jitter. On the one hand, the continuous reporting of error events will cause the system to frequently process and respond, increasing the system burden and resource consumption. On the other hand, the inaccuracy of vehicle fault diagnosis will affect the fault location and repair progress of maintenance technicians. At the same time, for car owners, the maintenance cost increases and driving safety cannot be guaranteed.

[0004] How to avoid false fault alarms caused by signal jitter from being stored in fault data is a technical problem that needs to be solved urgently. Summary of the invention

[0005] In view of this, embodiments of the present application provide a method, device, electronic device and readable storage medium for storing diagnostic events to solve the technical problem of storing false alarm data during vehicle fault diagnosis.

[0006] According to a first aspect of an embodiment of the present application, a method for storing diagnostic events is provided, the method comprising: when a diagnostic event reported by a diagnostic application is received and the state is a pre-fault state or a pre-normal state, the diagnostic event is de-jittered and then the diagnostic fault code is updated according to the state of the diagnostic event, wherein the de-jittering process adopts a timer-based de-jittering method, and when the timer times out and the step counting condition is met, the count value of the fault de-jitter counter is increased by a pre-configured step value, and the step value is configured according to the type of the diagnostic event; after obtaining the updated diagnostic fault code, the storage condition of the memory is evaluated according to the updated diagnostic fault code; when the memory meets the storage requirements of the diagnostic event, judging whether the flag data of the diagnostic fault code corresponding to the event storage entry triggering method is true according to the event storage entry triggering method corresponding to the diagnostic event; if the flag data is true, the diagnostic fault code and its corresponding event-related information are stored in the memory using an event retention method.

[0007] According to a second aspect of an embodiment of the present application, a storage device for diagnostic events is provided, the device comprising: an update module for, when the state of a diagnostic event reported by a received diagnostic application is a pre-fault state or a pre-normal state, performing de-jitter processing on the diagnostic event and then updating a diagnostic fault code according to the state of the diagnostic event, wherein the de-jitter processing adopts a timer-based de-jitter method, and when the timer times out and meets the step counting condition, the count value of the fault de-jitter counter increases by a pre-configured step value, and the step value is configured according to the type of the diagnostic event; an evaluation module for, after obtaining the updated diagnostic fault code, evaluating the storage condition of the memory according to the updated diagnostic fault code; a judgment module for, when the memory meets the storage requirements of the diagnostic event, judging whether the flag data of the diagnostic fault code corresponding to the event storage entry triggering mode is true according to the event storage entry triggering mode corresponding to the diagnostic event; and a storage module for, when the flag data is true, storing the diagnostic fault code and its corresponding event-related information in the memory in an event retention mode.

[0008] According to a third aspect of an embodiment of the present application, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the above method when executing the computer program.

[0009] According to a fourth aspect of an embodiment of the present application, a computer-readable storage medium is provided, which stores a computer program, and when the computer program is executed by a processor, the steps of the above method are implemented.

[0010] The beneficial effects of the embodiments of the present application compared with the prior art include at least the following: the embodiments of the present application adopt a timer-based de-jittering method, and when the timer times out and the pedometer condition is met, a step size of a step value configured according to the type of diagnostic event is added, and then the fault data is stored, thereby realizing the storage of diagnostic events, which can improve the accuracy and efficiency of storing data during vehicle fault diagnosis. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0012] Figure 1 It is a flowchart of a method for storing diagnostic events provided in an embodiment of the present application;

[0013] Figure 2It is a flowchart of a de-jittering method for a diagnostic event provided in an embodiment of the present application;

[0014] Figure 3 It is a flowchart of a method for storing diagnostic events provided in an embodiment of the present application;

[0015] Figure 4 It is a structural schematic diagram of a storage device for diagnostic events provided in an embodiment of the present application;

[0016] Figure 5 It is a structural schematic diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0017] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0018] In the related technology, the DM (Diagnostics Management) module in AUTOSAR (AUTomotive Open System ARchitecture) can receive and analyze the status of diagnostic events. The status of these diagnostic events can be obtained by fault detection of each electronic device in each vehicle and sent through the corresponding APP (Application Program).

[0019] When performing fault detection, real-time monitoring can be performed based on the preconditions and judgment conditions to determine whether there are potential faults. Usually, PrePassed, Passed, PreFailed, and Failed can be used to indicate the results of the judgment. Among them, faults with the diagnostic event status of Passed and Failed can be directly confirmed without the need to confirm the fault through the Debounce algorithm. Faults with the event status of PrePassed and PreFailed can be called potential faults, which may not be real faults, but only misdiagnosis caused by some signal jitter. The Debounce algorithm is needed to further confirm whether it is a fault.

[0020] Specifically, signal jitter refers to a short unstable signal received in the circuit, which may be caused by power supply noise, physical characteristics of the switch or other interference factors. When performing fault diagnosis, it is usually necessary to monitor the state of the input signal and make corresponding judgments and operations based on the signal state. If the signal jitters, it may lead to misjudgment, resulting in erroneous diagnostic results. The above-mentioned pre-fault state, that is, the preliminary fault state, needs to be further confirmed by the Debounce algorithm; the above-mentioned pre-normal state, that is, the preliminary normal state, also needs to be further confirmed by the Debounce algorithm.

[0021] By applying debounce processing to diagnostic events of potential fault states, short-term signal jitter can be filtered out, so that diagnostic events are triggered only after the signal has stabilized for a period of time. This reduces or avoids false fault alarms and stores them in fault data, ensuring that diagnostic events are triggered only when real faults or errors occur. Debounce processing can improve the reliability of diagnostic systems, reduce unnecessary maintenance or processing operations, and improve vehicle availability and performance.

[0022] The following will describe in detail a method and device for storing diagnostic events according to an embodiment of the present application in conjunction with the accompanying drawings.

[0023] Figure 1 1 is a flow chart of a method for storing diagnostic events provided in an embodiment of the present application. The method provided in an embodiment of the present application can be executed by any electronic device with computer processing capabilities, such as a terminal or a server. In an embodiment of the present application, the method can be executed by a controller of a vehicle. Figure 1 As shown, the storage method of the diagnostic event includes:

[0024] Step S101, when the status of the diagnostic event reported by the received diagnostic application is a pre-fault state or a pre-normal state, the diagnostic event is de-jittered and then the DTC (Diagnostic Trouble Code) is updated according to the status of the diagnostic event, wherein the de-jitter processing adopts a timer-based de-jitter method, when the timer times out and the step counting condition is met, the count value of the fault de-jitter counter is increased by a pre-configured step value, and the step value is configured according to the type of the diagnostic event.

[0025] Specifically, the diagnostic trouble code is a digital universal identifier of a fault state identified by the on-board diagnostic system. Before updating the DTC, de-jitter processing is performed to confirm that the fault information of the diagnostic event is not reported in error. When a problem occurs with the vehicle, the information corresponding to the fault needs to be stored so that the cause of the problem can be quickly located during vehicle maintenance. The stored information includes DTC status bit information. Each ECU (Electronic Control Unit) on the vehicle will correspond a DTC to the Event that needs to be monitored. When the monitored event occurs, the DTC corresponding to the Event will store fault information such as the DTC status bit, that is, the diagnostic trouble code and its corresponding event-related information. These event-related information include snapshot data and extended data, and are not limited to this.

[0026] Step S102, after obtaining the updated diagnostic trouble code, evaluating the storage condition of the memory according to the updated diagnostic trouble code,

[0027] Step S103 , when the memory meets the storage requirement of the diagnostic event, it is determined whether the flag data of the diagnostic fault code corresponding to the event storage entry triggering mode is true according to the event storage entry triggering mode corresponding to the diagnostic event.

[0028] Step S104: if the flag data is true, the diagnostic trouble code and its corresponding event related information are stored in the memory in an event retention manner.

[0029] In the technical solution of the embodiment of the present application, the diagnostic APP reports the four states of Passed, Failed, PrePassed and Prefailed of the event to the DM module. When the event undergoes a series of processing, the DTC state can be updated eventually.

[0030] When the DM module receives the event reported by the diagnostic APP through the monitor as PreFailed or PrePassed, it will debounce the event. During debounce processing, it is determined whether the fault is an event-triggered fault or a timeout fault. If it is a timeout fault, the event is configured as time-based debounce. If it is an event-triggered fault, the event is configured as count-based debounce.

[0031] When the DM module receives the behavior of the diagnostic APP reporting the event through the monitor as Passed or Failed, it directly changes the status bit of the DTC. Specifically, when the status of the diagnostic event reported by the diagnostic application is a fault state, the diagnostic fault code is updated to fault; when the status of the diagnostic event reported by the diagnostic application is a normal state, the diagnostic fault code is updated to normal.

[0032] Before step S101, it can also be determined whether the vehicle has started an operation cycle; and event monitoring is enabled when the vehicle starts an operation cycle. An operation cycle generally refers to an ignition cycle, and an operation cycle can be considered as a cycle of DTC detection. If the operation cycle enabling condition is met, the control diagnostic trouble code setting service judgment is performed, and if the operation cycle enabling condition is not met, the process is directly exited.

[0033] When performing the control diagnostic trouble code setting service judgment, the control diagnostic trouble code setting data can be obtained, and the diagnostic trouble code enable can be determined according to the control diagnostic trouble code setting data. The control diagnostic trouble code setting (Control DTCSetting) service can request the ECU to stop or restore the DTC setting.

[0034] If the control diagnostic trouble code setting service is used to suppress DTC enabling, the entire algorithm process is directly exited. If the control diagnostic trouble code setting service is not executed, step S101 is executed to start the event debounce process.

[0035] After step 101, when the DTC status is updated, DTC confirms whether the event status level reaches the set threshold. When the event status level reaches the set threshold, the first status position is set to true. After that, in step S102, the storage condition check is started. If the storage condition is met, it is determined how the event storage entry is triggered. If the storage condition is not met, the algorithm process is exited directly. There are two common ways to trigger event storage entries: one is Confirmed triggering, and the other is Pending triggering. Regardless of the above triggering method, event retention processing must be performed.

[0036] In step S103, if the event storage entry trigger mode is the confirmation mode, it is determined whether the first status bit of the diagnostic fault code is true, and the first status bit is used to mark whether the event storage entry trigger mode is the confirmation mode; if the event storage entry trigger mode is the pending mode, it is determined whether the second status bit of the diagnostic fault code is true, and the second status bit is used to mark whether the event storage entry trigger mode is the pending mode.

[0037] Specifically, confirmedDTC is the first status bit, which can represent the confirmed storage fault status. False (0) indicates that the storage trigger condition fault has not been met, and True (1) indicates that it has. pendingDTC is the second status bit, which can represent the fault status of the current and previous operation cycles. False indicates that there was no fault in the previous cycle or this cycle, and True indicates that there was a fault.

[0038] In step S104, when the diagnostic trouble code and its corresponding event-related information are stored in the memory by adopting the event retention method, it can be determined first whether the memory stores the corresponding data of the diagnostic event; if not, determine whether there is available storage space in the memory; if so, store the diagnostic trouble code and its corresponding event-related information; if not, replace the diagnostic trouble code and its corresponding event-related information according to the priority of the diagnostic event.

[0039] Specifically, if the Event is not stored, check whether there is free storage space. If there is available storage space, store the corresponding data of the Event. If the storage space is full, the replacement strategy is processed. For example, the diagnostic trouble code and its corresponding event-related information can be replaced according to the priority of the diagnostic event. For example, 200 DTCs are set, and only the fault information of 10 DTCs corresponding to the Event is stored. If the fault information of 10 DTCs has been stored, when there is a new Event fault, the fault information needs to be replaced according to the pre-designed replacement strategy. If the DTC corresponding to the Event cannot replace the stored DTC, the storage fails.

[0040] After step S104, a warning prompt may also be generated when the third state bit of the diagnostic trouble code is false and the first state bit is true, wherein the third state bit is used to mark whether the diagnostic trouble code and its corresponding event-related information are successfully stored in the memory.

[0041] In the event retention process, events, DTC status, snapshot data, and extended data can be stored in the Event Memory. When checking the storage result of the Event, if the event retention process is not satisfied and DemResetConfirmedBitOnOverflow is true, indicating that the event information is not stored, the entire process is exited. Among them, DemResetConfirmedBitOnOverflow is the third state bit.

[0042] If the storage is successful or DemResetConfirmedBitOnOverflow is false, the indicator light's enabling condition is further checked. The enabling condition is that the first status bit is true. If the enabling condition is met, a warning prompt is generated. Specifically, when the triggering condition for the warning prompt is met, the DTC's WarningIndicatorRequest status bit can be set to 1. This bit is set to 1, indicating that when a more serious DTC occurs in the vehicle, a corresponding warning prompt will be given to the driver. The warning indication can be a buzzer, a text prompt on the in-vehicle entertainment system, or an indicator light. If the triggering condition for the warning prompt is not met, the entire algorithm process is directly exited.

[0043] In step S101, when performing event debounce, when the status of the diagnostic event reported by the received diagnostic application is a pre-fault state, the first debounce timer can be started, and the status of the diagnostic event reported by the application diagnostic program can be continuously monitored. When the first debounce timer times out, if the normal state or pre-normal state of the diagnostic event reported by the application diagnostic program is not received during the timing period of the first debounce timer, the count value of FDCounter (Fault DebounceCounter) is increased by a first step length value, wherein the first step length value is set according to the type of diagnostic event. When the count value of the fault debounce counter is equal to the set first threshold value, the fault diagnosis result is determined to be a fault and the first debounce timer is stopped.

[0044] Specifically, the normal state or pre-normal state of not receiving the diagnostic event reported by the application diagnostic program during the timing period of the first de-jitter timer is the step counting condition of the fault de-jitter counter. If the step counting condition is met, the fault de-jitter counter increases by one step each time the first jitter timer times out. The fault de-jitter counter is a counter with a maximum value. The first threshold is the maximum value of the fault de-jitter counter.

[0045] The de-jitter algorithm includes a count-based de-jitter algorithm and a time-based de-jitter algorithm. Among them, the time-based de-jitter algorithm needs to wait for the specified time window and FDCounter to reach the threshold for confirming the fault to determine whether the event is a fault. If FDCounter only increases by one step value within the specified time, it may cause a certain delay while ensuring the diagnostic accuracy. This may have an impact on some applications with high real-time requirements.

[0046] The technical solution of the embodiment of the present application introduces a configurable FDCounter step value based on a time-based de-jitter algorithm. When performing fault diagnosis, the FDCounter step value can be configured according to requirements. Compared with the conventional time-based de-jitter algorithm, configuring the FDCounter step value according to requirements can balance the accuracy and storage efficiency of fault diagnosis, and has better adaptability in different fault scenarios.

[0047] Specifically, a smaller step size may require more computing time and resources because it requires more frequent diagnosis. Conversely, a larger step size can save computing time and resources, but may sacrifice some accuracy. Different fault scenarios may require different step sizes. Some faults may occur and resolve in a very short time, so a smaller step size is required to capture these faults. Other faults may take longer to occur and resolve, so a larger step size may be used to improve efficiency.

[0048] In the technical solution of the embodiment of the present application, the type of diagnostic event can be determined according to the fault scenario, and the first step value and the second step value can be configured according to the type of diagnostic event. The first step value and the second step value are both FDCounter step values. The de-jittering algorithm configured by the FDCounter step value can balance the accuracy and storage efficiency of fault diagnosis, and adaptively adjust according to the specific fault scenario, so that the accuracy and storage efficiency of fault diagnosis can be balanced under the premise of ensuring the accuracy of fault diagnosis and having better adaptability in different fault scenarios. Among them, the type of diagnostic event is the fault type, which can be an engine failure, a fuel system failure, a brake system failure, and a tire blowout failure, and is not limited to this.

[0049] For example, for engine fault diagnosis, a smaller FDCounter step size value may be more suitable. This is because engine faults often involve subtle changes, and a smaller step size can detect these problems more quickly, such as abnormal cylinder pressure or combustion problems. For the diagnosis of fuel system faults, a smaller FDCounter step size value may be more suitable. Fuel system faults often involve small changes in fuel pressure or injection volume, and a smaller step size can detect these problems more quickly. For the diagnosis of brake system faults, a larger FDCounter step size value may be more suitable. Brake system faults often involve large changes in the hydraulic system or brake discs, and a larger FDCounter step size value can better detect these problems. For tire blowouts, a larger FDCounter step size value may be more suitable to detect large changes in tire pressure.

[0050] The diagnostic APP reports the status of the diagnostic event to the DM module. When the DM module receives the diagnostic APP's report of the diagnostic event through the monitor as PreFailed or PrePassed, it performs time-based de-jitter processing on the diagnostic event.

[0051] The diagnostic APP reports the status of the diagnostic event as pre-fault to the DM module through the monitor, and when the DM module receives the status, the first de-jitter timer is started. During the period before the first de-jitter timer times out, the diagnostic event behavior report information is continuously received.

[0052] After starting the first de-bouncing timer, monitor the status of the diagnostic events reported by the application diagnostic program. If all diagnostic APPs report PreFailed and no Passed or PrePassed status information is received during the timing period, then when the first de-bouncing timer times out, increase the FDCounter by a configured step value. If FDCounter does not reach the first threshold, the first de-bouncing timer continues with the next similar timing operation. If the first threshold for confirming the fault is reached, the event is confirmed to be a fault state, that is, the Failed state is determined, and the first de-bouncing timer is stopped.

[0053] After starting the first de-jitter timer, monitor the status of the diagnostic event reported by the application diagnostic program, and when the status of the diagnostic event reported by the received diagnostic application is a fault state, confirm that the fault diagnosis result is a fault, and stop the first de-jitter timer. And when the status of the diagnostic event reported by the received diagnostic application is a normal state, confirm that the current diagnostic event is normal and stop the first de-jitter timer.

[0054] When the diagnostic APP reports the status of the diagnostic event to the DM module through the monitor as pre-normal and is received by the DM module, the second de-jitter timer is started. During the period before the second de-jitter timer times out, the diagnostic event behavior report information continues to be received. In an embodiment of the present application, the timing durations of the first de-jitter timer and the second de-jitter timer can be the same or different.

[0055] Specifically, when the status of the diagnostic event reported by the diagnostic application is received as a pre-normal state, the second de-bouncing timer is started, and the status of the diagnostic event reported by the application diagnostic program continues to be monitored; when the second de-bouncing timer times out, if the fault state or pre-fault state of the diagnostic event reported by the application diagnostic program is not received during the timing period of the second de-bouncing timer, the count value of the fault de-bouncing counter is increased by a second step value; when the count value of the fault de-bouncing counter is equal to the second threshold value, the fault diagnosis result is determined to be normal and the second de-bouncing timer is stopped.

[0056] In the embodiment of the present application, the first threshold value and the second threshold value may be the same or different. The first threshold value is the maximum value of the first de-jitter timer, and the second threshold value is the maximum value of the second de-jitter timer. The first step length value and the second step length value may be the same or different, and both may be adjusted independently according to the fault scenario.

[0057] After starting the second de-bouncing timer, monitor the status of the diagnostic events reported by the application diagnostic program. If all diagnostic APPs report PrePassed and no Failed or PreFailed status information is received during the timing period, then when the second de-bouncing timer times out, increase the FDCounter by a configured step value. If FDCounter does not reach the second threshold, the second de-bouncing timer continues with the next similar timing operation. If the second threshold for confirming the fault is reached, the event is confirmed to be in a normal state, that is, the Passed state is determined, and the second de-bouncing timer is stopped.

[0058] After starting the second de-jitter timer, monitor the status of the diagnostic event reported by the application diagnostic program, and when the status of the diagnostic event reported by the received diagnostic application is a fault state, confirm that the current diagnostic event is a fault and stop the second de-jitter timer. And when the status of the diagnostic event reported by the received diagnostic application is a normal state, confirm that the fault diagnosis result is normal and stop the second de-jitter timer.

[0059] After increasing the count value of the fault de-bouncing counter by the first step length value, the status of the diagnostic event reported by the application diagnostic program can continue to be monitored; and when the status of the diagnostic event reported by the application diagnostic program is a pre-fault state, start the first de-bouncing timer, and when the first de-bouncing timer times out, if the normal state or pre-normal state of the diagnostic event reported by the application diagnostic program is not received during the timing period of the current first de-bouncing timer, the count value of the fault de-bouncing counter is increased by the first step length value.

[0060] Before step S101, it can be determined whether the fault type of the diagnostic event is an event-triggered fault or a timeout fault; if it is a timeout fault, it is determined that the diagnostic event is configured as time-based debounce, and then step S101 is executed. If it is an event-triggered fault, the event is configured as count-based debounce, and step S101 is not executed.

[0061] like Figure 2As shown, after the diagnostic APP uploads the status of the diagnostic event, when the status is PreFailed and PrePassed respectively, the storage scheme of the diagnostic event in the embodiment of the present application is executed. When the status is PreFailed, start the first de-jitter timer with a timing duration of t1. When the status is PrePassed, start the second de-jitter timer with a timing duration of t2. After starting the first de-jitter timer with a timing duration of t1, determine whether it exceeds the timing duration t1 of the timer. Then continue to receive the status of the diagnostic event. When the duration does not exceed t1, if the reported status is Failed or Passed, cancel the timer. When the duration exceeds t1, determine whether PrePassed or Passed is received during the timing period. If so, restart the first de-jitter timer. If not, FDCounter increases a configured step size. When FDCounter reaches the first threshold, it can be confirmed that the event status is Failed. The steps after starting the second de-jitter timer with a timing duration of t2 are similar to the method steps after starting the first de-jitter timer with a timing duration of t1. For details, see. Figure 2 .

[0062] In the technical solution of the embodiment of the present application, the efficiency of fault diagnosis can be adjusted by configuring the FDCounter step value. By configuring different step values ​​for different fault scenarios, the FDCounter step value can be adaptively adjusted according to the specific fault scenario. The technical solution of the embodiment of the present application introduces a configurable FDCounter step value to de-jitter diagnostic events on the basis of a time-based de-jitter algorithm, that is, the FDCounter step value can be configured according to demand when performing fault diagnosis. The technical solution of the embodiment of the present application achieves a balance between the accuracy and efficiency of fault diagnosis, and increases the adaptability of the de-jitter algorithm in specific fault scenarios.

[0063] like Figure 3 Shown is a flow chart of a method for storing diagnostic events according to an embodiment of the present application. On the basis of a time-based de-jittering algorithm, a configurable FDCounter step value is introduced to de-jitter diagnostic events, and further after confirming the fault, confirm whether the fault level has reached the set level, and set the first state position to true when it reaches it. Then, check the storage conditions, and further confirm whether the memory meets the storage conditions, and when the storage conditions are met, determine whether to perform event retention processing according to the event storage entry triggering method. After the event retention processing is performed, a warning prompt can also be generated according to the storage situation.

[0064] According to the storage method of diagnostic events in the embodiment of the present application, by adopting a timer-based de-jittering method, a step size of a step value configured according to the type of diagnostic event is added when the timer times out and the pedometer condition is met, and then the fault data is stored, thereby realizing the storage of diagnostic events, which can improve the accuracy and efficiency of storing data during vehicle fault diagnosis.

[0065] The following is an embodiment of the device of the present application, which can be used to execute the embodiment of the method of the present application. The storage device of the diagnostic event described below and the storage method of the diagnostic event described above can be referred to each other. For details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the method of the present application.

[0066] Figure 4 Schematic diagram of a storage device for diagnostic events provided by an embodiment of the present application. Figure 4 As shown, the storage device for diagnostic events in the embodiment of the present application includes:

[0067] Update module 401 is used to update the diagnostic fault code according to the status of the diagnostic event after de-jittering the diagnostic event when the status of the diagnostic event reported by the received diagnostic application is a pre-fault state or a pre-normal state, wherein the de-jittering process adopts a timer-based de-jittering method, and when the timer times out and the step counting condition is met, the count value of the fault de-jitter counter is increased by a pre-configured step value, and the step value is configured according to the type of the diagnostic event.

[0068] The evaluation module 402 is used to evaluate the storage condition of the memory according to the updated diagnostic trouble code after acquiring the updated diagnostic trouble code.

[0069] The judgment module 403 is used to judge whether the flag data of the diagnostic fault code corresponding to the event storage entry triggering mode is true according to the event storage entry triggering mode corresponding to the diagnostic event when the memory meets the storage requirement of the diagnostic event.

[0070] The storage module 404 is used to store the diagnostic trouble code and its corresponding event related information into the memory in an event retention manner when the flag data is true.

[0071] Since the various functional modules of the storage device for diagnostic events of the example embodiment of the present application correspond to the steps of the example embodiment of the storage method for diagnostic events described above, for details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the storage method for diagnostic events described above in the present application.

[0072] According to the storage device for diagnostic events in the embodiment of the present application, a timer-based de-jittering method is adopted to increase a step size of a step value configured according to the type of diagnostic event when the timer times out and the pedometer condition is met, and then the fault data is stored, thereby realizing the storage of diagnostic events and improving the accuracy and efficiency of storing data during vehicle fault diagnosis.

[0073] Figure 5 Schematic diagram of an electronic device 5 provided in an embodiment of the present application. Figure 5 As shown, the electronic device 5 of this embodiment includes: a processor 501, a memory 502, and a computer program 503 stored in the memory 502 and executable on the processor 501. When the processor 501 executes the computer program 503, the steps in the above-mentioned method embodiments are implemented. Alternatively, when the processor 501 executes the computer program 503, the functions of the modules in the above-mentioned device embodiments are implemented.

[0074] The electronic device 5 may be a desktop computer, a notebook, a PDA, a cloud server, or other electronic device. The electronic device 5 may include, but is not limited to, a processor 501 and a memory 502. Those skilled in the art will appreciate that Figure 5 The electronic device 5 is merely an example and does not limit the electronic device 5 , and may include more or less components than those shown in the figure, or different components.

[0075] The processor 501 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0076] The memory 502 may be an internal storage unit of the electronic device 5, for example, a hard disk or memory of the electronic device 5. The memory 502 may also be an external storage device of the electronic device 5, for example, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the electronic device 5. The memory 502 may also include both an internal storage unit of the electronic device 5 and an external storage device. The memory 502 is used to store computer programs and other programs and data required by the electronic device.

[0077] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units.

[0078] If the integrated module is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. The computer program may include computer program code, and the computer program code may be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium does not include electric carrier signals and telecommunication signals.

[0079] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A method for storing diagnostic events, characterized in that: The method comprises: Confirm that the fault type of the diagnostic event is a timeout fault; When the status of a diagnostic event reported by a received diagnostic application is a pre-fault state or a pre-normal state, the diagnostic event is de-jittered and then the diagnostic fault code is updated according to the status of the diagnostic event, wherein the de-jitter processing adopts a timer-based de-jitter method, when the timer times out and the step counting condition is met, the count value of the fault de-jitter counter is increased by a pre-configured step value, and the timer is started again, and the status of the diagnostic event is confirmed when the count value of the fault de-jitter counter reaches a preset threshold, and the step value is configured according to the type of the diagnostic event; After acquiring the updated diagnostic trouble code, evaluating a storage condition of the memory according to the updated diagnostic trouble code; When the memory meets the storage requirement of the diagnostic event, judging whether the flag data of the diagnostic fault code corresponding to the event storage entry triggering mode is true according to the event storage entry triggering mode corresponding to the diagnostic event; If the flag data is true, the diagnostic trouble code and its corresponding event related information are stored in the memory in an event retention manner.

2. The method according to claim 1, characterized in that: Before receiving the diagnostic event reported by the diagnostic application, the method further includes: A control diagnostic trouble code setting data is obtained, and the diagnostic trouble code enable is determined according to the control diagnostic trouble code setting data.

3. The method according to claim 1, characterized in that Before receiving the diagnostic event reported by the diagnostic application, the method further includes: Determine whether the vehicle starts an operation cycle; Event monitoring enablement is determined during the vehicle on operation cycle.

4. The method according to claim 1, characterized in that Before obtaining the updated diagnostic trouble code, the method further includes: When the state of the diagnostic event reported by the diagnostic application is a fault state, updating the diagnostic fault code to a fault; When the status of the diagnostic event reported by the diagnostic application is received as a normal status, the diagnostic fault code is updated to normal.

5. The method according to claim 1, characterized in that Determining whether the flag data of the diagnostic fault code corresponding to the event storage entry triggering mode is true according to the event storage entry triggering mode corresponding to the diagnostic event includes: If the event storage entry triggering mode is the confirmation mode, determining whether the first state bit of the diagnostic trouble code is true, the first state bit being used to mark whether the event storage entry triggering mode is the confirmation mode; If the event storage entry triggering mode is a pending mode, it is determined whether the second status bit of the diagnostic trouble code is true, and the second status bit is used to mark whether the event storage entry triggering mode is a pending mode.

6. The method according to claim 1, characterized in that The diagnostic trouble code and its corresponding event related information are stored in the memory in an event retention manner, including: determining whether the memory stores data corresponding to the diagnostic event; If not, determining whether there is available storage space in the memory; If yes, the diagnostic trouble code and the corresponding event related information are stored; if no, the diagnostic trouble code and the corresponding event related information are replaced according to the priority of the diagnostic event.

7. The method according to claim 5, characterized in that After storing the diagnostic trouble code and its corresponding event related information in the memory in an event retention manner, the method further includes: When the third state bit of the diagnostic trouble code is false and the first state bit is true, a warning prompt is generated, wherein the third state bit is used to mark whether the diagnostic trouble code and its corresponding event-related information are successfully stored in the memory.

8. A storage device for diagnostic events, characterized in that: The device comprises: An update module, used to confirm that the fault type of the diagnostic event is a timeout fault, and when the status of the diagnostic event reported by the received diagnostic application is a pre-fault state or a pre-normal state, the diagnostic event is de-jittered and then the diagnostic fault code is updated according to the status of the diagnostic event, wherein the de-jittering process adopts a timer-based de-jittering method, when the timer times out and meets the step counting condition, the count value of the fault de-jitter counter is increased by a pre-configured step value, and the timer is started again, and the status of the diagnostic event is confirmed when the count value of the fault de-jitter counter reaches a preset threshold, and the step value is configured according to the type of the diagnostic event; An evaluation module, configured to evaluate a storage condition of a memory according to the updated diagnostic trouble code after acquiring the updated diagnostic trouble code; A judgment module, used for judging whether the flag data of the diagnostic fault code corresponding to the event storage entry triggering mode is true according to the event storage entry triggering mode corresponding to the diagnostic event when the memory meets the storage requirement of the diagnostic event; The storage module is used to store the diagnostic trouble code and its corresponding event related information into the memory in an event retention manner when the flag data is true.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images