As system complexity increases in automotive functional safety, the importance of analyzing dependent failures that occur through interactions between multiple elements is growing. The ISO 26262 standard requires Dependent Failure Analysis (DFA) to systematically manage these dependent failures, with Initiator (or DFI, Dependent Failure Initiator) being the core concept that serves as the starting point for this analysis.

This article will deeply cover everything from the definition of Initiator in the ISO 26262 perspective to practical application strategies.

Table of Contents

1. What is an Initiator and What Role Does it Play in DFA?

In the ISO 26262 standard, an Initiator or DFI is defined as “a single root cause that causes multiple elements to fail through coupling factors.” This refers to the starting point (Fault Initiator) where a single cause simultaneously or sequentially affects two or more components in a system, causing dependent failures. DFA is a technique that identifies these Initiators, analyzes their impact, and evaluates the possibility of safety goal violations.

Initiator analysis is particularly important in the following two situations:

ASIL Decomposition: When sharing a functional safety requirement among two or more sub-elements to lower the ASIL grade (e.g., decomposing ASIL D into ASIL B+B). In this case, independence between the distributed channels must be demonstrated. If there is a situation where both channels fail together due to the same Initiator (Common Cause Failure), the assumption of independence breaks down, invalidating the ASIL decomposition. ISO 26262-9:2018 Section 5 requires the exclusion of dependent failures when applying ASIL decomposition and stipulates that DFA must be performed for this purpose.

Freedom from Interference (FFI): When elements with different ASIL grades or QM and ASIL elements coexist on the same hardware or software (e.g., QM infotainment and ASIL D brake control loaded on the same SoC). It must be demonstrated that failures or malfunctions of lower safety grade elements do not interfere with the safety functions of higher safety grade elements (ISO 26262-9:2018 Section 6). This is also achieved by identifying and eliminating potential sources of mutual interference (Initiators) through DFA.

In summary, an Initiator is the starting point of DFA analysis and serves as a systemic vulnerability identifier that systematically discovers potential failure propagation paths (Coupling) through shared resources/infrastructure during the architectural design phase. Each Initiator is evaluated for its level of threat to safety goals through coupling factor analysis, ultimately providing the basis for safety measure development.

2. Seven Types of Initiators Classified by ISO 26262

ISO 26262-9:2018 Annex C and standard documents classify representative Initiator types that cause dependent failures into seven groups. When performing DFA, it’s important to use these types as a checklist to identify Initiator candidates without omission.

Shared Resource

Definition: Failure of a physical resource commonly used by two or more elements. Causes simultaneous failure of all elements sharing that resource.

Practical Examples:

Power: Failure of a common power rail supplying multiple ECUs
Clock: PLL defect when dual redundant MCUs use the same clock signal
Memory/CPU core: Shared L2 Cache in Dual-core CPU, using the same Reset circuit

Risk Characteristics: High – Wide impact depending on the physical sharing scope. A single failure can lead to the loss of multiple safety functions. Occurrence probability can be quantified (e.g., FIT).

Shared Information Input

Definition: Two or more elements depend on the same input signal/information source. Errors in the input itself cause simultaneous failures of multiple functions.

Practical Examples:

Single sensor: ABS/ESC jointly using a speed sensor signal
GPS signal: Shared between navigation (QM) and ADAS (ASIL B)

Risk Characteristics: High – Affects all functions using shared information. Sensor/information errors can damage multiple ASIL functions.

Insufficient Environmental Immunity

Definition: System components exposed to the same environmental stress. Multiple elements fail simultaneously due to electromagnetic interference (EMI), temperature, vibration, etc.

Practical Examples:

Simultaneous malfunction of adjacent circuits when strong EMI occurs
Loss of function of all nearby sensors due to engine room overheating
Simultaneous short circuit of sensors connected to connectors due to moisture penetration

Risk Characteristics: Medium – Extreme environments are low probability but when they occur, cause serious multiple failures. Affects all elements under the same environmental conditions.

Systematic Coupling

Definition: Simultaneous failures due to defects in the development phase or system design linkage. Software bugs, requirement errors, etc., affecting multiple functions.

