Overview of Dependent Failure Analysis-Freedom From Interference and Safety Analysis

Dependent Failure Analysis( DFA), Safety-Oriented Analysis(SOA) and the Freedom From Interference(FFI) are the three main analysis activities that need to be performed at the software architecture level if applicable. In ISO 26262-6 appendix E and ISO 26262-11, the relationship between them has been addressed. Based on my understanding of the standard, I want to share my understanding of those three analysis activities in the following chapters. 

1- Safety Analysis  

1.1 Purpose of safety analysis

The main purpose of the safety-oriented analysis at the software phase is to identify the potential weaknesses of the software functions (single-point faults or dual/multiple-point faults) or properties with defined ASIL ratings and to support the definition of the additional safety mechanisms to improve the weakness if necessary. The analysis object is all the software elements in the software architecture.

1.2 Analysis Steps

Same like other safety activities in ISO 26262, the safety-oriented analysis at software phase is separated into 3 main sub-activities:

Identify

Identify possible design weaknesses, conditions, faults or failures that could induce causal chains leading to the violation of safety requirements

Analyze

Analyze the consequences or behaviors of possible faults, failures or causal chains on the functions and properties required for the software architectural elements.

Design

Design additional safety measures or safety mechanisms if necessary after the analysis.

1.3 Analysis Methods

The safety analyses according to the software architectural design can follow functional and/or processing chains considering both static and dynamic aspects. By using this approach, the analysis could systematically step through the software and provide evidence of mitigation measures to protect against single-point or dual-point latent faults created by the failure modes of software elements. 

This activity could be performed following some systematic methods. As demonstrated in E3.4.3 of Annex D in ISO 26262-6, you could use some guiding words to help you identifying and analyzing the weaknesses or faults. 

This analysis could be also carried out by using the inductive method (FMEA: Failure Mode and Effect Analysis) or deductive method (FTA: Fault Tree Analysis). One example of inductive methods for the safety analysis at software is the FMEA, which is well known as SW-FMEA. The FMEA should be performed at a low enough level that it does not become a repetitive version of the system FMEA; however it shall be also carried out at a high enough level to preserve its usefulness to identify potential systematic faults at the architectural level. That could one of the reasons why ISO 26262 thinks safety analysis at the code level is unnecessary.

2-  DFA

The main purpose of the analysis of dependent failures(DFA) is to ensure that the effectiveness of the safety mechanisms is not affected by dependent failures initiators(single root cause that leads multiple elements to fail through coupling factors). 

DFA is not always required during software development. It is only required to be carried out when any of following approaches are performed: 

·ASIL decomposition at the software level

·Software safety mechanisms require independence between the monitored element and the monitor;

·Coexistence of the software elements with different ASIL ratings.

Same as other safety analysis activities, the DFA activity could be carried out into 3 main steps as defined below.

·Identify

Identify the dependent failure initiators;

·Analyze

Analyze the consequences of dependent failure initiators;

·Design

Design additional safety measures or safety mechanisms to improve the effectiveness of the safety mechanism if necessary after the analysis.

By carrying out the DFA, the dependent failure initiators will be identified and analyzed to check if they could weaken the effectiveness of the safety mechanism or not. Based on the analysis results, additional safety measures maybe required if necessary.

3-  FFI: Freedom From Interference

The main purpose of Freedom From Interference(FFI) is to ensure that the faults in the software elements with lower ASIL ratings or QM will not lead to hazardous behavior of the software elements with higher ASIL ratings.

The analysis objects of FFI are ：

·Timing and execution of low or QM software components and higher ASIL software components;

·The store memory of low or QM software components and higher ASIL software components

·Interactions or communication between low or QM software components and higher ASIL software components 

The interference between software elements with different ASIL ratings is one kind of dependent failure, cascading failure. Thus FFI shares the same reasons with DFA addressed above why and when the activities are required to be carried out.

In case of any interference between low or QM ASIL software components and higher ASIL software components which could lead to hazardous behavior of higher ASIL software elements, additional safety measures shall be carried out. A practical way is to avoid that kind of interference physically, for example by physical isolating. If avoid is not a good way, for example the communication between them, the measures to detect, to mitigate or to control that interference could be a choice. There are some commonly used safety measures against the interferences, however addressing all of them is out of the topic of the article. I could write another separate blog on this topic if I am available.

4-  Relationships between Safety Analysis andDFA/FFI 

Both Safety-Oriented Analysis and DFA/FFI are to ensure that the ability of the software to provide the specified functions, behavior and properties with required safety integrity is examined or confirmed. The analysis results of them are the basis of the effective safety mechanisms or safety measures during development.

The safety analysis could be first carried out. The analysis results of safety analysis could be used to identify the dependent failure initiators orinterference during DFA/FFI.

Thanks for your reading, in case that there are any mistakes or inappropriacies, please inform me to correct them. 

Any suggestions, feedback and comments are welcome and won't be ignored.

5-  Reference

[1] ISO-26262：2018 series standards

[2] Bing images

6-  About 功能安全沙龙

功能安全沙龙 is used as a Wechat Public Account for the technical sharing platform on following topics :

• ISO 26262
• SOTIF/ ISO 21448
• Cyber-security/J3061 or ISO-21434
• Powertrain Control of PHEV and EV
• ADAS or ADS or AD vehicles

If you are interested in those topics, please  subscribe to WeChat public account by scanning following Q-R code below: