Testing software for safety-critical automotive systems - Embedded.com

Testing software for safety-critical automotive systems


The automotive industry faces a significant challenge: 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.

But 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 like 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 behavior. 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 analyze its response to faults, and where arbitrary faults corrupting software or hardware components must be injected to test safety mechanisms.

Fault categories
We can categorize faults as either software or hardware faults. Within the hardware category, faults are one or more of the following:

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

To read more, go to: “Comparing fault-injection techniques.”

Leave a Reply

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