FMEA vs FTA in Automotive Functional Safety (ISO 26262) Explained

Hello, automotive safety engineers and functional safety professionals! FMEA (Failure Mode and Effects Analysis) and FTA (Fault Tree Analysis) are the two most fundamental safety analysis techniques in the ISO 26262 functional safety lifecycle. If HARA tells you what the hazards are and how critical they are, FMEA and FTA tell you how failures actually occur in your design and whether your safety mechanisms adequately address them.

In this comprehensive guide at PiEmbSysTech, we will explain both techniques in depth – covering their fundamental principles, their role in ISO 26262, the step-by-step process for each, worked automotive examples, how they relate to FMEDA, how they complement each other, and the practical tools and best practices used in industry. Let us begin.

1. Why Safety Analysis is Essential in ISO 26262

ISO 26262 requires safety analysis at multiple stages of the development lifecycle to verify that the safety concept and the design adequately address the identified hazards. The standard mandates two complementary categories of analysis: inductive analysis (bottom-up, exemplified by FMEA) and deductive analysis (top-down, exemplified by FTA). Both qualitative and quantitative forms of these analyses are required, depending on the ASIL level and the development phase.

Safety analysis serves four primary purposes in ISO 26262: verifying the Functional Safety Concept and Technical Safety Concept, identifying failure modes and their effects to ensure safety mechanisms provide adequate coverage, calculating quantitative hardware metrics (SPFM, LFM, PMHF), and supporting the Dependent Failure Analysis (DFA) that verifies independence between safety-relevant elements.

2. Inductive vs Deductive Analysis – The Fundamental Distinction

The difference between FMEA and FTA begins with their fundamental analytical direction:

Inductive analysis (FMEA – bottom-up): Starts from individual component failure modes and traces their effects upward through the system hierarchy to determine the impact on the item and ultimately on the safety goals. The question is: “If this component fails in this way, what is the effect on the system?”

Deductive analysis (FTA – top-down): Starts from an undesired top-level event (typically a safety goal violation) and traces downward through the system to identify all the individual failures and failure combinations that could cause the top event. The question is: “What combinations of failures could cause this safety goal to be violated?”

This directional difference makes the two methods naturally complementary. FMEA ensures that every component failure is accounted for and its effects understood. FTA ensures that every path to a safety goal violation is identified – including combinations of failures that FMEA, with its single-failure-at-a-time assumption, may not fully capture.

3. Where FMEA and FTA Appear in the ISO 26262 Lifecycle

FMEA and FTA are used at multiple stages of the ISO 26262 safety lifecycle:

Concept Phase (Part 3 – FSC verification): Qualitative FMEA and FTA are used to verify that the Functional Safety Concept correctly addresses all relevant failure paths from the safety goals. At this level, the analysis is performed on the preliminary architecture at a functional block level.

System Level (Part 4 – TSC verification): System-level FMEA and FTA verify that the Technical Safety Concept and system architectural design correctly implement the FSRs. The analysis is now performed on the actual system design with identified hardware and software elements.

Hardware Level (Part 5 – hardware safety evaluation): Hardware FMEA (and its quantitative extension, FMEDA) is used to classify every hardware failure mode and calculate the quantitative metrics: SPFM, LFM, and PMHF. Quantitative FTA may be used to calculate the probability of safety goal violations. This is where the majority of quantitative safety analysis effort occurs.

Software Level (Part 6): Software FMEA may be used to analyze software component failure modes and their effects on safety functions – though software analysis focuses more on systematic failure avoidance than probabilistic analysis.

ISO 26262 Part 4 Table 3 and Part 5 Table 4 specify which analysis methods are recommended, highly recommended, or required at each ASIL level.

4. FMEA Explained – Failure Mode and Effects Analysis

FMEA (Failure Mode and Effects Analysis) is a systematic, inductive (bottom-up) analysis technique that identifies potential failure modes of individual components or functions, determines the effects of each failure mode on the system and its safety goals, evaluates the current detection mechanisms (safety mechanisms) for each failure mode, and identifies the need for additional safety mechanisms where coverage is inadequate.

