Fault information de-jittering method, device, electronic device and readable storage medium

Abstract

The present application provides a fault information de-jittering method, device, electronic device and readable storage medium. The method includes: when the status of the diagnostic event reported by the diagnostic application is a pre-fault state, starting the first de-jitter timer and continuing to monitor the status of the diagnostic event reported by the diagnostic application; when the first de-jitter timer times out, if the normal state or pre-normal state of the diagnostic event reported by the diagnostic application is not received during the timing period of the first de-jitter timer, then the count value of the fault de-jitter counter is increased by a first step length value, wherein the first step length value is set according to the type of the diagnostic event; when the count value of the fault de-jitter counter is equal to the set first threshold value, determining that the fault diagnosis result is a fault and stopping the first de-jitter timer. The technical solution of the present application can balance the accuracy and efficiency of fault diagnosis.

Description

Technical Field

[0001] The present application relates to the field of intelligent driving technology, and in particular to a fault information de-jittering method, device, electronic device and readable storage medium. 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 is a technical problem that needs to be solved urgently. Summary of the invention

[0005] In view of this, the embodiments of the present application provide a fault information de-jittering method, device, electronic device and readable storage medium to solve the technical problem of false fault reporting in the vehicle fault diagnosis process.

[0006] According to a first aspect of an embodiment of the present application, a method for de-bouncing fault information is provided, the method comprising: when the status of a diagnostic event reported by a diagnostic application is a pre-fault status, starting a first de-bouncing timer and continuing to monitor the status of the diagnostic event reported by the diagnostic application; when the first de-bouncing timer times out, if the normal status or pre-normal status of the diagnostic event reported by the diagnostic application is not received during the timing period of the first de-bouncing timer, increasing the count value of the fault de-bouncing counter by a first step length value, wherein the first step length value is set according to the type of the diagnostic event; when the count value of the fault de-bouncing counter is equal to a set first threshold value, determining that the fault diagnosis result is a fault and stopping the first de-bouncing timer.

[0007] According to a second aspect of an embodiment of the present application, a fault information de-bouncing device is provided, which includes: a starting module, which is used to start a first de-bouncing timer and continue to monitor the status of the diagnostic event reported by the diagnostic application when the status of the diagnostic event reported by the diagnostic application is a pre-fault state; a timeout processing module, which is used to increase the count value of the fault de-bouncing counter by a first step length value when the first de-bouncing timer times out, if the normal state or pre-normal state of the diagnostic event reported by the diagnostic application is not received during the timing period of the first de-bouncing timer, wherein the first step length value is set according to the type of the diagnostic event; and a determination module, which is used to determine that the fault diagnosis result is a fault and stop the first de-bouncing timer when the count value of the fault de-bouncing counter is equal to a set first threshold value.

[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 embodiments of the present application set the first step length value according to the type of diagnostic event, add a first step length value when the first de-jitter timer times out and the step counting condition is met, and determine the fault diagnosis result when the fault de-jitter counter reaches the first threshold, so as to realize fault diagnosis de-jitter according to the fault scenario, thereby improving the accuracy and efficiency of 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 fault information de-jittering method provided in an embodiment of the present application;

[0013] Figure 2 It is a flow chart of a fault information de-jittering system provided in an embodiment of the present application;

[0014] Figure 3 It is a flowchart of another fault information de-jittering method provided in an embodiment of the present application;

[0015] Figure 4 It is a structural schematic diagram of a fault information de-jittering device 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 been stable for a period of time. This reduces or avoids false fault alarms and ensures 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 fault information de-jittering method and device according to the embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0023] Figure 1 is a flow chart of a fault information de-jittering method 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 vehicle controller. Figure 1 As shown, the fault information de-jittering method includes:

[0024] Step S101 : when the status of the diagnostic event reported by the diagnostic application is a pre-failure status, start a first de-jitter timer, and continue to monitor the status of the diagnostic event reported by the diagnostic application.

