Authors:
- Ping Yeung - Mentor, A Siemens Business
- Doug Smith - Mentor, A Siemens Business
- Abdelouahab Ayari - Mentor, A Siemens Business
Introduction:
The automotive safety standard, ISO 26262 [1], states that safety analyses on hardware designs should include Failure Mode and Effects Analysis (FMEA). Hardware architectural metrics are required to assess the adequacy of the safety mechanisms and their ability to prevent faults from reaching safety critical areas. A process of fault analysis that includes fault injection is crucial for measuring and verifying the assumptions of the FMEA.
In Part 5 of the ISO 26262 [2] specification, a hardware architecture needs to be evaluated against the requirements for fault handling. It requires that the probabilities of random hardware failures are rigorously analyzed and quantified via a set of objective metrics [3]. If any of the architectural metrics fail to meet the criteria defined for the product’s Automotive Safety Integrity Level (ASIL), re-evaluation of the component safety concept, improvement of existing safety mechanisms, and/or introduction of new safety mechanisms are mandated. Fault analysis is a process that aims to determine the percentage of faults that turn into failures that impact the hardware’s safety requirements. It uses fault injection with design representations at different levels to compute and to verify the values of failure mode and diagnostic coverage. Hence, fault injection is an essential method to determine the completeness and correctness of the safety mechanisms in meeting hardware safety requirements.
Traditionally, fault injection involves running a functional simulation on the gate-level representation, flipping a bit at some point in time, then analyzing the results to see if any of the signals defined as safety critical (such as output ports, state-machines) had changed in any way. Determining the percentage of faults that will turn into failures requires injecting tens of thousands of faults into hundreds of tests, simulating them to their outputs, and comparing the results. However, a gate-level design representation is only available late in the design cycle. At that stage, any conceptual re-evaluation and/or architectural change will have a significant impact on the project schedule and is costly to perform. As a result, fault injections at the register transfer level [3] or even at the transaction level [4] are important alternatives to perform fault analysis and to assess the efficiency of the safety mechanisms early in the design cycle.
Even at a higher level of abstraction, random fault injection is still time-consuming and inefficient in meeting today’s project schedules. Hardware emulation or design prototyping is useful for addressing the performance bottleneck in simulation-based fault analysis. Yet these approaches are inefficient as the injected faults may not cause any failure of the safety goals (safe faults) or the failures may be prevented by the safety mechanisms. To be efficient, we want to focus on faults that are not guarded by any safety mechanism and will subsequently cause failures of the safety goals (single-point faults, residual faults).
These factors motivate us to adopt formal verification for fault analysis. In this paper, we present a static analysis step to derive, optimize, and prioritize the fault list so that it can be analyzed as efficiently as possible. Also, a formal methodology is used for fault injection to maximize the observability of the faulty results.
 View & Download:
Read the entire Formal Techniques for Optimizing ISO 26262 Fault Analysis technical paper.
|
|
 |
|---|