In this blog we revisit the subject of dependent failures as defined in ISO 26262 (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 dependant 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 Group DFI Type Detail Score
Shared Resource Clock Same clock source for both channels no checks 10
Test only for stuck at faults 7
Test for stuck at, jitter, DC, drift 4
Full independent clock monitoring 1
Power Supply Identical Power Supply 10
Same technology but different PSU implementation 7
Different power supply technology 4
Different power supply technology, with independent monitoring, level, transient and oscillation 1

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.