By some estimates, fault detection and the subsequent error handling averages between 30% and 50% of the algorithmic code for embedded systems.  However, despite the high percentage of code devoted to fault detection the literature devoted to this topic is less commonly read.

In a previous video post, Fault Detection, I looked at common patterns for fault detection algorithms and decomposition between fault detection and control algorithms.  In this post, I will cover the validation of fault detection algorithms.

Requirements: the validation starting point

To begin, the fault detection algorithm should have an independent requirement specifying what conditions constitutes a fault.

The example above is the requirements for an engine temperature fault monitoring system.  It defines what is monitored and the severity of the faults.  Importantly it does not define how fault detection system will be implemented.

Fault system implementation

Once the requirements are written and validated for correctness, the fault system can be implemented.

In this case, I implemented the fault detection algorithm as a Stateflow chart.  Noise in the signal was handled by using a debounce variable “delta” to bouncing between the InitETM and MoveToFault modes.

Fault system validation

The next step is to write the test cases that will validate the requirements document.  From the technical description, 6 test conditions (or cases) that can be defined

1. Engine operating in safe temperature range:  Maps toe TD.1
2. Engine operating above critical temperature range: Maps to TD.2
3. Engine stays in ENGCRITTEMP state after entering ENGCRTTEMP state: Maps to TD.2.a
4. Engine operating in unsafe temperature range for less than 5 seconds: Maps to TD.3.a
5. Engine operating in unsafe temperature range for more than 5 seconds: Maps to TD.3.a
6. After entering ENGOVERHEAT state engine temperature is less than maxEngTemp for more than 10 seconds: Maps to TD.3.b

In the act of writing the test cases, it is discovered that the requirements were underspecified.  The requirement reads “noise in the signal shall be accounted for” but it does not specify the level of noise.  At this point, the requirement should be updated to include information on the level of noise in the signal.

Final thoughts

Fundamentally, the process of validating fault detection systems is the same as validating any other software construct.  In addition to the manual methods of defining tests software tools such as Simulink Design Verifier can be used verify coverage of the model.