Design Article
Software testing for safety-critical automotive systems
By Victor Reyes, Synopsys
12/17/2012 7:30 PM EST
Comparing fault-injection techniques
Table 1 compares four traditional fault-injection techniques by considering some of the most important factors. These include:
Typically, the test team will use ‘hardware-based with contact’ fault injection to inject errors on the IO boundary of the Electronic Control Unit, and ‘hardware-based without contact’ to trigger soft errors – for example, to simulate memory corruption due to radiation or electromagnetic interference.
The ‘with contact’ techniques can model permanent faults, and they are not intrusive (although there is a risk of damage if misused). The ‘without contact’ techniques are more focused on transient errors and are also non-intrusive. However, there is little control on when and where the fault will be injected.
Software-based, fault-injection techniques can only inject errors on those locations accessible by the software, that is, memory and registers for memory-mapped peripherals, which means they are only able to model transient faults. The biggest problem with software-based, fault-injection techniques is that they are intrusive: because the engineer has to modify the software binary code to inject the errors, there is a risk that the test unit may behave differently from the production software running in the field.
The techniques described above use real hardware, which limits the observability. They are controllable and repeatable, but because they use real hardware, the tests are never completely deterministic. All three techniques run fast enough (real time) to handle complex software stacks.
Simulation-based, fault injection (performed at the gate or RTL level) has the advantage of having full access to all hardware elements on the system. Without being intrusive, it has full observability, controllability and determinism. However, the simulations are extremely slow, which makes them unusable on more complex fault scenarios where the design team must take the software into account.
Next: Virtual prototyping
Table 1 compares four traditional fault-injection techniques by considering some of the most important factors. These include:
- The type of faults that can be triggered (fault injection points),
- The ability to model permanent faults,
- Intrusiveness, or how the injection of the fault changes the original execution flow of the system,
- Observability, which defines how well the set of reactions (or events) triggered by the fault can be seen and recorded,
- Controllability, which defines the precision in terms of exact time and location where the fault can be injected,
- Repeatability, or the ability to repeat the test in a deterministic fashion, and
- Speed, which will define to some extent the complexity and duration of the test scenarios.
Table 1: Comparing traditional
fault-injection techniques
Typically, the test team will use ‘hardware-based with contact’ fault injection to inject errors on the IO boundary of the Electronic Control Unit, and ‘hardware-based without contact’ to trigger soft errors – for example, to simulate memory corruption due to radiation or electromagnetic interference.
The ‘with contact’ techniques can model permanent faults, and they are not intrusive (although there is a risk of damage if misused). The ‘without contact’ techniques are more focused on transient errors and are also non-intrusive. However, there is little control on when and where the fault will be injected.
Software-based, fault-injection techniques can only inject errors on those locations accessible by the software, that is, memory and registers for memory-mapped peripherals, which means they are only able to model transient faults. The biggest problem with software-based, fault-injection techniques is that they are intrusive: because the engineer has to modify the software binary code to inject the errors, there is a risk that the test unit may behave differently from the production software running in the field.
The techniques described above use real hardware, which limits the observability. They are controllable and repeatable, but because they use real hardware, the tests are never completely deterministic. All three techniques run fast enough (real time) to handle complex software stacks.
Simulation-based, fault injection (performed at the gate or RTL level) has the advantage of having full access to all hardware elements on the system. Without being intrusive, it has full observability, controllability and determinism. However, the simulations are extremely slow, which makes them unusable on more complex fault scenarios where the design team must take the software into account.
Next: Virtual prototyping
|
|
|
|
|
Navigate to related information