[0025] Step S102, when the first de-bounce timer times out, if the normal state or pre-normal state of the diagnostic event reported by the diagnostic application is not received during the timing period of the first de-bounce timer, the count value of FDCounter (FaultDebounce Counter) is increased by a first step length value, wherein the first step length value is set according to the type of the diagnostic event.

[0026] Specifically, the normal state or pre-normal state of not receiving the diagnostic event reported by the diagnostic application during the timing of the first de-jitter timer is a 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 de-jitter timer times out. The fault de-jitter counter is a counter with a maximum value set.

[0027] Step S103: when the count value of the fault de-bouncing counter is equal to the set first threshold, determine that the fault diagnosis result is a fault and stop the first de-bouncing timer.

[0028] Specifically, the first threshold is the maximum value of the fault debounce counter.

[0029] 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.

[0030] 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 efficiency of fault diagnosis, and has better adaptability in different fault scenarios.

[0031] 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.

[0032] 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-jitter algorithm configured by the FDCounter step value can balance the accuracy and efficiency of fault diagnosis, and adaptively adjust according to the specific fault scenario, so that the accuracy and efficiency of fault diagnosis can be balanced under the premise of ensuring the accuracy of fault diagnosis and it has better adaptability in different fault scenarios. Among them, the type of diagnostic event is the fault type, which can be engine failure, fuel system failure, brake system failure and tire blowout failure, and is not limited to this.

[0033] 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.

[0034] like Figure 2 As shown, 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, the diagnostic event will be debounced based on time. Among them, monitor 1 is located in the diagnostic APP A, monitors 2 and 3 are located in the diagnostic APP B, and each monitor can correspond to a fault type.

[0035] The diagnostic APP reports the status of the diagnostic event as pre-fault to the DM module through the monitor, and when the DM 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.

[0036] After starting the first de-bouncing timer in step S101, monitor the status of the diagnostic events reported by the diagnostic application. If all the diagnostic APPs report PreFailed and no Passed or PrePassed status information is received during the timing period, execute step S102. When the first de-bouncing timer times out, increase a configured step value for FDCounter. 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, execute step S103 to confirm that the event is a fault state, that is, determine the Failed state, and stop the first de-bouncing timer.

[0037] After the first de-jitter timer is started in step S101, the status of the diagnostic event reported by the diagnostic application is monitored, and when the status of the diagnostic event reported by the diagnostic application is a fault state, the fault diagnosis result is confirmed to be a fault, and the first de-jitter timer is stopped. And when the status of the diagnostic event reported by the diagnostic application is a normal state, the current diagnostic event is confirmed to be normal, and the first de-jitter timer is stopped.

[0038] 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.

[0039] 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 diagnostic application 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 diagnostic application 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.

[0040] 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.

[0041] After starting the second de-bouncing timer, monitor the status of the diagnostic events reported by the diagnostic application. If all the 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 the 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.

[0042] After starting the second de-jitter timer, monitor the status of the diagnostic event reported by the diagnostic application, and when the status of the diagnostic event reported by the 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 diagnostic application is a normal state, confirm that the fault diagnosis result is normal and stop the second de-jitter timer.

[0043] After increasing the count value of the fault de-bouncing counter by the first step length value in step S102, the status of the diagnostic event reported by the diagnostic application can continue to be monitored; and when the status of the diagnostic event reported by the diagnostic application 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 diagnostic application 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.

[0044] 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.

[0045] like Figure 3 As shown, after the diagnostic APP uploads the status of the diagnostic event, when the status is PreFailed and PrePassed respectively, the fault information de-bouncing scheme in the embodiment of the present application is executed. When the status is PreFailed, start the first de-bouncing timer with a timing duration of t1. When the status is PrePassed, start the second de-bouncing timer with a timing duration of t2. After starting the first de-bouncing 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-bouncing 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-bouncing timer with a timing duration of t2 are similar to the method steps after starting the first de-bouncing timer with a timing duration of t1. For details, see. Figure 3 .