The FMEA process examines each element in the system architecture, one at a time, and considers all the ways that element could fail – while assuming that all other elements are operating correctly. This one-failure-at-a-time assumption is both FMEA’s strength (it ensures comprehensive coverage of single-point failures) and its limitation (it does not natively capture multiple simultaneous failures, which is where FTA complements it).

5. Types of FMEA in Automotive – System, Design, Process

System FMEA (S-FMEA): Analyzes the system architecture at the functional block level. Each functional element is examined for failure modes and their effects on the overall system behavior and safety goals. System FMEA is used during TSC verification (Part 4).

Design FMEA (D-FMEA / Hardware FMEA): Analyzes the detailed hardware design at the component level – individual ICs, resistors, capacitors, connectors, PCB traces, solder joints. Each component’s failure modes (open, short, drift, stuck-at) are identified, and their effects on the circuit function are traced. D-FMEA is the basis for FMEDA (Part 5).

Process FMEA (P-FMEA): Analyzes the manufacturing process to identify failure modes introduced during production – such as solder defects, component misplacement, incorrect programming, or inadequate testing. P-FMEA supports Part 7 (Production) requirements.

The AIAG/VDA FMEA Handbook (2019) provides the harmonized 7-step approach for automotive FMEA that is widely used in the industry alongside the ISO 26262 safety analysis requirements.

6. Step-by-Step FMEA Process

The FMEA process follows these fundamental steps:

Step 1 – Define the scope and boundaries: Identify the system, subsystem, or component to be analyzed. Define the boundaries, interfaces, and operating conditions. Reference the item definition and system architecture.

Step 2 Identify elements and their functions: List every element within the analysis scope and describe its intended function. For hardware FMEA, this means each component on the schematic. For system FMEA, this means each functional block in the system architecture.

Step 3 – Identify failure modes for each element: For each element, determine all the ways it could fail. Hardware components have characteristic failure modes: open circuit, short circuit, drift (parameter change), intermittent contact, stuck at logical 0 or 1. Software functions may have failure modes: no output, incorrect output, wrong timing, unintended behavior.

Step 4 – Determine the effect of each failure mode: Trace the effect of each failure mode through the system hierarchy – first at the local level (what happens to the immediately connected circuitry), then at the system level (what happens to the system function), and finally at the vehicle level (does it potentially violate a safety goal?).

Step 5 – Identify existing safety mechanisms: For each failure mode that could contribute to a safety goal violation, identify the existing detection or mitigation mechanisms (hardware redundancy, software monitoring, diagnostic functions). Evaluate the diagnostic coverage of each mechanism.

Step 6 – Classify the failure: Based on the failure effect and the detection mechanism, classify the failure into ISO 26262 Part 5 categories: safe fault, single-point fault, residual fault, detected multi-point fault, perceived multi-point fault, or latent multi-point fault.

Step 7 – Identify additional safety mechanisms (if needed): If the existing safety mechanisms provide inadequate coverage and the resulting hardware metrics do not meet the ASIL targets, identify and specify additional safety mechanisms.

7. The FMEA Worksheet – Column-by-Column Guide

Column	Content	Example (EPS Torque Sensor)
Element / Component	The part under analysis	Torque Sensor ASIC (U1)
Function	Intended function of the element	Measure driver steering torque; output digital value via SPI
Failure Mode	How the element can fail	FM1: Output stuck at zero; FM2: Output offset drift; FM3: SPI communication failure
Failure Rate (λ)	Component failure rate (FIT)	50 FIT total (distributed across failure modes)
Failure Mode Distribution	% of total λ for this failure mode	FM1: 30% = 15 FIT; FM2: 40% = 20 FIT; FM3: 30% = 15 FIT
Local Effect	Effect on adjacent circuitry	FM1: MCU reads torque = 0 Nm regardless of actual steering input
System Effect	Effect on system function	FM1: EPS provides no assist (perceived as sudden heavy steering)
Vehicle-Level Effect	Effect on safety goals	FM1: Potential violation of SG-02 (loss of steering assist)
Safety Mechanism	Detection/mitigation measure	FM1: Secondary MCU cross-check via redundant sensor channel (DC = 99%)
Diagnostic Coverage (DC)	% of failure rate detected by safety mechanism	FM1: 99% (High)
Failure Classification	ISO 26262 Part 5 failure category	FM1: Detected multi-point fault (λ_MPF_D); residual = 1% × 15 FIT = 0.15 FIT

