Orchestrating an ISO26262 Fault Campaign
ISO26262 remains the state-of-the-art standard governing the activities required to prove electronics and electronic systems are safe for deployment in an automotive application. It details safety activities from concept, through development, and to production/decommission.
IC companies, experienced and newcomers alike, are challenged by one safety activity in particular: fault injection. Fault injection, also commonly known as the fault injection campaign, is required for the higher ASIL targets. It’s primary objective is to prove that the IC or IP will safely operate under a faulted state caused by a random hardware failure.
The scope of a fault campaign is often massive (millions of fault nodes), and as a result, can be extremely costly in schedule in engineering resources.
Therefore, it is critical that project teams deploy the correct solutions and methodology to accelerate closure of the fault campaign.
The remainder of this blog post highlights some of the key considerations when planning a fault campaign. A detailed description of each of these components can be found in the white paper titled “Orchestrating an efficient ISO26262 Fault Campaign“
Fault Campaign Flow
I’m often asked what tools are needed in a fault campaign and how they should be used. Unfortunately, the answer isn’t a one size fits all tool package. Fortunately, the process to answering those questions is systematic.
Define the tools
There are two considerations which help drive tooling decisions: Design Profile and Safety Architecture. The presence of hardware, software, digital/AMS circuitry, and other design elements will dictate the blend of tools required to complete the fault campaign. As an example, a fault campaign executed on a digital IP will require a different set of tools compared to fault campaign executed on a mixed-signal SoC containing embedded software.
Define the Methodology
Once you have the tooling defined, the next phase is defining the methodology. Specifically, project teams must define the fault campaign targets and how the fault campaign will be subdivided across the different tool capabilities. The primary contributors to this analysis is the design profile and the safety architecture. As an example, a fault injected into a digital circuit covered by a digital HW safety feature will be executed on a separate platform than an analog fault covered by an analog HW safety feature. Boundary conditions where faults propagate across multiple domains adds another level of complexity to this analysis. Once complete, fault campaign execution begins.
Execute the fault campaign
Siemens EDA breaks the execution phase down into a three step flow:
- Fault List Creation – Establishes scope of fault campaign
- Fault Injection – Multi-domain fault injection and classification
- Work Product Generation – Delivering safety metrics based on fault injection
During fault list creation, leverage automation to reduce scope of the fault campaign and produce the optimal fault list. Scope reduction comprises of a set of static and structural analysis to pre-classify fault nodes.
During fault injection, the fault list supplies the faults to be injected and classified. To achieve maximum efficiency, direct faults to the appropriate injection engine. The example below details two fault classifications aligned to the ISO26262 terminology; single point and residual.
In the final step, safety metrics are calculated and work products generated which are delivered to the integrator of the IC/IP for inclusion into system level analysis.
Conclusion
Many challenges exist in setting up, executing, and closing an ISO26262 fault campaign, more than can be described in a single blog post. If you’d like to learn more, please view the white paper or webinar, and if you are interested in learning how Siemens EDA helps automate the setup and execution of complex fault campaigns, please reach out.