Practical Examples:

Redundant SW modules having the same software bug
Two channels calibrated with the same incorrect calibration values
Multiple ECUs with the same inherent design flaws (common library errors, etc.)

Risk Characteristics: Medium-High – Fatal when discovered. Can be prevented by development process. Affects all instances reflecting the defect.

Components of Identical Type

Definition: Common defects in identical type components that underwent the same design/manufacturing. Simultaneous failure of multiple components due to manufacturing lot defects or design limitations.

Practical Examples:

Multiple airbag sensors with the same manufacturing defect
Using the same power transistors in dual motor drivers

Risk Characteristics: Medium – Fatal if there are hidden common defects even with high individual reliability. Affects all channels/modules using identical components.

Communication Coupling

Definition: Fault propagation through communication/data interfaces. Communication errors in one element affecting another (data errors, bus failures, etc.).

Practical Examples:

Multiple ECU function degradation due to CAN communication bus errors
Corruption in shared memory data transferring to other SW
Defect transfer when MCU partitions use shared cache

Risk Characteristics: High – Modern vehicles have strong network connections so impact is large. High propagation requires priority consideration. Affects all nodes using the relevant communication network/shared resource.

Unintended Interface

Definition: Fault transfer due to unexpected interactions that were not intended. Although designed to be separate, influence through hidden paths (EMI coupling, inadequate grounding, etc.).

Practical Examples:

Crosstalk due to coupling capacitance between signal lines
Memory invasion due to poor DMA control
Noise infiltration due to inadequate body grounding

Risk Characteristics: Medium – Difficult to detect, occurs intermittently. Widespread impact along potential paths overlooked in design. Identified through expert review/testing.

These Initiators can act as causes of Cascading Failure and Common Cause Failure. ISO 26262 emphasizes that the higher the ASIL grade of a system, the more priority should be given to reviewing these Initiator types, and especially in ASIL D systems, it must be demonstrated that there are no applicable issues for all Initiator types listed above or that sufficient mitigation measures are in place.

3. Initiator Analysis Process and Practical Application Strategies

Initiator analysis in DFA proceeds in an iterative flow of identification → impact analysis → countermeasure preparation → verification and result confirmation.

(1) Initiator Identification Stage

Target Decision: Select pairs or groups of elements requiring mutual independence, such as ASIL decomposition/redundancy elements, QM-ASIL mixed elements, etc., as analysis targets.

Candidate Identification:

Conduct systematic checklist-based brainstorming using the list of 7 DFI types from ISO 26262-9 Annex C.
Analyze system architecture to map shared resources (hardware, software modules, communications, etc.).
Utilize existing FMEA/FTA results to extract causes that commonly affect multiple functions (same cause items in FMEA, shared events in FTA Cut Sets).
Consider potential systematic/human errors in development process and operational stages.

Deliverables: List of Initiator candidates (Excel draft format), dependency matrix.

(2) Initiator Impact Analysis Stage

Impact Assessment: Analyze the potential impact of each identified Initiator on system safety goals.

Qualitative analysis: Describe failure propagation scenarios. Describe which paths and which elements lead to failure when an Initiator occurs, and FTA can be used if necessary.
Quantitative analysis (if needed): For random hardware failures, risk can be assessed based on failure rate (FIT) data. However, since many Initiators are systemic/environmental factors, quantification is difficult, and ISO 26262 tends to rely on qualitative judgment.

Relevance Determination: Determine whether a safety goal could actually be violated due to the Initiator and distinguish between Relevant/Not relevant.

Prioritization: Assign priorities (e.g., High/Medium/Low) to high-impact Initiators. This is evaluated from the perspective of probability of occurrence (frequency) and scope of impact (simultaneous effect on multiple safety goals). FMEA’s Severity x Occurrence or modified beta factor techniques can be used, but ISO 26262 requires sufficient graphical analysis and measures rather than simple quantitative scoring.

Deliverables: Initiator impact analysis results (completion of “Impact/Result” column in Excel table), priority marking.

