Three Steps To ISO 26262 Fault Campaign Closure

The complexity of automotive ICs continues to grow exponentially, challenging even the most veteran teams to deliver innovative products to market while simultaneously ensuring safety through the operational life of the product.

This is the purpose of safety verification. Its primary objective is to understand whether the safety architecture sufficiently prevents random failures from violating ISO 26262 safety requirements for both commercial and passenger automobiles. To complete safety verification, faults are injected, propagated, and classified. Fault classifications are then used to generate the required safety metrics.

In this article we will give a brief background on fault injection techniques and summarize a methodology used to more efficiently close on fault injection campaigns.

Keeping pace with a growing fault state space

Figure 1 illustrates the scope of a fault injection campaign. A two-input AND gate contains three fault injection sites. When extrapolating the number of fault sites per gate over a million-gate design and then across the desired faults models, the resulting fault state space can be extremely large.

Fig. 1: Fault injection state space.

The fault campaign effort required is also impacted by the target Automotive Safety Integrity Level (ASIL), which is a safety classification scheme (with four levels ranked according to integrity requirements) for a system being developed. An ASIL-D system requires a higher degree of fault coverage compared to an ASIL-B system. This increase in coverage requires additional effort. ISO 26262 further describes fault injection as a recommended activity for ASIL-B and a highly recommended activity for ASIL-D systems.

The higher degree of automotive semiconductor complexity has led to the introduction of dedicated fault injection engines and tools. These dedicated software tools aid verification engineers by introducing concurrency and intelligence into the injection of a fault. Figure 2 demonstrates how an injection engine pulls faults from a single fault list and parallelizes the effort by executing injection across multiple engines, with the most advanced fault injection engines taking advantage of multi-threading, multicore, and larger machine grids.

Fig. 2: Fault injection simulator flow.

This trend has continued with IC complexity continuing to grow to support vehicle electrification, driver assist, and autonomous vehicle automotive systems. Automotive semiconductors have grown to full systems on chip (SoC) consisting of hardware and software, digital and analog components, functional islands with varying safety requirements, and more. Selecting the right blend of fault injection tools is important in obtaining maximum efficiency through the fault campaign.

Formal engines, simulators, hardware emulation, and prototype fault injection technologies are four technologies commonly leveraged during a fault campaign. Each fault injection solution provides unique capabilities with each having its pros and cons in solving certain challenges. Depending on the product being developed, project teams will need to deploy one or more of these solutions.

Formal analysis leverages the power of formal engines to perform fault analysis and classification. Formal engines use static analysis and mathematical transformations to evaluate fault injection and propagation. Formal analysis is exhaustive across the entire state space and exercises all stimulus scenarios, making this analysis ideal for smaller blocks or in instances where fault classification proofs are required. Another benefit of formal is that no testbench is required. This allows for early cycle classification while also providing gap closure capabilities in the event workload-dependent fault injection platforms (simulation or emulation) don’t close on a fault campaign. There are a few drawbacks to using formal in a fault campaign. Formal analysis engines experience capacity limitations and, therefore, are not ideal for top-level analysis of large SoCs. Secondly, highly configurable IPs add a layer of complexity due to the need for additional formal constraints. Finally, deploying this capability may require formal expertise.

Fault simulation is the traditional workhorse in a fault injection campaign. It provides expanded capacity and performance above formal analysis. Depending on design type and size, simulation is a viable option at the block, subsystem, and system levels. However, it does require a testbench and success depends on the robustness of the testbench stimulus. Fault injection simulation is also typically deployed on both digital and analog/mixed-signal components.

Fault emulation expands the capacity even further by offering hardware accelerated fault injection. Large designs and SoCs that implement top-level safety mechanisms, such as a data path CRC, benefit from hardware acceleration. Applications that leverage software test libraries as part of their safety architecture and/or require dynamic interaction with software safety mechanisms will benefit from emulation. Lastly, emulation is an ideal platform for validating software assisted hardware safety mechanisms.

The three steps in a fault injection workflow

Orchestrating the fault campaign so that each solution complements the others is important in achieving maximum efficiency and shortening the fault campaign duration. It is recommended that a fault campaign plan be created, describing what injection testing will be performed, which tools will be deployed, how many faults will be tested, and more. Once tooling decisions are made, the next step is establishing the execution methodology of the fault campaign.

Siemens EDA promotes a three-step flow that reduces the overall scope and execution time of the campaign.

• Step 1 – Fault List Generation
• Step 2 – Fault Injection
• Step 3 – Work Product Generation

Fault list generation ultimately defines the scope of the fault campaign. Just as how functional coverage details the desired scenarios that must be hit, a fault list defines the faults that must be injected and classified.

Once the fault list is generated, fault injection is performed across the various engines. While faults can typically be injected on many tools, one tool may be significantly more efficient at classifying certain fault nodes. Therefore, to achieve maximum efficiency, the fault list should be subdivided into buckets, with each bucket targeting a specific fault injection engine. After every fault in the list is injected and classified, fault injection ceases.

The final step in the flow is safety metric calculation and work product generation. It is common practice to deliver a failure modes effects and diagnostic analysis (FMEDA) as part of the overall safety case. ISO 26262 also suggests delivering an FMEDA and provides examples throughout the standard. The FMEDA contains the failure modes and overall safety metrics that were calculated using the fault classifications identified during fault injection.

Figure 3 provides an overview of the fault campaign workflow. As in tool selection, the methodology is customized based on the design profile and safety features present in the design.

Fig. 3: Fault campaign methodology.

Conclusion

Teams must decide on the correct mix of fault injection tools based on the application and safety architecture. Those who do it correctly are the ones who will expedite fault campaign closure and succeed in delivering tomorrow’s automotive electronic systems designs today.

For a full treatment on this methodology and the tools that expedite fault campaign closure, please read the full paper Orchestrating an Efficient ISO26262 Fault Campaign.