Not Seeing the Wood for the Trees – Refining Dependent Failures Analysis

Over the years, we’ve published a few blogs on dependent failures and the techniques used to quantify the dependent failures analysis, such as „Quantifying ISO 26262 Dependent Failures Analysis“ from 2020, the area not as thoroughly supported by ISO 26262, though other functional safety standards, like ISO 13849-1 and IEC 61508, offer more prescriptive guidance on the topic.

At its core, dependent failures analysis is basically analysis of common elements that could fail and cause two or more components to fail for the same reason, ultimately leading to a violation of a safety requirement(s). Over the years we have seen many examples e.g. systematic failures in microcontrollers from the same family, which could have resulted in catastrophic results if not caught in the development phase.

Dependent failure initiators

There are many sources that list the potential initiation of dependent failures. ISO 26262 handles the topic well but focusses more on the technical aspects. Other standards such as ISO 13849-1 and IEC 61508, additionally bring in more human factors including competence, training, and experience.

For technical considerations when analysing dependent failures, the key elements are:

  • similar and dissimilar redundant elements
  • different functions implemented with identical software or hardware elements
  • functions and their respective safety mechanisms
  • partitions of functions or software elements
  • physical distance between hardware elements, with or without a barrier
  • common external resources

Examples are wide and varied, including common software tools or libraries, power supplies, or clock signals, to name just a few.

Failures can also be subdivided into two basic groups: common cause failures and cascading failures.
Cascading failures involve interference between elements or components, while common cause failures focus on similar or identical elements or components.

Alastair Walker, Owner & Consultant

Do you want to learn more about the implementation of ISO 26262, IATF 16949, IEC 60664 or other standard in the Automotive sector? We provide remote support and training to enhance your functional safety related projects. Please contact us at info@lorit-consultancy.com for bespoke consultancy or join one of our upcoming online courses.

Erfahre mehr

Where can dependent failures occur in the lifecycle?

As with most failures, a systematic element plays a significant role. During development, a lack of analysis may result in the selection of common component types that are not caught through dependent failure analysis. This analysis should also consider the intended use and use environment of the product. However, manufacturing and service stages can also be areas where dependent failures arise. Examples include manufacturing faults such as calibration issues or incorrect programming of devices etc.

Identifying dependent failures

As described in several papers we have published before, the approach in ISO 26262 part 11 in relation to semiconductor dependent failures represents a very helpful process flow, as indicated in Figure 1.

Dependent Failure Analysis DFA ISO 26262 for Semiconductors
Figure 1. Dependent Failures Analysis ISO 26262 Semiconductors

 

For many customers, the process of identifying dependent failures can often be implemented using a grid with functions listed along the top and safety mechanisms down the side. The activity then involves identifying common functionalities that could cause both the function and safety mechanism to fail. This strategy is also applied to different functional blocks.

Obviously, this approach only addresses certain considerations of dependent failures. As shown in Fig. 1, fault tree analysis is often used to support this activity. The advantage of a fault tree is that it can capture virtually all aspects of the analysis.

Typical Fault Tree Analysis from ISO 26262 Part 11
Figure 2. Typical Fault Tree Analysis from ISO 26262 Part 11

 

Fault trees are a very powerful tool and support common cause analysis very well, e.g. Beta factor analysis for common cause models. However, there is a concern that common cause failures may be repeatedly used in a fault tree if not supported by a suitable tool. This is where disjointing comes into play.

Disjointing

Most fault tree tools will support disjointing, otherwise you end up with a relatively complex algebraic process. The fault tree standard IEC 61025 gives good guidance on the subject, on the assumption that the tool you use does not support this.

Using the system failure (cut sets) approach if our system failure was based on

SF = a.b + c.d +a.e.d + b.e.c (Equation 1)

where “AND” relations are defined by dots (.) and “OR” relations by plus (+).

Disjointing is applied by making each term disjoint from the first term. This is then approached by inspecting the first term a.b and pick out variables that do not appear in the second term c.d. In set theory this is called the relative complement.

For our equation 1 then we replace the second term (c.d) with /a.c.d + a./b.c.d
We repeat this process with each term in equation 1 and this will yield equation 2, after disjointing each term from the others in the equation:

SF3 = a.b + /a.c.d + a./b.c.d + /b./c.a.e.d + /a./a.b.e.c (Equation 2)

The conversation to a system failure function then yields:

FS1 = FaFb + (1-Fa)FcFd + Fa(1-Fb)FcFd + (1-Fb)(1-Fc)FaFeFd + (1-Fd)(1-Fa)FbFeFc (Equation 3)

This illustrates the complex activity that requires the support of a tool to avoid this rather large algebraic activity.

Summary

Dependent failures analysis is a critical activity in ensuring system safety. How it is addressed across international standards varies significantly, but it remains an essential part of any safety case, as many contributing factors can otherwise be overlooked. ISO 13849-1 arguably takes the most pragmatic approach, while ISO 26262 provides more comprehensive coverage of the technical aspects compared to most other standards. For more complex systems, the use of fault trees is highly recommended – but ensure the chosen tool supports common cause failure models.

By Alastair Walker, Owner / Consultant

If you are looking for functional safety support either through consultancy or training courses, please feel free to contact us via contact form or at info@lorit-consultancy.com.

KONTAKT

Formular

Wir freuen uns auf Ihre Kontaktaufnahme.

    Datenschutz­bestimmungen anzeigen