[0046] 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 fault information 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.

[0047] According to the fault information de-jittering method of the embodiment of the present application, by setting the first step length value according to the type of diagnostic event, adding a first step length value when the first de-jitter timer times out and the step counting condition is met, and determining the fault diagnosis result when the fault de-jitter counter reaches the first threshold, fault diagnosis de-jittering can be achieved according to the fault scenario, thereby improving the accuracy and efficiency of fault diagnosis.

[0048] 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 fault information de-jittering device described below and the fault information de-jittering method 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.

[0049] Figure 4 Schematic diagram of a fault information de-jittering device provided in an embodiment of the present application. Figure 4 As shown, the fault information de-jittering device in the embodiment of the present application includes:

[0050] The starting module 401 is used to start a first de-jitter timer when the status of the diagnostic event reported by the diagnostic application is a pre-failure status, and continue to monitor the status of the diagnostic event reported by the diagnostic application.

[0051] The timeout processing module 402 is used to increase the count value of the fault de-bouncing counter by a first step length value when the first de-bouncing timer times out, if the normal state or pre-normal state of the diagnostic event reported by the diagnostic application is not received during the timing period of the first de-bouncing timer, wherein the first step length value is set according to the type of the diagnostic event.

[0052] The determination module 403 is used to determine that the fault diagnosis result is a fault and stop the first de-jitter timer when the count value of the fault de-jitter counter is equal to a set first threshold.

[0053] The startup module 401 can also be used to start the second de-jitter timer when the status of the diagnostic event reported by the diagnostic application is a pre-normal state, and continue to monitor the status of the diagnostic event reported by the diagnostic application; when the second de-jitter timer times out, if the fault state or pre-fault state of the diagnostic event reported by the diagnostic application is not received during the timing period of the second de-jitter timer, the count value of the fault de-jitter counter is increased by a second step value; when the count value of the fault de-jitter counter is equal to the second threshold value, the fault diagnosis result is determined to be normal and the second de-jitter timer is stopped. In an embodiment of the present application, the first threshold value and the second threshold value may be the same or different in size. 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 value and the second step value may be the same or different in size, and both may be independently adjusted according to the fault scenario.

[0054] The timeout processing module 402 can also be used to continue monitoring the status of the diagnostic event reported by the diagnostic application after increasing the count value of the fault de-bouncing counter by the first step length value; and when the status of the diagnostic event reported by the diagnostic application 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 diagnostic application is not received during the timing period of the current first de-bouncing timer, then increase the count value of the fault de-bouncing counter by the first step length value.

[0055] The fault information de-jittering device in the embodiment of the present application may also include a judgment module, which can be used to judge 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 to configure the diagnostic event as time-based de-jittering, and then the fault information de-jittering device performs the fault information de-jittering method steps of the embodiment of the present application. If it is an event-triggered fault, the event is configured as count-based de-jittering, and the fault information de-jittering method steps of the embodiment of the present application are no longer performed.

[0056] The fault information de-jittering device in the embodiment of the present application may further include a configuration module, which can be used to determine the type of the diagnostic event according to the fault scenario, and configure the first step length value and the second step length value according to the type of the diagnostic event.

[0057] 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. Therefore, on the basis of the time-based de-jittering algorithm, a method of configurable FDCounter step value is introduced to de-jitter fault information, 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-jittering algorithm in specific fault scenarios.

[0058] Since the various functional modules of the fault information de-jittering device of the example embodiment of the present application correspond to the steps of the example embodiment of the above-mentioned fault information de-jittering method, for details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the above-mentioned fault information de-jittering method of the present application.

