Fault injection

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

Simple Fault

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.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.