Dependent Failure Analysis: A Guide

In the highly complex world of automotive systems, ensuring the safety and reliability of software components is of the utmost importance. Due to the multiple interactions involved between systems and components, many dependencies are built in.

Sometimes, failures in one element can cause failures in other elements. These are called ‘Dependent Failures’.

In other words, Dependent failures refer to failures whose probability cannot be expressed by an unconditional probability of the individual event. (Humphreys, P., &  Jenkins, A. M. 1991). 

If not addressed in the case of safety systems, these failures would lead to violations of safety goals, sometimes with highly severe consequences. This is where Dependent Failure Analysis has proven valuable. We will explore the significance of DFA in hardware development from the perspective of ISO 26262 and how it helps ensure the safety of automotive systems. 

Types of Dependent Failures: 

There are two types of dependent failures,  

1. Common cause failures (CCF)
2. Cascading failures (CF)

Common cause failures occur when two or more elements fail due to a single specific event or root cause.  

On the other hand, cascading failures occur when the failure of one component leads to the failure of another in a cascading fashion 

Dependent Failure Analysis (DFA) involves a systematic approach to identify and analyse both cascading and common cause failures. DFA aims to detect and eliminate these dependent failures to achieve freedom from interference and independence in automotive systems. The ISO 26262 standard provides guidelines for performing dependent failure analysis, and various tools are available to aid in the analysis process. The analysis typically involves the identification of failure causes, failure modes, the impact of failures, existing safety measures, risk analysis, and action items for design changes. 

DFA is further decomposed into Common cause failure analysis and Cascading failure analysis  

Common Cause Failure Analysis 

Common cause failure analysis is a key aspect of dependent failure analysis. It involves identifying elements for which common causes of failure need to be determined. Factors such as software implementation, partitioning, redundancy, and external resource control influence the selection of elements for analysis.  

e.g., A cell temperature measurement for a HV BMS application uses 3 temperature sensors to meet the required FIT. If the delta between the sensors is ≥3° C the battery is isolated from the HV Bus for safety. All three sensors fail simultaneously while maintaining the delta between the sensors within 3° C due to common causes such as random hardware faults or development faults.  In this case, the coupling factor for the common cause failures could be that all the sensors use the same technology and identical hardware elements.  

Figure 1: Example of a Common Cause Failure in temperature measurement

Generally, cut sets from fault trees that form redundant pairs are analysed for CCFs by checking against coupling classes (Refer Figure 1).  

Cascading Failure Analysis 

Cascading failure analysis is another important aspect of dependent failure analysis. It involves analysing the exchange of data or transfer of loads between source and destination elements to identify transmitted by the source element that can cause cascading failures. The ASIL assigned to the source and destination elements is also considered in the analysis. Factors such as timing and execution, memory corruption, and information exchange are analysed to identify potential failures.  

e.g., A function going into a deadlock and utilizing resources continuously without allowing other functions to be executed is a classic case of cascading failure 

Differences between CCF and Cascading failure 

Table 1: Differences between CCF’s and cascading failures (Xie, Lin & Lundteigen, Mary & Liu, Yiliu. (2018))

Achieving Freedom from Interference and Independence 

Freedom from interference refers to the absence of cascading failures between elements that result in safety goal violations. Freedom from interference between elements is validated by identifying cascading failures and ensuring that faults in lower ASIL components do not propagate to higher ASIL components. A query might arise as to why not construct all system segments to conform to ASIL C/ASIL D standards. The simple answer is that it is not financially viable. Moreover, the same outcome can be attained by a combination of lower ASIL-rated systems or components that operate independently of one another and exhibit non-interference. 

Achieving freedom from interference involves mitigating cascading failures through various safety measures. One approach is block partitioning, where faults detected in one block are contained within that block and do not cascade into other blocks.  

In the context of automotive functional safety, independence is the absence of dependent failures that lead to safety goal violations. CCF and CF must be addressed to call a system or module independent. 

When is DFA started and what are the inputs required 

DFA generally starts during ASIL decomposition stage and takes inputs from FMEA and FTA. System architecture at the required decomposition levels, safety architecture, safety goals and a DFA template are required to start a DFA.  The analysis can be performed at the system, software, and hardware levels.  

Approaches to DFA 

DFA can be approached in two ways: top-down (deductive) and bottom-up (inductive) analysis. The top-down approach starts from top-level failures or safety goal violations and breaks them down to identify failure modes and dependent failures. This approach is useful during the architectural design phase to make informed design decisions. On the other hand, the bottom-up approach starts with a set of initiating causes and analyses the failures they may cause. It is typically employed when the architectural design is more refined. Combining both approaches provides a comprehensive understanding of dependent failures and contributes to meeting functional safety requirements. 

Conclusion 

Dependent Failure Analysis is a crucial technique in achieving freedom from interference and independence in automotive systems. By analysing and addressing cascading and common-cause failures, automotive experts can ensure the safety and reliability of software components. The analysis involves identifying failure causes, modes, and impacts, as well as implementing appropriate safety measures and design changes. Dependent failure analysis, as a methodology, can enhance the safety and performance of automotive systems, contributing to a safer driving experience for all. 

For further information on how to apply DFA or to discuss safety analysis and risk management at your organisation, get in touch with us at enquiries@3sk.co.uk