(3) Safety Countermeasure Identification Stage

Countermeasure Derivation: Derive safety mechanisms or design changes that can eliminate or control dependent failures for items determined to be dangerous Initiators.

Utilizing ISO 26262-11 guide: The standard provides a list of examples of safety measures to consider for representative Initiator types (e.g., shared resource failure → power/clock monitor, environmental factors → protection circuit, development errors → multiple diversity design, communication interference → protocol error handling, unintended interface → physical shielding, etc.).
Key strategies: Diversity and separation strategies become the main countermeasures. These include physical separation (differential signals, guard rings), time division (TDMA), logical separation (hypervisor, MPU/MMU), and multiple diversity design. Implementation of defensive design and monitoring/diagnostic mechanisms is also important.

Deliverables: List of countermeasures per Initiator (completion of “Safety Measures” column in Excel table). Each measure is assigned a unique ID and managed as a requirement.

(4) Verification and Result Confirmation Stage

Effectiveness Verification: Verify that the prepared measures sufficiently reduce the risk of dependent failure.

Quantitative assessment: For random hardware failure Initiators, calculate whether the failure rate/dual-point probability after applying the measures satisfies the hardware targets (SPFM, LFM, PMHF). If an Initiator overlaps with a single point of failure (SPF), it is treated as an SPF in FMEDA and recorded in DFA, but should be clearly stated to avoid duplicate analysis or omission.
Testing and simulation: Systemic/environmental Initiators are verified through tests or simulations. These include EMC tests (EMI interference), Fault Injection Tests (memory corruption, CPU occupation), stress tests (temperature, overvoltage), expert assessment, etc. Software interference, in particular, is difficult to confirm without Fault Injection Tests.

Residual Risk Assessment: Review whether the residual risk remaining after applying measures is at an acceptable level.

Iterative Process: If verification results show that measures are insufficient, return to the relevant stage, improve measures, and repeat verification.

Documentation: Prepare a DFA verification report and a DFA Summary document summarizing key DFA results to demonstrate compliance with ISO 26262 requirements. The final DFA results are included in the Safety Case for use in audits.

Deliverables: DFA verification report, DFA Summary document.

4. Practical Application Case: SoC Sharing between ASIL D Brake Control and QM Infotainment

A scenario where ASIL D brake control function and QM infotainment function are integrated on a single SoC (System-on-Chip) is a representative case of Mixed-Criticality SoC application and starkly demonstrates the necessity of DFA.

Initiator Identification:

Shared resources: SoC failure itself (common power/clock/thermal runaway), external common power supply failure, interference with internal shared resources within SoC (memory bus, cache, interrupt lines, CPU core competition).
Environmental: Excessive temperature rise (SoC heat generation or external high temperature).
Systematic: OS or driver defects (common kernel bugs, shared driver defects).

Impact Analysis: SoC/power Initiators are highly dangerous with a high possibility of directly violating ASIL D safety goals and can be considered dual-point failures. Internal resource interference can be fatal, leading to brake control errors in case of memory corruption or brake control timeout in case of CPU occupation. OS/driver bugs have a low frequency of occurrence but can have serious impacts.

Mitigation Measures:

Hardware separation/redundancy: Perform ASIL D functions and QM functions on separate MCUs, or strengthen redundant cores and physical isolation within the same SoC. Add core resource redundancy and SoC external Fail-Safe circuits.
Power stabilization: Introduce dual power sources, maintain auxiliary power, transition to a safe state when low voltage is detected (e.g., complete braking), SoC internal power monitoring.
Software separation/monitoring (FFI): Memory protection (MPU/MMU), time partitioning (real-time OS, time slices), highest priority safety tasks, watchdog/SMU monitoring. Utilize isolation processes/virtualization (hypervisor).
Common SW error prevention: Thorough development verification, independent review, interface minimization, shared resource protection (priority inheritance, etc.).

Verification: Fault Injection tests (SW partitioning effect, memory/CPU interference), hardware tests (low voltage, Failsafe operation during SoC reset), independent safety reviewer review.

