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

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.

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.

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:

SF₃ = 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:

F_S1 = F_aF_b + (1-F_a)F_cF_d + F_a(1-F_b)F_cF_d + (1-F_b)(1-F_c)F_aF_eF_d + (1-F_d)(1-F_a)F_bF_eF_c (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