8. Worked Example – EPS Hardware FMEA (Excerpt)

Consider the following simplified FMEA excerpt for an EPS power stage MOSFET (Q1 – high-side FET in the H-bridge motor driver):

Failure Mode	λ (FIT)	System Effect	Safety Goal Impact	Safety Mechanism	DC	Classification
Q1 Short Drain-Source	8	Continuous current to motor phase A; unintended torque	SG-01 violation (ASIL D)	Motor current monitoring via shunt + safety relay disconnect	99%	MPF_D (7.92 FIT); Residual (0.08 FIT)
Q1 Open Drain-Source	12	Loss of current to motor phase A; loss of assist torque	SG-02 violation (ASIL C)	Phase current feedback monitoring; deviation > threshold in 5 ms	95%	MPF_D (11.4 FIT); Residual (0.6 FIT)
Q1 Gate-Source Short	5	FET always ON; continuous current; potential unintended torque	SG-01 violation (ASIL D)	Gate driver VGS monitoring + safety relay	99%	MPF_D (4.95 FIT); Residual (0.05 FIT)
Q1 Degraded RDS(on)	3	Reduced efficiency; overheating over time	No direct safety goal violation	Temperature monitoring	–	Safe fault

This FMEA analysis feeds directly into the FMEDA calculations for SPFM, LFM, and PMHF.

9. From FMEA to FMEDA – The Quantitative Extension

FMEDA (Failure Mode, Effects, and Diagnostic Analysis) extends the standard FMEA by adding quantitative failure rate data and diagnostic coverage assessment to calculate the ISO 26262 Part 5 hardware metrics. While FMEA can be qualitative (identifying failure modes and their effects without failure rate numbers), FMEDA is inherently quantitative – it requires component failure rates (in FIT), failure mode distributions (percentage of total λ per failure mode), and diagnostic coverage values (percentage of each failure mode detected by safety mechanisms).

The FMEDA process classifies every failure mode of every component into the ISO 26262 failure categories (safe, single-point, residual, detected multi-point, perceived multi-point, latent multi-point) and sums the failure rates in each category to calculate SPFM (Single Point Fault Metric), LFM (Latent Fault Metric), and PMHF (Probabilistic Metric for random Hardware Failures). A detailed FMEDA worked example with actual metric calculations is provided in our Part 5 – Hardware Development article.

10. FTA Explained – Fault Tree Analysis

FTA (Fault Tree Analysis) is a systematic, deductive (top-down) analysis technique that starts from an undesired top-level event – typically a safety goal violation – and systematically decomposes it into lower-level events using logical gates (AND, OR) until the root causes (basic events, typically individual hardware faults or software errors) are identified. The result is a graphical tree structure – the fault tree – that shows all the causal paths from basic events to the top event.

FTA answers the question: “What combinations of failures can cause this safety goal to be violated?” Unlike FMEA, which considers one failure at a time, FTA natively models the interaction of multiple simultaneous failures through AND gates – making it the primary method for identifying and analyzing multi-point faults, common cause failures, and architecture-level vulnerabilities.

11. FTA Symbols – Gates, Events, and Transfers

Symbol	Name	Meaning
Rectangle	Intermediate Event	An event that results from the combination of lower-level events through a gate
Circle	Basic Event	A root cause event (component failure) with a known or estimated failure rate
Diamond	Undeveloped Event	An event not further developed (insufficient information or outside scope)
OR Gate	OR Gate	Output event occurs if any one of the input events occurs. Represents single-point failure paths.
AND Gate	AND Gate	Output event occurs only if all input events occur simultaneously. Represents multi-point fault paths (redundancy).
Triangle	Transfer	Continues the tree on another page (for large trees)

