Global Sources
EE Times-India
Stay in touch with EE Times India
EE Times-India > Embedded

Software testing for safety-critical car systems

Posted: 04 Jan 2013     Print Version  Bookmark and Share

Keywords:ISO 26262  Fault injection  RTL 

One of the most significant challenges in the automotive industry is to release cars with zero software defects. The number of recalls and redesigns due to software problems illustrates the magnitude of the challenge—they have grown exponentially over the last decade. There are major economic implications for manufacturers since the cost of recalling a vehicle can be huge, especially when the issue affects the integrity of the brand.

Manufacturers already spend a lot of money on software testing. In fact, testing accounts for about 75% of the cost of software development. And that spend is set to grow as the number of tests that manufacturers have to run continues to increase.

However, simply increasing the number of tests is not always the best way to reduce defects. Improving tests, so that they exercise corner cases that are not triggered by normal operation, improves quality.

Standards such as ISO 26262 address the planning and development of safety-critical systems and place further demands on software testing. ISO 26262 provides an automotive-specific, risk-based approach based on Automotive Safety Integrity Levels (ASIL). It specifies the requirements and recommended methods for validation of the safety levels including fault-injection testing.

Fault-injection testing
Fault injection helps to determine whether the response of a system matches its specification in the presence of faults. It helps system engineers to understand the effects of faults on the target system behaviour. It also helps to assess the efficiency of fault-tolerance mechanisms, and enables the design team to reduce the presence of faults during the design and implementation phases.

Fault injection can improve test coverage of safety mechanisms (at the system level) by covering corner cases that are difficult to trigger during normal operation. It is also recommended whenever a hardware safety mechanism is defined, to analyse its response to faults, and where arbitrary faults corrupting software or hardware components must be injected to test safety mechanisms.

Fault categories
We can categorise faults as either software or hardware faults. Within the hardware category, faults are either:

 • Permanent (triggered by component damage),
 • Transient (triggered by environmental conditions, also known as soft errors), or
 • Intermittent (caused by unstable hardware).

Table: Comparing traditional fault-injection techniques.

Comparing fault-injection techniques
The table 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.

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.

Virtual prototyping
A virtual prototype is a software model that emulates the hardware. Design teams can use a virtual prototype to model the digital aspects of a microcontroller unit, an electronic control unit or even a complete ECU network, and run the simulation on a desktop PC. Virtual prototypes run the same binary software as the real hardware. Because the virtual prototype is a soft model, software teams can get access to it months before the actual hardware device is available.

1 • 2 Next Page Last Page

Comment on "Software testing for safety-critical..."
*  You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top