Dependent Failure Analysis (DFA) and its relevance in Functional Safety
In the complex world of automotive systems, ensuring the safety and reliability of software components is of utmost importance. Due to the multiple interactions involved between systems and components, there are a lot of dependencies that are built in. Sometimes failures occurring in one element can cause failures in other elements. These are called ‘Dependent Failures’. In other words, Dependent failures refer to the failures whose probability cannot be expressed by an unconditional probability of the individual event. (Humphreys, P., & Jenkins, A. M. 1991). These failures if not addressed in the case of safety systems would lead to violation of safety goals sometimes with highly severe consequences. This is where Dependent Failure Analysis has proven to be valuable. We will explore the significance of DFA in hardware development from the perspective of ISO 26262 and how it helps in ensuring 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. The goal of DFA is 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 there are various tools 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 segments of a system 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 to achieving freedom from interference is block partitioning, where faults detected in one block are contained within that block and do not cascade into other blocks.
Independence, in the context of automotive functional safety, is the absence of dependent failures that lead to safety goal violations. To call a system or module independent both CCF and CF must be addressed
When is DFA started and what are the inputs required
DFA is generally started during ASIL decomposition stage and takes inputs from FMEA and FTA. System architecture at the required levels of decomposition, 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 architecture design is more refined. Combining both approaches provides a comprehensive understanding of dependent failures and contributes to meeting functional safety requirements.
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 firstname.lastname@example.org