12. Step-by-Step FTA Process

Step 1 – Define the top event: The top event is typically the negation of a safety goal. For EPS: “Unintended steering torque is applied” (negation of SG-01).

Step 2 – Identify immediate causes: What immediate system-level conditions can directly cause the top event? For the EPS: “Motor driver applies uncommanded current” OR “Safety relay fails to disconnect.”

Step 3 – Decompose using logic gates: Continue decomposing each intermediate event into lower-level events using OR gates (any single cause is sufficient) and AND gates (multiple causes required simultaneously). At each level, ask: “Is this event caused by any single sub-event (OR) or only by a combination of sub-events (AND)?”

Step 4 – Continue until basic events are reached: Decompose until each branch terminates at a basic event – an individual component failure or external event with a known failure rate.

Step 5 – Qualitative analysis (minimal cut sets): Identify the minimal cut sets – the smallest combinations of basic events that are sufficient to cause the top event. Single-event cut sets represent single-point failures. Two-event (or higher) cut sets represent multi-point failure paths.

Step 6 – Quantitative analysis (if required): Assign failure probabilities to each basic event and calculate the top event probability using Boolean algebra. For OR gates: P(output) ≈ P(A) + P(B). For AND gates: P(output) = P(A) × P(B). This enables calculation of the PMHF contribution.

13. Worked Example – EPS Fault Tree (Simplified)

For the top event “Unintended steering torque applied” (SG-01 violation), a simplified fault tree structure would be:

Top Event: Unintended steering torque applied [OR gate]

    Branch 1: Primary MCU commands unintended torque AND safety monitoring fails to detect [AND gate]

        Sub-event 1a: Primary MCU software error (systematic fault)

        Sub-event 1b: Secondary MCU monitoring fails to detect [OR gate]

            Sub-event 1b-i: Secondary MCU hardware failure (random failure, λ = 20 FIT)

            Sub-event 1b-ii: SPI cross-check communication failure (λ = 5 FIT)

    Branch 2: Motor driver hardware fault causes unintended current AND safety relay fails to disconnect [AND gate]

        Sub-event 2a: MOSFET gate-source short (Q1, λ = 5 FIT)

        Sub-event 2b: Safety relay K1 stuck closed (λ = 2 FIT)

    Branch 3: Common cause failure disables both primary and monitoring paths simultaneously (CCF)

This tree reveals that single-point failures are mitigated by the dual-MCU architecture (AND gates), but that common cause failures (Branch 3) remain a concern – leading to the requirement for DFA (Part 9) to evaluate and mitigate dependent failure risks.

14. Qualitative FTA – Minimal Cut Sets and Common Cause

The primary output of qualitative FTA is the identification of minimal cut sets (MCS). A minimal cut set is the smallest set of basic events whose simultaneous occurrence is sufficient to cause the top event. From the EPS example above, the minimal cut sets would be: {MCU software error, Secondary MCU failure}, {MCU software error, SPI cross-check failure}, {MOSFET gate-source short, Safety relay stuck}, and {Common cause failure}. Single-event cut sets (if any exist) are single-point failures and indicate inadequate architecture – they should be eliminated by design. Two-event cut sets represent dual-point failures where both events must occur simultaneously. The CCF cut set is particularly important because it represents a scenario where a single root cause (shared voltage supply failure, EMC event, temperature exceedance) defeats multiple redundancy layers.

15. Quantitative FTA – Calculating Top Event Probability

Quantitative FTA assigns failure probabilities (derived from failure rates) to each basic event and calculates the probability of the top event. For ISO 26262, this calculation contributes to the PMHF evaluation. Using the EPS example Branch 2: P(top event via Branch 2) = P(MOSFET short) × P(relay stuck) = (5 × 10⁻⁹/h) × (2 × 10⁻⁹/h) × T_lifetime. For dual-point faults with one latent failure, the calculation includes the diagnostic test interval (T_MPFD_L from Part 5), making the actual contribution dependent on how frequently the latent fault is tested. The total PMHF is the sum of contributions from all cut sets.

