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 factor | Example system level | Example hardware level | Example software level |
|---|---|---|---|
| Shared Information Input | External messages e.g. CAN | Sensor output | Variable global to 2 functions |
| Communication | Between to ECUs in the same system | Electrical connection between 2 elements | Data flow via global variables |
| Identical Type | Same type of sensor | Same microcontroller | Same C macro |
| Unintended Interface | One function overruling another due to lack of synchronization | Crosstalk between signal paths | Same memory space |
| Shared Resource | Power supply | clock | I/O routines |
| Systematic coupling | Identical production processes | Identical production processes | Same compiler |
| Environmental immunity | Mechanical coupling | EMC | N/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 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.