[0059] According to the fault information de-jittering device of the embodiment of the present application, by setting the first step length value according to the type of diagnostic event, adding a first step length value when the first de-jitter timer times out and the step counting condition is met, and determining the fault diagnosis result when the fault de-jitter counter reaches the first threshold, it is possible to de-jitter the fault diagnosis according to the fault scenario, thereby improving the accuracy and efficiency of the fault diagnosis.

[0060] 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.

[0061] 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.

[0062] 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.

[0063] 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.

[0064] 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.

[0065] 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.

[0066] 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 fault information de-jittering method, characterized in that: The method comprises: Confirm that the fault type of the diagnostic event is a timeout fault; When the state of the diagnostic event reported by the diagnostic application is a pre-failure state, starting a first de-jitter timer, and continuing to monitor the state of the diagnostic event reported by the diagnostic application; When the first de-bounce timer times out, if a normal state or a pre-normal state of the diagnostic event reported by the diagnostic application is not received during the timing period of the first de-bounce timer, the count value of the fault de-bounce counter is increased by a first step length value, wherein the first step length value is set according to the type of the diagnostic event; When the count value of the fault de-bounce counter does not reach a set first threshold, restarting the first de-bounce timer and continuing to monitor the status of the diagnostic event reported by the diagnostic application; When the count value of the fault de-bouncing counter is equal to a set first threshold, it is determined that the fault diagnosis result is a fault and the first de-bouncing timer is stopped.

2. The method according to claim 1, characterized in that After starting the first de-jitter timer, the method further includes: When receiving the diagnosis event reported by the diagnosis application as a fault state, confirming that the fault diagnosis result is a fault, and stopping the first de-jitter timer; When the state of the diagnostic event reported by the diagnostic application is received as a normal state, the first de-jitter timer is stopped.

3. The method according to claim 1, characterized in that The method comprises: When the state of the diagnostic event reported by the diagnostic application is received as a pre-normal state, starting a second de-jitter timer, and continuing to monitor the state of the diagnostic event reported by the diagnostic application; When the second de-jitter timer times out, if the fault state or pre-fault state of the diagnostic event reported by the diagnostic application is not received during the timing period of the second de-jitter timer, the count value of the fault de-jitter counter is increased by a second step value; When the count value of the fault de-bouncing counter is equal to the second threshold, it is determined that the fault diagnosis result is normal and the second de-bouncing timer is stopped.

4. The method according to claim 3, characterized in that: After starting the second de-jitter timer, the method further includes: When the state of the diagnostic event reported by the diagnostic application is received as a normal state, confirming that the fault diagnosis result is normal and stopping the second de-jitter timer; When the state of the diagnostic event reported by the diagnostic application is a fault state, the second de-jitter timer is stopped.

5. The method according to claim 1, characterized in that Before increasing the count value of the fault debounce counter by a first step length value, the method further includes: Determining the type of the diagnostic event according to the fault scenario; The first step length value is configured according to the type of the diagnostic event.

6. A fault information de-jittering device, characterized in that: The device comprises: A judgment module, used to confirm that the fault type of the diagnostic event is a timeout fault; A starting module, configured to start a first de-jitter timer when the state of the diagnostic event reported by the diagnostic application is a pre-failure state, and continue to monitor the state of the diagnostic event reported by the diagnostic application; a timeout processing module, configured to, when the first de-jitter timer times out, increase the count value of the fault de-jitter counter by a first step length value if the normal state or pre-normal state of the diagnostic event reported by the diagnostic application is not received during the timing period of the first de-jitter timer, wherein the first step length value is set according to the type of the diagnostic event; The timeout processing module is further used for: restarting the first de-jitter timer when the count value of the fault de-jitter counter does not reach the set first threshold value, and continuing to monitor the status of the diagnostic event reported by the diagnostic application; The determination module is used to determine that the fault diagnosis result is a fault and stop the first de-jitter timer when the count value of the fault de-jitter counter is equal to a set first threshold.

7. 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 5 are implemented.

8. 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 5 are implemented.

Images