16. FMEA vs FTA – The Master Comparison Table

Aspect	FMEA	FTA
Direction	Bottom-up (inductive)	Top-down (deductive)
Starting point	Individual component failure modes	Top-level undesired event (safety goal violation)
Core question	“What happens if this component fails?”	“What causes this safety goal to be violated?”
Single-point failures	Excellent – primary strength	Identified as single-event minimal cut sets
Multi-point failures	Limited – assumes one failure at a time	Excellent – natively models via AND gates
Common cause failures	Not natively addressed	Can be modeled as basic events affecting multiple branches
Output format	Tabular worksheet (spreadsheet)	Graphical tree diagram
Qualitative use	Identifying failure modes and effects	Identifying minimal cut sets and failure paths
Quantitative use	Via FMEDA – calculating SPFM, LFM, PMHF	Calculating top event probability, supporting PMHF
Architecture design required?	Yes – needs component-level design	Can start with functional architecture (no detailed design)
Standard references	AIAG/VDA FMEA Handbook; SAE J1739; IEC 60812	IEC 61025; ISO 26262 Part 4 Annex, Part 5 Annex
Best for	Comprehensive component-level analysis; hardware metrics	Architecture-level verification; multi-point fault analysis; DFA support

17. How FMEA and FTA Complement Each Other

FMEA and FTA are not competing methods – they are complementary, and ISO 26262 recommends using both. FMEA provides the comprehensive component-level failure mode inventory that ensures no individual failure is overlooked. Its output (failure modes, effects, safety mechanisms, diagnostic coverage) feeds directly into the FMEDA calculations. FTA provides the architectural-level verification that ensures the safety concept is structurally sound – that no single failure path bypasses the safety mechanisms, and that multi-point failure combinations are adequately addressed by redundancy.

The practical workflow typically proceeds as follows: first, the FTA is constructed from the safety goals (top-down) to verify the safety architecture and identify the required detection mechanisms. Then, the FMEA/FMEDA is performed on the detailed hardware design (bottom-up) to verify that every component failure mode is either safe, detected, or adequately mitigated. The basic events at the bottom of the FTA correspond to the failure modes in the FMEA. The FMEDA provides the quantitative data (failure rates, diagnostic coverage) that enables quantitative FTA. Together, they provide complete coverage: FTA ensures no failure path is missed, FMEA ensures no failure mode is missed.

18. Connection to Dependent Failure Analysis (DFA)

Dependent Failure Analysis (DFA) uses FMEA and FTA as its primary inputs. DFA identifies failures that can defeat redundancy – including Common Cause Failures (CCF), Cascading Failures, and violations of Freedom from Interference (FFI). FTA is particularly valuable for DFA because the AND gates in the fault tree represent the redundancy points – the DFA analyst examines each AND gate to determine whether a common cause could simultaneously trigger all input events, effectively converting the AND gate into an OR gate and eliminating the intended redundancy. FMEA contributes to DFA by identifying coupling factors – shared components, shared power supplies, shared environmental conditions – that could cause dependent failures between elements assumed to be independent.

19. Industry Tools for FMEA and FTA

APIS IQ-Software: One of the most widely used tools in automotive, combining FMEA, FTA, FMEDA, and DFA in an integrated environment with bidirectional traceability between failure modes and fault tree events.

Medini Analyze (Ansys): A comprehensive model-based safety analysis tool supporting system FMEA, hardware FMEA/FMEDA, FTA (qualitative and quantitative), DFA, and hardware metric calculations integrated with the system architecture.

Isograph Reliability Workbench: Supports FTA, FMEA, and Markov analysis with automated minimal cut set generation and quantitative calculations.

Siemens Polarion / Cameo Safety Analyzer: Model-based safety analysis integrated with requirements management and system engineering tools.

Microsoft Excel: Still widely used for smaller-scope FMEAs, though it lacks automated traceability and integration with FTA. Excel-based FMEA templates following the AIAG/VDA format are common in the industry.

exida SILcal: Specialized for FMEDA with built-in failure rate databases and hardware metric calculation, widely used for IEC 61508 and ISO 26262 quantitative analysis.

