Optimization method based on automobile electric control system fault diagnosis anti-shake logic
By setting a combination strategy of anti-shake time counting constant and fault counting constant, the fault diagnosis logic of automotive electronic control system is optimized, solving the problems of false alarms and missed alarms in the existing technology, and improving the accuracy and reliability of fault detection.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-24
- Publication Date
- 2026-03-31
AI Technical Summary
Existing automotive electronic control system fault diagnosis logic struggles to achieve an effective balance between anti-interference capability and fault identification sensitivity, leading to false alarms and missed faults, which affect system reliability and driving safety.
A combined strategy of debounce time counting constant Debounce_x and debounce fault counting constant Debounce_y is adopted. By setting initial constants and counter logic, unified fault diagnosis of continuous detection type and discrete detection type is realized to prevent false alarms and missed alarms.
It improves the accuracy and robustness of fault detection, reduces the workload of software development, enhances the reliability and reusability of fault detection logic, and prevents fault flag bits from being abnormally cleared.
Smart Images

Figure CN121764035A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of automotive electronic control fault diagnosis, and in particular to an optimization method based on anti-shake logic for fault diagnosis of automotive electronic control systems. Background Technology
[0002] With the rapid development of automotive electronics and intelligence, modern cars have become complex networks composed of dozens or even hundreds of electronic control units, which control key systems such as the engine, transmission, brakes, steering, and airbags. Fault diagnosis logic is an embedded set of "monitoring programs" or "decision rules".
[0003] In the current fault diagnosis logic of automotive electronic control systems, two typical problems commonly exist: one is "false alarms," where the system incorrectly identifies a normal state as a fault; the other is "false failures," where the system should have detected and reported a fault but failed to do so. These two types of problems directly affect the reliability of the electronic control system and the functional safety of the entire vehicle.
[0004] The shortcomings and deficiencies of existing technologies mainly lie in the rationality of the fault reporting logic design. Specifically: First, if the system is designed to "report faults immediately upon receiving a fault signal," while ensuring timely fault reporting, it is highly susceptible to false triggers due to momentary signal fluctuations or external interference. For example, in complex electromagnetic environments, sensor signals may experience brief interference and jumps. If the diagnostic logic does not have appropriate filtering or delayed judgment settings, false fault reports will occur frequently. Once a false alarm occurs, the system often enters a fault protection mode, such as limiting engine power or triggering an alarm, which directly affects the driver's normal driving experience and may even lead to driving safety risks due to unnecessary degraded control.
[0005] Secondly, for certain types of faults, such as open circuits or short circuits in temperature sensors, the output fault signals may exhibit discrete and non-continuous characteristics. If the diagnostic logic is set to "a fault is determined only after x consecutive detections of the fault signal," then such intermittent faults will be ignored by the system because they cannot meet the "continuous triggering" condition, leading to missed fault detection. For example, when a sensor intermittently fails due to poor contact, the fault signal is intermittent and cannot form a continuous count, thus the system cannot accurately identify the fault. Such missed detections will prevent potential fault hazards from being dealt with in a timely manner, and long-term accumulation may lead to component damage or system malfunction, also constituting a safety hazard.
[0006] In summary, existing fault diagnosis logic has not yet achieved an effective balance between signal anti-interference capability and fault identification sensitivity. There is an urgent need for a more intelligent and adaptive diagnostic strategy to improve the accuracy and robustness of fault detection. Summary of the Invention
[0007] The purpose of this invention is to overcome the shortcomings of the prior art and provide an optimized method based on the anti-shake logic of fault diagnosis in automotive electronic control systems.
[0008] The objective of this invention is achieved through the following technical solution: A first aspect of the present invention provides an optimization method based on anti-shake logic for fault diagnosis in automotive electronic control systems, comprising the following steps: S1: Set initial constants, including the stabilization time count constant Debounce_x and the stabilization fault count constant Debounce_y; when the stabilization time count constant Debounce_x and the stabilization fault count constant Debounce_y are equal, the fault diagnosis stabilization logic is continuous detection; when the stabilization time count constant Debounce_x is greater than the stabilization fault count constant Debounce_y, the fault diagnosis stabilization logic is discrete detection. S2: Increment the value of the first time counter x by 1; S3: Determine the value of the first time counter x and the size of the anti-shake time counting constant Debounce_x. If the value of the first time counter x is greater than the anti-shake time counting constant Debounce_x, after maintaining the current value of the fault flag bit FaultActv and the current value of the second time counter y, and clearing the value of the first time counter x, return to step S2; otherwise, proceed to step S4. S4: Determine if the fault signal FaultFlag is equal to 1. If FaultFlag is equal to 1, increment the value of the second time counter y by 1, and then further determine if the value of the second time counter y is greater than or equal to the anti-shake fault count constant Debounce_y. If the second time counter y is greater than or equal to Debounce_y, set the fault flag FaultActv to 1 and report the fault. If the second time counter y is less than Debounce_y, set the fault flag FaultActv to 0 and return to step S2. If FaultFlag is not equal to 1, proceed to step S5. S5: Increment the value of the count counter Counter by one, and determine whether the value of the count counter Counter is greater than or equal to the preset value. If the value of the count counter Counter Counter is greater than or equal to the preset value, then output that the fault flag bit FaultActv is set to 0 and the value of the second time counter y is set to 0, and then return to step S2; otherwise, after keeping the current value of the fault flag bit FaultActv and the current value of the second time counter y, return to step S2.
[0009] Furthermore, the preset value is 3.
[0010] The beneficial effects of the present invention are as follows: In an exemplary embodiment of the present invention, (1) By setting the debounce time count constant Debounce_x and the debounce fault count constant Debounce_y respectively, the fault debounce logic is unified, so that the fault confirmation logic can be universal for both "continuous detection type" and "discrete detection type", thereby reducing the workload in the software development process and improving the reusability of the software when developing different fault judgment logics.
[0011] (2) By setting a fault clearing cycle, the abnormal clearing of the fault flag bit FaultActv due to fluctuations in the fault signal FaultFlag after the fault is set is prevented.
[0012] (3) By designing "discrete detection" logic, the software is prevented from failing to report the fault when the fault signal fluctuates between high and low levels because it cannot detect continuous fault signals. This improves the reliability of the fault detection logic. Attached Figure Description
[0013] Figure 1 A flowchart illustrating an exemplary embodiment of the present invention, showing an optimization method based on anti-shake logic for fault diagnosis of an automotive electronic control system; Figure 2 A schematic diagram of the judgment logic for step S3 provided in an exemplary embodiment of the present invention; Figure 3 A schematic diagram of the judgment logic for step S4 provided in an exemplary embodiment of the present invention; Figure 4 A schematic diagram of the judgment logic for one branch of step S4 provided in an exemplary embodiment of the present invention; Figure 5 A schematic diagram of the judgment logic of step S5, another branch of step S4, provided for an exemplary embodiment of the present invention; Figure 6 A schematic diagram of a Chart module in Simulink provided as an exemplary embodiment of the present invention; Figure 7 A schematic diagram of the test results for the logic of "preventing the abnormal clearing of the fault flag bit FaultActv due to fluctuations in the fault signal FaultFlag after fault triggering" provided in an exemplary embodiment of the present invention. Figure 8 A schematic diagram of the test results for the logic of "when the fault flag bit FaultActv is intermittently transmitted, the fault can be detected and reported in a timely manner" provided as an exemplary embodiment of the present invention; Figure 9 A schematic diagram of the test results for the zeroing logic of the debounce fault count constant Debounce_y provided as an exemplary embodiment of the present invention; Figure 10 This is a schematic diagram of the test results provided for an exemplary embodiment of the present invention, which shows that "when the first time counter x and the second time counter y are equal, the fault can be triggered". Detailed Implementation
[0014] The technical solution of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. Furthermore, the technical features involved in the different embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.
[0015] See Figure 1 , Figure 1 A flowchart of an optimized method for fault diagnosis and anti-shake logic based on an exemplary embodiment of the present invention is shown. The logic of this method can either "report a fault only after detecting a fault signal within x consecutive cycles" or "report a fault after detecting x fault signals within a certain cycle," and the logic of both methods is universal. The method includes the following steps: S1: Set initial constants, including the stabilization time count constant Debounce_x and the stabilization fault count constant Debounce_y; when the stabilization time count constant Debounce_x and the stabilization fault count constant Debounce_y are equal, the fault diagnosis stabilization logic is continuous detection; when the stabilization time count constant Debounce_x is greater than the stabilization fault count constant Debounce_y, the fault diagnosis stabilization logic is discrete detection. Specifically, in this step, to achieve y detections within x cycles, whether it is continuous or discrete detection, a first time counter x can be set at the outermost layer of the model as a limit to the total detection interval; within this interval, a second time counter y is set as a fault signal set count.
[0016] If it is a continuous detection strategy, then the value of the debounce fault count constant Debounce_y for the fault signal set count is equal to the debounce time count constant Debounce_x for the total detection interval limit, that is: y = x; if it is a discrete detection strategy, then the value of the debounce fault count constant Debounce_y is less than the debounce time count constant Debounce_x for the total limit interval, that is: y < x.
[0017] For example: (1) If a fault is detected 10 times consecutively within 10 cycles, then according to the above logic, the stabilization time count constant Debounce_x is set to 10, and the stabilization fault count constant Debounce_y is also set to 10. (2) If a fault is detected as soon as 6 times within 10 cycles, then according to the above logic, the stabilization time count constant Debounce_x is set to 10, and the stabilization fault count constant Debounce_y is set to 6. These settings can be adjusted according to the actual situation.
[0018] S2: Increment the value of the first time counter x by 1; S3: Determine the value of the first time counter x and the size of the anti-shake time counting constant Debounce_x. If the value of the first time counter x is greater than the anti-shake time counting constant Debounce_x, after maintaining the current value of the fault flag FaultActv and the current value of the second time counter y, and clearing the value of the first time counter x, return to step S2; otherwise, proceed to step S4.
[0019] Specifically, in this step, the first time counter x is placed in the first if statement as a conditional judgment and compared with a constant named "Debounce_x". This limits the maximum time for fault confirmation. The judgment logic is as follows: Figure 2 As shown.
[0020] S4: Determine if the fault signal FaultFlag is equal to 1. If FaultFlag is equal to 1, increment the value of the second time counter y by 1, and then further determine if the value of the second time counter y is greater than or equal to the anti-shake fault count constant Debounce_y. If the second time counter y is greater than or equal to Debounce_y, set the fault flag FaultActv to 1 and report the fault. If the second time counter y is less than Debounce_y, set the fault flag FaultActv to 0 and return to step S2. If FaultFlag is not equal to 1, proceed to step S5. Specifically, in this step, in Figure 2 Following the shown if statement, a check is performed to determine whether the fault signal FaultFlag is set. This check also uses an if statement, dividing its execution strategy into two branches. The corresponding decision logic is as follows: Figure 3 As shown.
[0021] Branch 1 (i.e., the judgment condition is met, corresponding to step S4) has the following strategy: when the fault signal FaultFlag is set to 1, it means that a fault signal has been received, and then the fault setting count is entered, causing the corresponding second time counter y to increment. Its judgment logic is as follows: Figure 4 As shown.
[0022] It should be noted that, Figure 4 The Debounce_y constant shown is the key to controlling whether fault detection is "continuous detection" or "discrete detection". If its value is equal to the debounce time count constant Debounce_x set by the outer first time counter x, the fault detection logic is continuous detection, and the fault debounce time is x cycles; if its value is less than the debounce time count constant Debounce_x set by the outer first time counter x, the fault detection logic is discrete detection, and the fault debounce time is at least y cycles and at most x cycles.
[0023] When the cumulative count value of the second time counter y in the model reaches the value set by the constant debounce fault count constant Debounce_y, the fault flag bit FaultActv is set and the fault is reported.
[0024] S5: Increment the value of the count counter Counter by one, and determine whether the value of the count counter Counter is greater than or equal to the preset value. If the value of the count counter Counter Counter is greater than or equal to the preset value, then output that the fault flag bit FaultActv is set to 0 and the value of the second time counter y is set to 0, and then return to step S2; otherwise, after keeping the current value of the fault flag bit FaultActv and the current value of the second time counter y, return to step S2.
[0025] Specifically, in this step, what is achieved is... Figure 3 The strategy for the corresponding branch 2 (i.e., the judgment condition is not met, corresponding to step S4) is: when the fault signal FaultFlag is 0, it means that no fault signal has been received, and the fault flag bit FaultActv should be set to 0.
[0026] However, if the fault flag FaultActv is cleared to zero at this time, when the transmission of the fault signal FaultFlag is unstable, it will lead to a situation where "the fault was originally set, but the fault flag FaultActv jumps between 1 and 0 because the fault signal FaultFlag jumps to 0 at a certain moment".
[0027] Therefore, at this point, it is necessary to execute the fault recovery confirmation, which is the fault recovery debounce strategy. Its execution logic is as follows: Figure 5 As shown.
[0028] It should be noted that this section is about Figure 5 The logic for the counter variable Counter is implemented using the Chart module in Simulink, similar to a for loop in C. The design is as follows: when the fault signal FaultFlag is detected as 0 for three consecutive cycles (i.e., the preset value in the preferred exemplary embodiment is 3, which can be modified according to actual conditions), the fault clearing signal ClearFlag is output, resetting the fault flag FaultActv and the second time counter y to zero. The Chart logic is as follows. Figure 6 As shown.
[0029] like Figure 6 As shown, the counter Counter only increments by 1 when the fault signal FaultFlag = 0. Only when the counter Counter reaches 3 is the fault clearing signal ClearFlag set to 1, issuing a fault flag clearing command. During this process, whenever the fault signal FaultFlag becomes 1, the counter Counter is immediately cleared to zero, and counting resumes only after FaultFlag becomes 0 again. This prevents instability in the Fault Flag (FaultActv) signal output due to sudden changes in FaultFlag, and also ensures the rationality of the fault recovery logic. It should be noted that this method is for recoverable faults.
[0030] In summary, in this exemplary embodiment: (1) By setting the debounce time count constant Debounce_x and the debounce fault count constant Debounce_y respectively, the fault debounce logic is unified, so that the fault confirmation logic can be universal for both "continuous detection type" and "discrete detection type", thereby reducing the workload in the software development process and improving the reusability of the software when developing different fault judgment logics.
[0031] (2) By setting a fault clearing cycle, the abnormal clearing of the fault flag bit FaultActv due to fluctuations in the fault signal FaultFlag after the fault is set is prevented.
[0032] (3) By designing "discrete detection" logic, the software is prevented from failing to report the fault when the fault signal fluctuates between high and low levels because it cannot detect continuous fault signals. This improves the reliability of the fault detection logic.
[0033] The following will explain the experimental data: (1) Regarding the test results of the logic mentioned above, which is to prevent the fault flag bit FaultActv from being abnormally cleared due to fluctuations in the fault signal FaultFlag after the fault is triggered, the following are the results. Figure 7 As shown: As can be seen, when a fault is triggered, the fault flag FaultActv is set after the fault confirmation cycle. After the fault flag is set, the fault signal FaultFlag fluctuates, but the FaultFlag signal does not meet the requirement of being set to 0 for three consecutive cycles, thus the fault clearing confirmation is not completed. Therefore, the model logic does not clear the fault flag FaultActv. In this way, the stability of the FaultActv signal output is ensured, as well as the reliability of the recoverable fault protection logic.
[0034] (2) In addition, the counting logic of the stabilization time counting constant Debounce_x and the stabilization failure counting constant Debounce_y is verified, such as... Figure 8 , Figure 9 As shown.
[0035] First, it was verified that when the FaultActv flag is intermittently transmitted, the fault can be detected and reported in a timely manner. The test results are as follows: Figure 8 As can be seen, when the fault signal FaultFlag is transmitted unstablely and is received intermittently, as long as it is detected 6 times (here, the debounce fault count constant Debounce_y is set to a high level signal for the fault flag FaultActv), the fault flag FaultActv is set, and the fault is reported. In this way, the problem of faults not being reported due to discontinuous fault signals can be prevented.
[0036] Secondly, the clearing logic of the debouncing fault count constant Debounce_y was verified, confirming that it only clears to zero after the fault signal FaultFlag has been low for three consecutive cycles. The test results are as follows: Figure 9 As can be seen, when a fault is triggered, the low-level signal of the fault signal FaultFlag will only stop the second time counter y (Counter_y in the figure, and Counter_x is the first time counter x) of the fault flag counting. However, as long as the low-level signal of the fault signal FaultFlag has not counted for 3 consecutive cycles, the second time counter y will not be cleared.
[0037] (3) When the first time counter x and the second time counter y are equal, the fault can be triggered. That is, it is verified that the "continuous detection type" fault can be triggered. At the same time, the logical universality of the "continuous detection type" fault and the "discrete detection type" fault can also be verified. In this exemplary embodiment, the fault is set to be reported after 10 fault signals are detected continuously within 10 cycles.
[0038] As described in the technical solution description Figure 4 As shown, the key to distinguishing between "continuous detection type" and "discrete detection type" lies in whether the value of the image stabilization fault count constant Debounce_y is equal to the value of the outer counter x (the image stabilization time count constant Debounce_x). Therefore, the image stabilization fault count constant Debounce_y was modified to 10 for testing. The test results are as follows. Figure 10 As shown in the figure, the fault is injected at the beginning of the second counting cycle of the first time counter x (Counter_x in the figure). At this time, the second time counter y (Counter_y) starts counting synchronously. When the high level of the fault signal FaultFlag lasts for 10 cycles, the fault flag bit FaultActv is set to 1, and the fault reporting is completed.
[0039] Obviously, the above embodiments are merely illustrative examples for clear explanation and are not intended to limit the implementation. Those skilled in the art can make other variations or modifications based on the above description. It is neither necessary nor possible to exhaustively list all possible implementations. However, obvious variations or modifications derived therefrom are still within the scope of protection of this invention.
Claims
1. An optimization method based on anti-shake logic for fault diagnosis in automotive electronic control systems, characterized in that: Includes the following steps: S1: Set initial constants, including the stabilization time count constant Debounce_x and the stabilization fault count constant Debounce_y; when the stabilization time count constant Debounce_x and the stabilization fault count constant Debounce_y are equal, the fault diagnosis stabilization logic is continuous detection; when the stabilization time count constant Debounce_x is greater than the stabilization fault count constant Debounce_y, the fault diagnosis stabilization logic is discrete detection. S2: Increment the value of the first time counter x by 1; S3: Determine the value of the first time counter x and the size of the anti-shake time counting constant Debounce_x. If the value of the first time counter x is greater than the anti-shake time counting constant Debounce_x, after maintaining the current value of the fault flag bit FaultActv and the current value of the second time counter y, and clearing the value of the first time counter x, return to step S2; otherwise, proceed to step S4. S4: Determine if the fault signal FaultFlag is equal to 1. If FaultFlag is equal to 1, increment the value of the second time counter y by 1, and then further determine if the value of the second time counter y is greater than or equal to the anti-shake fault count constant Debounce_y. If the second time counter y is greater than or equal to Debounce_y, set the fault flag FaultActv to 1 and report the fault. If the second time counter y is less than Debounce_y, set the fault flag FaultActv to 0 and return to step S2. If FaultFlag is not equal to 1, proceed to step S5. S5: Increment the value of the count counter Counter by one, and determine whether the value of the count counter Counter is greater than or equal to the preset value. If the value of the count counter Counter Counter is greater than or equal to the preset value, then output that the fault flag bit FaultActv is set to 0 and the value of the second time counter y is set to 0, and then return to step S2; otherwise, after keeping the current value of the fault flag bit FaultActv and the current value of the second time counter y, return to step S2.
2. The optimization method based on the anti-shake logic for fault diagnosis of automotive electronic control systems according to claim 1, characterized in that: The preset value is 3.