When working on automotive functional safety projects, we often encounter a persistent problem: "Is this fault a Common Cause Failure (CCF) or a Cascading Failure (CF)?" This question can be a real headache during design, verification, and even during audits. I've faced similar dilemmas in the field, so in this article, I'm going to thoroughly break down these two concepts from an ISO 26262 perspective. I'm confident that by the end of this article, you won't struggle with this issue anymore! 😊
Key Terms at a Glance 🤔
First, to understand common cause and cascading failures, let's look at some key terms defined in ISO 26262. Knowing these terms will greatly help in grasping the concepts.
| Term | ISO 26262 Definition Summary | Keywords |
|---|---|---|
| Common Cause Failure (CCF) | Single cause leading to simultaneous failure of multiple elements ⟶ No causal propagation between elements | Parallel·Simultaneous |
| Cascading Failure (CF) | Failure of one element sequentially leading to failure of other elements ⟶ Causal propagation A→B→C | Sequential·Propagation |
| Dependent Failure | All failures that are not statistically independent (= CCF + CF) | Higher-level concept |
| FFI (Freedom from Interference) | Ensures that cascading failures do not violate the Safety Goal (SG) | Excluding CCF |
| DFA (Dependent Failure Analysis) | ISO 26262-9 analysis activity to identify and verify all dependent failures (CF + CCF) | Utilizes 7 Initiators |
ISO 26262 treats Dependent Failure as a higher-level concept that includes Common Cause Failures (CCF) and Cascading Failures (CF). Freedom from Interference (FFI) specifically focuses on ensuring freedom from cascading failures.
Common Cause Failure vs. Cascading Failure: The Distinction 📊
These two types of failures may seem similar, but there's a crucial difference: the causal relationship and temporal characteristics of the failure. This table will give you a clear overview.
| Distinction Criteria | Common Cause Failure (CCF) | Cascading Failure (CF) |
|---|---|---|
| Causal Relationship | Cause → A, B, C (Parallel) | A → B → C (Sequential Propagation) |
| Temporal Characteristics | Virtually simultaneous (Δt ≤ team-defined limit) | Time delay present |
| FTA Gate | CCF Gate | Sequence Gate |
| FFI Verification | Not applicable | Required |
| Mitigation | Separation·Diversity·Monitoring | Isolation·Partitioning·Protection Circuit |
Honestly, the most crucial tip for distinguishing these two types of failures is to remember "simultaneous or sequential", and you'll correct most classification errors. It's truly a useful point!
ISO 26262 exclusively uses 'Common Cause Failure' as its official term. 'Common Mode' is more commonly used in IEC 61508 or general reliability terminology, so be careful not to confuse them.
10 Common Ambiguous Points - Detailed Resolution 🔍
In the field, there are often ambiguous situations when distinguishing between CCF and CF. I'll share practical solutions for each of these situations, based on my own experiences. Understanding these points well will make passing functional safety audits a breeze!
📝 Point of Confusion 1: Common Cause vs. Common Mode Interchangeability
In ISO 26262, only Common Cause Failure is used. 'Common Mode' is more commonly used in IEC 61508 or other general reliability terms, so be careful when writing documentation. I remember struggling with this confusion myself in my early days!
📝 Point of Confusion 2: Lack of 'Simultaneous' Threshold
The term 'simultaneous' when defining CCF can be ambiguous. Our team usually agreed on and documented a Δt (e.g., 10 ms) at the beginning of the project to address this issue. Without a clear criterion, failure analysis later on can be a real headache.
📝 Point of Confusion 3: Mixed Scenarios (CCF + CF)
Sometimes a scenario involves both common cause and cascading failures. In such cases, the key is to model them separately in FTA (Fault Tree Analysis) using parallel gates for CCF and sequence gates for CF. This allows for clear analysis of complex failure paths.
📝 Point of Confusion 4: β-Factor Application
The β-Factor is a crucial element when calculating CCF probabilities. While it's common to use the IEC 61508 method , it's essential to always provide objective evidence such as test results or reliability databases. We can't just apply it arbitrarily, can we?
📝 Point of Confusion 5: Misconception "DFA is for HW only"
Many people mistakenly believe that DFA (Dependent Failure Analysis) applies only to hardware, but that's absolutely not true! It must include software issues like shared RAM or RTOS conflicts, and even operational errors. I missed this point a lot when I was a beginner.
📝 Point of Confusion 6: DFA vs. FMEA/FTA/FMEDA Distinction
These analyses have different purposes. DFA is about identifying and verifying dependent failures, while FMEA/FTA/FMEDA provide different outputs for their respective objectives. Therefore, it's crucial to remember that separate plans are needed for each analysis.
📝 Point of Confusion 7: FFI Scope
FFI (Freedom from Interference) applies only to cascading failures. It's important that common cause failures are not subject to FFI. CCF must be managed with a separate CCF mitigation plan.
📝 Point of Confusion 8: Only Random HW for CCF?
Some people sometimes think that only random hardware failures qualify as CCF. However, failures caused by systemic reasons, such as identical firmware bugs or OTA (Over-The-Air) update errors, are also included in CCF. The scope is broader than you might think!
📝 Point of Confusion 9: Just Copying the 7 Initiator List
When performing DFA, many simply copy the 7 initiators (power, clock, I/O, physical proximity, shared SW, EMC, human factors) provided by ISO 26262. However, it is far more efficient and clear to create a table mapping each initiator to its affected element, propagation path, and corresponding mitigation.
📝 Point of Confusion 10: DFA Update Timing
DFA is not a one-time activity. It must be evaluated for impact and updated whenever there are changes in design, ASIL level, lot, or software release. Failing to do this can lead to significant problems later on.
The 7 Initiators mentioned above help systematically identify potential causes of dependent failures. This enables a more robust system design.
Analysis Workflow 💡
Now, let's look at the overall flow for distinguishing common cause and cascading failures and implementing countermeasures. Following this workflow will enable efficient functional safety analysis!
- Determine Simultaneous vs. Sequential: The first step is to clearly decide whether failures occur simultaneously or propagate sequentially.
- List Risk Scenarios with 7 DFA Initiators: Using the 7 Initiators (power, clock, I/O, physical proximity, shared SW, EMC, human factors), you must identify all possible risk scenarios without omission.
- FFI Evaluation: Breaking/Isolating Cascading Failure Paths: To ensure that cascading failures (CF) do not violate the safety goal (SG), perform an FFI evaluation to reliably break and isolate the failure propagation paths.
- CCF Mitigation: Diversity·Physical Separation·Probability Reduction based on β-Factor: For common cause failures (CCF), apply functional or design diversity and minimize impact through physical separation. Also, effectively reduce failure probability using the β-Factor.
- PMHF Formula Integration: Sum of Independent (MPF) + β*λ_total (CCF): In the final PMHF (Probabilistic Metric for Random Hardware Failures) calculation, sum the probabilities due to independent failures (MPF) and common cause failures (CCF) to evaluate the system's safety.
- Interlocking with Change Management: Automatic Notification with "DFA Impact" Flag: Establishing a system that automatically alerts you if a design change impacts DFA is incredibly convenient for ensuring analyses are updated without omissions.
Revisiting with Power Supply Example 📚
The theory might seem difficult, so let's clarify the distinction between common cause and cascading failures using a real-world power supply failure scenario. This example should give you a good grasp of the concept.
| Scenario | Classification | Description |
|---|---|---|
| P Standalone Failure → System Power Loss | SPF | SG violation by a single element |
| P Failure (External Surge) → A·B·C simultaneous Off | CCF | Single cause with parallel impact |
| A Failure → P Failure → B·C Sequential Off | CF | Propagation A→P→B/C, FFI required |
See? It's much clearer with an example, isn't it? It just reinforces that "simultaneous or sequential" is truly the core distinction.
Conclusion: Key Takeaways 📝
In this article, we've explored common cause and cascading failures in detail from an ISO 26262 perspective and looked at how to clearly resolve various points of confusion that can arise in real-world scenarios. To summarize:
- Clarify Concepts: Common Cause Failure (CCF) can be distinguished as 'simultaneous parallel failures due to a single cause', while Cascading Failure (CF) is defined as 'sequential propagation of a failure from one element to another'. 'Simultaneous' and 'sequential' are the key distinguishing terms!
- Utilize DFA: DFA is a dependent failure analysis activity that covers both CCF and CF, allowing for a systematic approach based on the 7 Initiators. Don't forget to include not only hardware but also software and operational failures.
- Apply Practical Mitigations: For CCF, apply diversity and physical separation, and reduce probability through β-Factor. For CF, apply FFI to isolate and block failure propagation paths to achieve safety goals.
- Continuous Management: It's crucial to periodically update DFA and consistently manage related documents whenever there are design or environmental changes.
I hope this article has been helpful for your automotive functional safety projects. Common cause and cascading failures aren't so difficult now, right? If you have any further questions, please feel free to ask in the comments! 😊
Common Cause vs. Cascading Failure Key Summary
Frequently Asked Questions ❓
'ISO26262' 카테고리의 다른 글
| [ISO26262] #1. The Hidden Risk in Your Car: Understanding Latent Faults Before It's Too Late. (3) | 2025.06.15 |
|---|