20. Common Mistakes and How to Avoid Them

Mistake 1: Using FMEA alone without FTA. FMEA only considers single failures at a time. Without FTA, multi-point failure combinations and common cause failure paths may be missed. Always use both methods.

Mistake 2: Constructing the FTA from the design rather than from the safety goals. The top event of the FTA must be a safety goal violation — not a hardware failure. Start top-down from the safety goal, not bottom-up from the schematic.

Mistake 3: Using unrealistic failure rates in FMEDA. Using overly optimistic component failure rates produces artificially high metrics that do not reflect the real-world safety performance. Use credible failure rate sources (SN 29500, IEC TR 62380, FIDES, or manufacturer data with validation).

Mistake 4: Overlooking failure modes. Common omissions include intermittent faults, drift faults, timing-related failures, and failure modes of passive components (resistors, capacitors, connectors). A systematic approach using standardized failure mode libraries reduces this risk.

Mistake 5: Not considering the safety mechanism itself as a potential failure source. Safety mechanisms can fail too. The FMEA must include failure modes of the safety mechanism components, and the FTA must include the possibility that the safety mechanism fails to detect or respond.

Mistake 6: Treating FMEA as a one-time activity. The FMEA must be updated whenever the design changes – new components, modified circuits, changed software interfaces, or updated failure rate data all require FMEA revision.

21. Frequently Asked Questions

Q1: Is FMEA mandatory for all ASIL levels?

ISO 26262 Part 4 and Part 5 tables specify that inductive analysis (FMEA) is highly recommended for all ASILs (A through D) at the system and hardware levels. At ASIL D, both FMEA and FTA are highly recommended. In practice, FMEDA is virtually mandatory for any ASIL B or higher system because it is the primary method for calculating the required hardware metrics.

Q2: Can FTA replace FMEA?

No. FTA and FMEA serve different purposes and have different strengths. FTA is better at identifying multi-point failure paths and verifying the architecture. FMEA is better at comprehensive component-level analysis and calculating hardware metrics (via FMEDA). ISO 26262 recommends both.

Q3: What is the difference between FMEA and FMEDA?

FMEA identifies failure modes and their qualitative effects. FMEDA extends FMEA by adding quantitative failure rate data and diagnostic coverage assessment, enabling the calculation of the ISO 26262 Part 5 hardware metrics (SPFM, LFM, PMHF). FMEDA is essentially “FMEA + failure rate numbers + DC assessment + failure classification + metric calculation.”

Q4: How do FMEA and FTA relate to HAZOP?

HAZOP (Hazard and Operability Analysis) is primarily used during the concept phase for hazard identification in the HARA process. FMEA and FTA are used later in the development lifecycle to verify that the safety concept and design adequately address the hazards identified in the HARA. HAZOP identifies what can go wrong at the functional level; FMEA and FTA verify that the design handles it.

Q5: Can software failures be analyzed with FTA?

Yes. Software failure modes can be included as basic events in the fault tree. However, because software failures are systematic (not random), assigning failure probabilities to software events is problematic. Software FTA is typically qualitative – identifying the software failure paths that could contribute to a safety goal violation – rather than quantitative.

22. Conclusion

FMEA and FTA are the foundational safety analysis techniques in ISO 26262. FMEA provides comprehensive, bottom-up, component-level failure analysis that ensures every failure mode is identified, classified, and either detected or mitigated. FTA provides systematic, top-down, architecture-level analysis that ensures every path to a safety goal violation is identified – including multi-point failure combinations that FMEA alone cannot capture. Together with their quantitative extensions (FMEDA for hardware metrics, quantitative FTA for top event probability), they form the analytical backbone that demonstrates whether a design achieves its safety goals with adequate confidence.

This article is part of our comprehensive ISO 26262 series at PiEmbSysTech. For related topics, see Part 5 – Hardware Development (SPFM, LFM, PMHF) and Part 9 – ASIL Decomposition & DFA.

Stay safe. Stay analytical. Keep engineering the future.

– The PiEmbSysTech Team