This case shows that when integrating non-safety (QM) functions with the highest grade (ASIL D) functions, an extremely conservative approach is necessary, and safety partitioning technology and test-based verification are essential.

5. Standard Compliance and Audit Preparation Strategy

During ISO 26262 functional safety audits, auditors focus on the following aspects related to DFA:

Completeness of DFA results: Whether there are any omissions in the analysis for all important component pairs (redundant channels, monitor-monitored, mixed ASIL).

Validity of Initiator identification: Whether sufficient consideration has been given to common coupling elements (power, clock, environment, system, etc.) presented in standards such as ISO 26262 Annex C.

Appropriateness of safety measures: Whether the countermeasures for identified Initiators are effective and convincingly presented, and whether there is evidence of effectiveness (test/analysis results).

Residual Risk management: How residual risks remaining after mitigation are handled and whether they are properly argued in the safety case.

Traceability: Whether requirement measures derived from DFA are traced to actual design/implementation/verification.

For audit preparation, it is necessary to check items such as DFA target identification, coverage of 7 Initiator types, risk assessment records, measure specification and allocation, verification plan/execution, document consistency, and compliance with ISO requirements (Work Product) as a checklist. Particularly important is presenting the process with evidence of how the analysis was conducted and on what basis safety was secured, rather than simply claiming “there is no problem.”

6. Practical Challenges, Solutions, and Future Outlook

Dependent Failure Analysis (DFA), an important analytical method for ensuring functional safety in automotive electronic systems, faces various challenges in practice. This article examines the difficulties experienced in the field, their solutions, and future prospects in a changing technological environment.

Practical Challenges

The main difficulties commonly experienced by field engineers when performing DFA include:

Omission of Potential Initiators (Causes): It’s easy to overlook environmental factors, human errors, and limitations of safety mechanisms themselves.
Overlooking Scenario Combinations: There may be failure to identify cases where various factors act in combination.
Conceptual Misunderstandings: Misconceptions exist such as “ASIL decomposition automatically ensures independence” or “DFA equals CCF (Common Cause Failure).”
Limitations of Analysis Tools: Existing tools may not capture all complex dependencies.
Resource Constraints: Limitations in time, manpower, and budget can make thorough analysis difficult.

Effective Solutions

Practical solutions to address these challenges include:

Multidisciplinary Team Reviews: Identify missed Initiators from various expert perspectives through methods such as HAZOP (Hazard and Operability Study).
Recognizing Coverage Limitations of Safety Mechanisms: Clearly acknowledge and document that no safety mechanism is 100% perfect.
Example-Based Learning: Ensure team members accurately understand the differences between common cause failures and cascading failures through specific cases.
Simulation/Test Prototyping: Increase analysis accuracy through decision-making based on actual data.
Efficiency Strategies: Utilize risk-based prioritization, reuse of existing analyses, workshop approaches, and parallel work processes.

Tool Utilization Approaches

While there are currently no tools that can fully automate DFA, the following existing tools can support analysis:

MBSE (Model-Based Systems Engineering) Tools: Generate shared resource matrices using SysML, AADL, etc.
Safety Analysis Tools: Query functions in FMEA/FTA databases such as Medini, Ansys, etc.
FTA Cut Set Analysis: Identify common elements through minimum cut sets
Simulation-Based Exploration: Verify system behavior under various conditions

Latest Technology Trends and Future Outlook

With technological advancements in the automotive industry, DFA is also facing new challenges and opportunities:

Autonomous Driving Systems

Resource Competition Issues: Timing and memory bandwidth competition in high-performance computing (HPC) emerging as new Initiators
Sensor Fusion Problems: Potential dependencies related to data and algorithms
Environmental Specific Situations: Lighting conditions etc. can simultaneously affect multiple sensors
Response Technologies: Increasing importance of Time-Space Partitioning, Multicore analysis tools, scenario-based verification, etc.

Trends After ISO 26262:2018

DFA established as an essential activity
Expansion of DFI (Dependent Failure Initiative) guides from semiconductor suppliers with the addition of Part 11
Cybersecurity Integration: Introduction of ‘Cyber-Safety’ perspective through linkage with ISO 21434
Inclusion of intentional common causes such as hacker attacks as analysis targets

