Over the past few weeks I have been thinking about how to test systems while introducing faults at lower levels within the system. At the topmost level the problem is simple; faults can be treated as just a signal. At a lower level either the model would need to be instrumented or the computational chain would need to be understood.
Where are the faults?
Within controls design a fault is defined as either an interruption in, or else a delay or “crossed” signal in the data flow. Our first question is to ask “where and how do faults occur?” Faults occur at the boundaries of systems, either though direct I/O or communication protocols (CAN/LIN/Ethernet…) or through errors in global memory (pointer corruption).
Injection Blocks
In this example we wrap our UUT (unit-under-test) as a referenced model. In the test environment we point to a secondary referenced model that includes a fault-injection block. Taking this approach we can instrument the UUT without challenging the UUT.
The actual “injection” block can be comprised of almost anything. In this case I used simple test sequence block to short the signal after 5 seconds
When to fault test?
Fault based testing is an edge case for testing; not all systems require or merit fault testing. A general rule of thumb is…
- If the system is safety critical
and - The system directly communicates with external systems
and - The system does not have redundant communication
then…
…the system should have fault testing implemented.