Quantifying ISO 26262 Dependent Failures Analysis

In this blog we revisit the subject of dependent failures as defined in ISO 26262 (Read also the blog post Part 11: Blog Post 3: Dependent Failure Analysis 2017) and more to the point how they can be quantified. Depending on the item under development the number of potential dependent failures initiators (DFI) can be large and at present there is no clear way defined on how to quantify these failures.

Figure 1: Coupling factor classes for dependent failures

The 7 types of coupling factors are applicable to system, hardware, and software levels as defined in ISO 26262:

Coupling factorExample system levelExample hardware levelExample software level
Shared Information InputExternal messages e.g. CANSensor outputVariable global to 2 functions
CommunicationBetween to ECUs in the same systemElectrical connection between 2 elementsData flow via global variables
Identical TypeSame type of sensorSame microcontrollerSame C macro
Unintended InterfaceOne function overruling another due to lack of synchronizationCrosstalk between signal pathsSame memory space
Shared ResourcePower supplyclockI/O routines
Systematic couplingIdentical production processesIdentical production processesSame compiler
Environmental immunityMechanical couplingEMCN/A

Figure 2: Examples of System, Hardware and Software DFI

With the large number of potential DFI how far should teams go in mitigating the potential failures? Ultimately many items will require to be addressed early so that the dependent failures are mitigated by inherent good design, rather than introducing a ‘sticking plaster’ approach later in the design life-cycle.

IEC 61508 Quantification

IEC 61508 the standard from which ISO 26262 was derived, does use a technique to quantify dependent failures or rather common cause failures, by posing a set of 37 questions around the diversity of each aspect of the development. As an organisation we use a similar technique in ISO 26262 projects but scoring each of the 7 coupling factors based on the impact it might have on safety goals. This takes the form of an FMEA and requires the corresponding rigour in the safety mechanism to ensure that the DFI has been adequately mitigated.

DFI Mitigation

As mentioned above we want to prevent DFI occurring where possible to reduce rework time and expense. Clear guidelines within an organisation can help ensure the major issues are avoided e.g. the same microcontroller in redundant paths. For less obvious scenarios a rating system can be extremely helpful. The acceptance criteria can be defined and a process then put in place rather to avoid than mitigate scenarios. Typical scoring might be as indicated in Figure 3:

DFI GroupDFI TypeDetailScore
Shared ResourceClockSame clock source for both channels no checks10
Test only for stuck at faults7
Test for stuck at, jitter, DC, drift4
Full independent clock monitoring1
Power SupplyIdentical Power Supply10
Same technology but different PSU implementation7
Different power supply technology4
Different power supply technology, with independent monitoring, level, transient and oscillation1

Figure 3: DFI Rating System

The acceptance criteria may be only to accept DFI below a given value or perhaps a level for the total DFI ranking for the item or element.

How companies approach this topic varies dramatically, but certainly recommended is some form of acceptance criteria for dependent failures to guide teams through this challenging activity in ISO 26262.

By Alastair Walker, Consultant

Do you want to learn more about the implementation of ISO 26262, IATF 16949 or any other standard in the Automotive or Medical Device sector? We work remotely with you. Please contact us at info@lorit-consultancy.com for bespoke consultancy or join one of our upcoming online courses.



We look forward to hearing from you.

    Show privacy policy