Future Standard Development Directions

Interference Analysis for Multicore/Complex SoCs: Specification of timing analysis, etc.
System-Level CCF Scoring: Development of quantitative evaluation methods
Linkage with SOTIF (Safety Of The Intended Functionality): Non-fault dependency analysis
Integration of Human/Organizational Factors: Development of holistic dependency analysis methodologies beyond technical elements

Conclusion

A deep understanding and systematic management of Initiators is a key challenge in ensuring the safety of increasingly complex automotive E/E (Electric/Electronic) systems. Beyond compliance with the ISO 26262 standard, it is necessary to maximize independence from the system architecture design stage and proactively identify Initiators according to new technology trends.

DFA is an essential journey to achieve the ultimate goal of functional safety: “Ensure that no single cause can undermine our safety.” As technology advances and systems become more complex, the importance of dependency analysis will continue to grow.

Practical Challenges, Solutions, and Future Outlook

Practical Challenges

The main difficulties commonly experienced by field engineers when performing DFA include:

Omission of Potential Initiators (Causes): It’s easy to overlook environmental factors, human errors, and limitations of safety mechanisms themselves.
Overlooking Scenario Combinations: There may be failure to identify cases where various factors act in combination.
Conceptual Misunderstandings: Misconceptions exist such as “ASIL decomposition automatically ensures independence” or “DFA equals CCF (Common Cause Failure).”
Limitations of Analysis Tools: Existing tools may not capture all complex dependencies.
Resource Constraints: Limitations in time, manpower, and budget can make thorough analysis difficult.

Effective Solutions

Practical solutions to address these challenges include:

Multidisciplinary Team Reviews: Identify missed Initiators from various expert perspectives through methods such as HAZOP (Hazard and Operability Study).
Recognizing Coverage Limitations of Safety Mechanisms: Clearly acknowledge and document that no safety mechanism is 100% perfect.
Example-Based Learning: Ensure team members accurately understand the differences between common cause failures and cascading failures through specific cases.
Simulation/Test Prototyping: Increase analysis accuracy through decision-making based on actual data.
Efficiency Strategies: Utilize risk-based prioritization, reuse of existing analyses, workshop approaches, and parallel work processes.

Tool Utilization Approaches

While there are currently no tools that can fully automate DFA, the following existing tools can support analysis:

MBSE (Model-Based Systems Engineering) Tools: Generate shared resource matrices using SysML, AADL, etc.
Safety Analysis Tools: Query functions in FMEA/FTA databases such as Medini, Ansys, etc.
FTA Cut Set Analysis: Identify common elements through minimum cut sets
Simulation-Based Exploration: Verify system behavior under various conditions

Latest Technology Trends and Future Outlook

With technological advancements in the automotive industry, DFA is also facing new challenges and opportunities:

Autonomous Driving Systems

Resource Competition Issues: Timing and memory bandwidth competition in high-performance computing (HPC) emerging as new Initiators
Sensor Fusion Problems: Potential dependencies related to data and algorithms
Environmental Specific Situations: Lighting conditions etc. can simultaneously affect multiple sensors
Response Technologies: Increasing importance of Time-Space Partitioning, Multicore analysis tools, scenario-based verification, etc.

Trends After ISO 26262:2018

DFA established as an essential activity
Expansion of DFI (Dependent Failure Initiative) guides from semiconductor suppliers with the addition of Part 11
Cybersecurity Integration: Introduction of ‘Cyber-Safety’ perspective through linkage with ISO 21434
Inclusion of intentional common causes such as hacker attacks as analysis targets

Future Standard Development Directions

Interference Analysis for Multicore/Complex SoCs: Specification of timing analysis, etc.
System-Level CCF Scoring: Development of quantitative evaluation methods
Linkage with SOTIF (Safety Of The Intended Functionality): Non-fault dependency analysis
Integration of Human/Organizational Factors: Development of holistic dependency analysis methodologies beyond technical elements