ISO 26262 Safety Analysis: We all need something to lean on

Introduction

In my last post (Colliding Worlds of Safety Analysis), I highlighted the challenges facing safety teams and the opportunity for engineers to lean on EDA to play a bigger role in ISO 26262 safety analysis.  In this post, I’d like to to dive a bit deeper into how automation can aid project teams.

A safety workflow demands significant engineering resources and can be generically divided into three primary activities.

• Safety Analysis: Initial failure analysis and safety architecture definition
• Safety Insertion: Enhancing the design to protect against failures
• Safety Verification: Testing the design to validate the enhancements sufficiently detect failures

Figure 1 – Generic Safety Lifecycle

For those experienced with safety, these three phases probably sound familiar. 

Impact of inaccurate ISO 26262 Safety Analysis

But now for the difficult question: Have you reached the end of safety verification and had to notify management that the implemented safety architecture doesn’t achieve the desired safety goals? I have heard this scenario play out and it underscores the importance of accurate early cycle safety analysis. The impact of incorrect safety analysis commonly results in additional project schedule, cost, and resources. Figure 2 demonstrates the impact of inaccurate safety analysis.

Figure 2 – Impact of Incorrect Safety Analysis

More complex architectures supporting ADAS and AV functions are exacerbating the challenge to correctly identify the optimal safety architecture. Similar to functional verification challenges in the past, industry is answering the call for help by creating design analysis technologies to provide the facilities for safety architects to identify the optimal safety architecture earlier in the lifecycle. One area where automation has always excelled is understanding the makeup of a designs core elements (gates, flops, connectivity, etc…).  This knowledge, combined with static and structural analysis algorithms, provide a view of which design structures are safety critical, which are protected, and more.  In short, leveraging these capabilities early in the development cycle provides project teams the confidence that the planned safety architecture will achieve the ASIL target.

Below are a few of the analysis activities available to safety architects:

• Failure rate (FIT) calculation and contribution per design structure
• Safety assessment to identify existing failure coverage (Gap Analysis)
• Safety exploration to ascertain optimal safety architecture and impact to power, performance and area (PPA)

Conclusion

Ultimately, managers desire as short a project cycle as possible. But equally important is a predictable schedule. Static and structural analysis capabilities provide the reassurance to safety architects and leadership that the proposed safety architecture will achieve the desired safety target, and therefore bounds a traditionally unbounded workflow. As an added bonus, static and structural analysis also prevents the over designing of safety, thus optimizing for power, performance, and area (PPA). Simply put, early cycle analysis aided by automation forms the foundation of your single iteration safety lifecycle.