What is the difference between FMEA and FMEDA?

FMEDA adds diagnostics and numbers. An FMEA is qualitative: it lists failure modes, their effects and the actions to take. An FMEDA assigns a failure rate to each hardware failure mode and credits the diagnostic coverage of each safety mechanism, so it can calculate the single-point fault metric, latent fault metric and PMHF contribution that ISO 26262-5 sets targets for at ASIL B, C and D.

Functional Safety · ISO 26262 · ASIL A–D

Functional Safety Engineering for Systems That Must Fail Safely.

Agnile supports functional safety and system-safety activities for automotive and safety-critical systems, from item definition and HARA through safety goals, functional and technical safety concepts, safety analysis, verification, validation, and safety case preparation.

Schedule a 60-minute call Contact Us

Engineer CredentialsISO 26262 alignedASIL A–D experience

What is ISO 26262 functional safety engineering?

ISO 26262 functional safety engineering is the work of showing that a road vehicle’s electrical and electronic systems avoid unreasonable risk when they malfunction. Hazards are rated in a HARA, each safety goal gets an ASIL from A to D, and the ASIL sets the rigour of the safety concepts, analyses, verification and safety case that follow. Agnile Technologies delivers this for OEMs and Tier-1 suppliers: HARA, functional and technical safety concepts, FMEA, FTA, DFA and FMEDA, safety verification and safety case evidence.

Reviewed by Shreyansh, Founder & CTO, Agnile Technologies • Last reviewed 14 October 2026

Capability areas

How We Engineer Functional Safety

Concept Phase

Item definition, impact analysis, HARA, ASIL determination, safety goals, functional safety concept, and safety planning.

System and Software Safety

Technical safety concept, hardware-software interface, safety requirements allocation, safety mechanisms, monitoring concepts, and diagnostic coverage strategy.

Safety Analysis

FMEDA, FTA, DFA, dependent failure analysis, common-cause considerations, and safety mechanism effectiveness analysis.

Verification, Validation & Safety Case

Safety verification planning, requirements-based testing, safety validation support, confirmation review support, and safety case evidence preparation.

Lifecycle

The ISO 26262 Lifecycle: Parts, Activities and Work Products

ISO 26262:2018, the second edition, has 12 parts. Parts 2 to 9 carry the requirements a programme works through; the table maps each to the activities and the work products an assessor reads. For the full background, read what ISO 26262 is and how it works.

Part	Lifecycle phase	Activities	Work products
Part 2	Management of functional safety	Safety culture and competence, safety planning across the lifecycle, and confirmation measures — confirmation reviews, functional safety audit and functional safety assessment	Safety plan, safety case, confirmation review reports, functional safety audit and assessment reports
Part 3	Concept phase	Item definition (Clause 5), hazard analysis and risk assessment (Clause 6) and the functional safety concept (Clause 7)	Item definition, HARA report with ASILs and safety goals, functional safety concept
Part 4	Product development at the system level	Technical safety concept, system architectural design and its safety analyses, hardware–software interface, system and item integration and testing, safety validation	Technical safety requirements and concept, system architecture, HSI specification, integration test and safety validation reports
Part 5	Product development at the hardware level	Hardware safety requirements, hardware design and safety analyses, evaluation of the hardware architectural metrics and of safety-goal violations due to random hardware failures	Hardware safety requirements specification, FMEDA, SPFM / LFM and PMHF evaluation reports
Part 6	Product development at the software level	Software safety requirements, architectural design, unit design and implementation, unit verification, integration and verification, testing of the embedded software	Software safety requirements, architecture and unit design specifications, verification reports with structural coverage
Part 7	Production, operation, service and decommissioning	Planning so the functional safety achieved in development is maintained in production, field service and decommissioning	Production, operation, service and decommissioning plans and instructions for safety-related items
Part 8	Supporting processes	Interfaces within distributed developments, safety requirements management, configuration and change management, verification, documentation, confidence in the use of software tools (Clause 11), qualification of software components and hardware elements	Development Interface Agreement, tool classification and qualification reports, configuration and change records
Part 9	ASIL-oriented and safety-oriented analyses	ASIL decomposition, criteria for coexistence of elements, analysis of dependent failures, and the inductive and deductive safety analyses used throughout	Decomposition rationale, dependent failure analysis, FMEA and FTA reports
Parts 1, 10, 11, 12	Vocabulary, guideline and adaptations	Part 1 defines the vocabulary; Part 10 is an informative guideline; Part 11 guides application to semiconductors; Part 12 adapts the standard for motorcycles	Referenced as the programme needs them — Part 11 for microcontroller and SoC safety analyses, Part 12 for motorcycle programmes

HARA and ASIL

HARA and ASIL: How Risk Sets the Rigour

A Hazard Analysis and Risk Assessment (HARA), defined in ISO 26262-3, starts from the item definition, combines each malfunctioning behaviour with the operational situations the vehicle meets, and rates every resulting hazardous event on three parameters. The combination maps to ASIL A to D — or to QM, where normal quality management is enough — and each hazardous event with an ASIL receives a safety goal, usually with a safe state and a fault tolerant time interval.

Parameter	Classes	What it rates
Severity	S0–S3	The harm to the people involved, from no injuries (S0) to life-threatening or fatal injuries (S3)
Exposure	E0–E4	How often the operational situation occurs, from incredible (E0) to high probability (E4)
Controllability	C0–C3	Whether the driver or others involved can avoid the harm, from controllable in general (C0) to difficult to control or uncontrollable (C3)

The highest combination — S3, E4, C3 — gives ASIL D. The ASIL then travels with the safety goal into every requirement derived from it and scales what follows: hardware architectural metrics, software methods and structural coverage, and the independence of confirmation measures. ASIL decomposition can split a requirement across redundant, sufficiently independent elements — ASIL D into B(D) + B(D), C(D) + A(D) or D(D) + QM(D) — provided a dependent failure analysis supports the independence claimed.

What the ASIL changes — hardware metric targets (ISO 26262-5) and highly recommended unit-level structural coverage (ISO 26262-6)
ASIL	SPFM	LFM	PMHF	Structural coverage
ASIL A	No target	No target	No target	Statement
ASIL B	≥ 90%	≥ 60%	< 10⁻⁷/h	Statement and branch
ASIL C	≥ 97%	≥ 80%	< 10⁻⁷/h	Branch
ASIL D	≥ 99%	≥ 90%	< 10⁻⁸/h	Branch and MC/DC

For each level in more depth, see ISO 26262 ASIL levels explained; to try the rating yourself, use the interactive HARA worksheet further down this page.

Safety analyses

FMEA, FTA, DFA and FMEDA: Which Analysis Answers Which Question

ISO 26262 does not ask for one analysis; it asks for the right combination at each level. Inductive and deductive analyses find different faults, dependent failure analysis protects every independence claim, and the FMEDA turns hardware design into the numbers the ASIL targets are checked against.

Inductive · bottom-up

FMEA — Failure Mode and Effects Analysis

What is the effect when this component, function or signal fails in a given way?

The inductive safety analysis ISO 26262 expects at every ASIL, at system, hardware and software level. Automotive teams increasingly follow the AIAG & VDA FMEA Handbook, which ranks actions by Action Priority rather than RPN.

Output: Failure modes, effects, existing safety mechanisms and actions

FMEAin the glossary →

Deductive · top-down

FTA — Fault Tree Analysis

Which combinations of faults can violate this safety goal?

The deductive safety analysis, increasingly recommended as the ASIL rises and highly recommended at ASIL C and D. Quantified, it supports the evaluation of random hardware failures.

Output: Fault tree, minimal cut sets, single-point and multiple-point faults

FTAin the glossary →

Systematic · shared causes

DFA — Dependent Failure Analysis

Can one cause defeat elements that are meant to be independent or free from interference?

ISO 26262-9 analysis of dependent failures — needed wherever ASIL decomposition, redundancy or coexistence of elements relies on independence or freedom from interference.

Output: Common-cause and cascading failure initiators — shared power, clock, memory, software partitions, environment — with the measures that address them

Quantitative · hardware

FMEDA — Failure Modes, Effects and Diagnostic Analysis

Is diagnostic coverage high enough to meet the ASIL's hardware metric targets?

The usual way to evaluate the ISO 26262-5 hardware architectural metrics and random-hardware-failure targets for ASIL B, C and D safety goals.

Output: Failure rates per failure mode, diagnostic coverage, SPFM, LFM and PMHF contribution

FMEDAin the glossary →

Safety × cybersecurity

Where Safety and Cybersecurity Must Align

Where safety and cybersecurity interact — BMS, braking, EPS, ADAS, gateways, and connected ECUs — Agnile helps teams build one coherent engineering evidence chain. ISO 26262-2 calls for communication between functional safety and cybersecurity, and ISO/SAE 21434 expects the same from the other side: an attack that can trigger a hazardous event inherits the severity the HARA already assigned, and a safety mechanism an attacker can switch off no longer supports its safety goal.

One item definition. Joint HARA–TARA workshops fix the item boundary, operating environment and external interfaces once, so both analyses build on the same model.
Goals that reference each other. Safety goals with their ASIL and cybersecurity goals are derived from a shared set of hazardous events and damage scenarios, with dependencies marked where one protects the other.
Mechanisms that do different jobs. End-to-end protection detects corrupted, lost or delayed messages caused by faults; it is not designed to resist deliberate manipulation, which is what SecOC message authentication and secure boot add. Where both apply, they are allocated together at the hardware–software interface.
One evidence trail. Verification covers safety and security test cases together, and the safety case and cybersecurity case cite each other instead of contradicting each other at assessment.

See the worked scenario safety and cybersecurity co-engineering for an ADAS feature, and our automotive cybersecurity and ISO/SAE 21434 consulting services.

Process

How an ISO 26262 Engagement Runs — Six Steps

The same six steps follow the ISO 26262 lifecycle on every programme. Durations are typical for one item; a complete item-to-ASIL programme runs 12–16 weeks, and ASIL-compliant software development follows your release plan.

Scoping, item boundary and safety plan Week 1
Agree the item, its boundary, the highest ASIL expected, the lifecycle phase and the confirmation measures the evidence is for. Where development is distributed, a Development Interface Agreement (ISO 26262-8) fixes which work products each party owns.
Item definition and HARA 2–4 weeks
Item definition (Part 3, Clause 5) and HARA (Clause 6): facilitated workshops — typically two to five days — rate Severity, Exposure and Controllability, assign ASILs and derive safety goals with safe states and fault tolerant time intervals.
Functional and technical safety concepts About 4 weeks
Functional safety concept (Part 3, Clause 7) allocating functional safety requirements to the architecture, then the technical safety concept (Part 4) with safety mechanisms, ASIL decomposition where it pays off, and the hardware–software interface.
Safety analyses and hardware metrics About 5 weeks, with the HSI
FMEA and FTA at system, hardware and software level, dependent failure analysis for every independence claim, and FMEDA to evaluate SPFM, LFM and PMHF against the ISO 26262-5 targets for the ASIL.
Verification, safety validation and safety case About 4 weeks
Requirements-based and fault-injection testing, integration and safety validation evidence (Part 4), and the safety case — the argument, supported by work products, that functional safety is achieved for the item (Part 2).
Confirmation measures support 2–3 weeks for an independent review
Preparation for confirmation reviews, the functional safety audit and the functional safety assessment, with independence scaled to the ASIL. We pressure-test the evidence first; the assessor's judgement stays with the assessor.

Test execution — model-, software- and hardware-in-the-loop, fault injection and requirements-based testing — runs through our verification and validation practice, so safety evidence and test evidence share one traceability chain.

Engagement models

How we engage on Functional Safety programmes.

A complete item-to-ASIL programme, a focused concept-phase acceleration, or an independent Safety Case review. We scope the actual work on the call.

FS-01·12–16 weeks
Item-to-ASIL Programme
ISO 26262 lifecycle support for one item — Item Definition through Functional Safety Validation. HARA workshops, Functional / Technical / Hardware-Software Safety Concepts, FMEDA on production silicon, and the Safety Case ready for concept review and series.
Engagement flow
Item Definition + HARA
3w
FSC + TSC
4w
HSI + FMEDA
5w
Safety Validation + Case
4w
Deliverables
HARA report (ASIL determination)
Safety Concept set (FSC + TSC + HSI)
FMEDA + DFA on production silicon
Safety Case (item-level)
FS-02·6–10 weeks
Concept Phase Acceleration
Item Definition workshop, Hazard Analysis, ASIL determination, Functional Safety Concept and Technical Safety Concept — delivered as a focused engagement to unblock concept-phase reviews. Useful when the programme is downstream of system definition but ahead of HW/SW partitioning.
Engagement flow
Item Definition
2w
HARA
2w
FSC + TSC
4w
Deliverables
Item Definition (ISO 26262-3 Clause 5)
HARA report with ASIL ratings
FSC + TSC ready for concept review
FS-03·2–3 weeks
Safety Case Review
Independent assessment of an existing Safety Case — methodology pressure-test, traceability audit, gap identification against the ISO 26262 Part 2 safety-case requirements and the Part 3–6 work products it cites. Useful before a third-party assessment or when inheriting a Safety Case from a previous supplier.
Engagement flow
Document Review
1w
Workshop + Q&A
0.5w
Assessment Write-up
0.5w
Deliverables
Independent Safety Case assessment
Prioritised gap list
Remediation plan with effort estimates

Practicalities

Engagement Practicalities

The questions programme managers, safety managers and procurement ask before the scoping call, answered up front.

Delivery model	Workshops on-site or remote; analysis, documentation and reviews delivered from Bengaluru
Working window	India is 4.5 hours ahead of CET and 3.5 hours ahead of CEST, so every European morning is a shared working window
Inputs we need	System description or architecture, any existing item definition and requirements, hardware design data and failure-rate sources for the FMEDA, and your work-product templates
Tooling	Your templates and tools, so the evidence stays in your structure and traces from safety goal to test
Quality and data handling	Under Agnile's ISO 9001:2015 and ISO/IEC 27001:2022 management systems (Certificate Nos. 25110401 and 25110402)
Language	Deliverables, workshops and reviews in English
Typical durations	Concept-phase engagement 6–10 weeks; item-to-ASIL programme 12–16 weeks; independent safety case review 2–3 weeks; organisation-wide process deployment 3–6 months
Cost drivers	Number of items and safety goals, highest ASIL, lifecycle phase, maturity of existing work products, hardware complexity and failure-rate data, software scope, distributed-development interfaces and the assessment date — fixed price after scoping
Deliverables	Item definition, HARA, functional and technical safety concepts, FMEA / FTA / DFA / FMEDA reports, verification and validation evidence, and the safety case

Why Agnile

What We Do Differently

01
Engagements are led by certified functional safety specialists with production-programme and audit experience.
02
FMEDA on production silicon. We work with the actual hardware metrics from your AURIX, RH850, or S32G — measured numbers, not approximations.
03
Joint HARA-TARA workshops where Functional Safety and Cybersecurity meet. The same engineering team handles both — one continuous safety-and-security argument.
04
ASIL D programmes carried through to series. We have closed Safety Cases on powertrain, BMS, EPS, and braking systems on production vehicles.
05
Methodology that survives audit. Every safety claim traces to its evidence — designed to hold up at concept review, FSC review, and final ISO 26262 assessment.

Standards depth

Standards we work to.

The ISO 26262 parts we work in, and what each looks like on a programme.

ISO 26262 Part 3
Concept phase — Item Definition + HARA
We facilitate Item Definition workshops (Clause 5), run the HARA (Clause 6) to rate Severity, Exposure and Controllability and derive Safety Goals with their ASIL, and draft Functional Safety Concepts (Clause 7) traceable to the Item Definition.
ISO 26262 Part 4
System-level development
Technical Safety Concept derived from the FSC, system architectural design with safety mechanisms allocated to hardware and software, the hardware–software interface (HSI) specification, and integration-test and safety-validation planning. Any ASIL decomposition is recorded with the independence argument Part 9 requires.
ISO 26262 Part 5
Hardware development — FMEDA
FMEDA on production silicon — SPFM ≥ 99% at ASIL D, LFM ≥ 90% at ASIL D, PMHF < 10⁻⁸/h target. Failure-mode catalogue with safety mechanisms credited per Annex D.
ISO 26262 Part 6
Software development
Software requirements, architecture, unit design, implementation, and unit-level + integration-level test — with structural coverage tuned to the ASIL (statement coverage highly recommended at A and B, branch coverage from B, MC/DC at D).
ISO 26262 Part 9
ASIL-oriented + safety-oriented analyses
ASIL decomposition (D → B(D)+B(D), D → C(D)+A(D), D → D(D)+QM(D)). Dependent Failure Analysis to show the independence a decomposition claims, and freedom-from-interference arguments for shared resources such as memory, timing and communication.
ISO 21448 (SOTIF)
Safety of the Intended Functionality
For ADAS / automated-driving features, we extend ISO 26262 functional safety with ISO 21448:2022 SOTIF analysis — functional insufficiencies and triggering conditions, evaluation of known hazardous scenarios (Clause 10) and of residual risk from unknown ones (Clause 11).

Interactive — HARA worksheet

Pick S, E, C — see the ASIL

ISO 26262-3:2018 Annex B in three sliders. Move severity, exposure, and controllability — the ASIL output and decomposition options update live, per ISO 26262-9 Clause 5.

Severity (S)

Potential consequence of the hazardous event

Life-threatening (survival uncertain) to fatal

Exposure (E)

Probability of the operational situation

High probability — > 10%, common driving

Controllability (C)

Ability of driver to avoid the harm

Difficult to control or uncontrollable

Source — ISO 26262-3:2018 Annex B Table B.1 · Decomposition per ISO 26262-9:2018 Cl.5

ASIL output

ASIL D

ASIL D. Highest rigour. SPFM ≥ 99%, LFM ≥ 90%, PMHF ≤ 10⁻⁸/h target. Mandatory independence. Often requires architectural decomposition.

Decomposition options

ASIL D(D)+ASIL QM(D)
ASIL C(D)+ASIL A(D)
ASIL B(D)+ASIL B(D)
Each option preserves the original ASIL on the item; the channel allocations require demonstrated freedom from interference per Part 9 Annex E.

S3 · E4 · C3 → D

Case study

What This Looks Like in Practice

Anonymised by request. References available on qualified enquiry.

Anonymised engagement summary. Customer identity and programme details withheld under NDA. Metrics reflect internally documented delivery outcomes.

Indian BMS programme · Connected mobility

HARA + ASIL decomposition for an ASIL D battery management system.

Context

An Indian engineering team developing a high-voltage Battery Management System for a connected-mobility vehicle programme had inherited a HARA with ASIL D ratings on every safety goal — driving development cost beyond budget. The team needed independent re-rating with defensible decomposition before the programme's Functional Safety Concept review.

Approach

Agnile ran fresh HARA workshops on the BMS item definition, decomposed top-level safety goals via ASIL B(D) + ASIL B(D) where defensible, validated the decomposition with FTA, and produced the FSC + TSC ready for review. Five weeks, three workshops, full traceability.

What we delivered

Re-rated HARA with decomposed ASIL ratings
FTA validation of decomposition independence
FSC + TSC + HSI for cell + pack levels
Safety Case structure populated through clause 6

What the customer got

Passed FSC review on first submission
Safety goals decomposed to ASIL B(D) + ASIL B(D) where independence could be shown

ASIL D → B(D)+B(D) · 5 weeks · cell + pack

FAQ

ISO 26262 Functional Safety — Questions

ASIL, the Automotive Safety Integrity Level, is ISO 26262's four-level scale — A, the lowest, to D, the highest — for how much rigour a safety requirement needs. It is assigned to each hazardous event in the HARA from its Severity, Exposure and Controllability ratings, inherited by the safety goal, and scales hardware metric targets, software methods and confirmation measures. Hazardous events needing no ISO 26262 measures are rated QM.

A Hazard Analysis and Risk Assessment is the ISO 26262-3 analysis that identifies hazardous events — a malfunctioning behaviour of the item in a specific operational situation — and rates each for Severity (S0–S3), Exposure (E0–E4) and Controllability (C0–C3). The result is an ASIL per hazardous event and a safety goal for each one rated A to D: the top-level requirement everything downstream traces to.

Direction. FMEA works bottom-up: it starts from each failure mode of a component or function and asks what effect it has. FTA works top-down: it starts from a hazardous event or safety-goal violation and decomposes it into the combinations of faults that can cause it. ISO 26262 uses both — inductive analysis such as FMEA at every ASIL, deductive analysis such as FTA increasingly as the ASIL rises — because each catches what the other misses.

Dependent failure analysis looks for single causes that can defeat elements meant to be independent: common-cause failures, such as a shared power supply, clock or memory, and cascading failures, where one element's fault propagates into another. ISO 26262-9 uses it to support ASIL decomposition, redundancy and freedom-from-interference claims; without it, an independence argument is an assertion rather than evidence.

ISO 26262:2018, the second edition, has 12 parts: vocabulary (Part 1), management of functional safety (2), concept phase (3), system, hardware and software development (4 to 6), production, operation, service and decommissioning (7), supporting processes (8), ASIL-oriented and safety-oriented analyses (9), an informative guideline (10), application to semiconductors (11) and adaptation for motorcycles (12).

It depends on scope, so we quote a fixed price after a scoping call. The main cost drivers are the number of items and safety goals, the highest ASIL, the lifecycle phase, how complete your existing work products are, hardware complexity and failure-rate data for the FMEDA, software scope, distributed-development interfaces, and how close the confirmation review or functional safety assessment is.

Typically six to ten weeks for a concept-phase engagement — item definition, HARA, functional and technical safety concepts — and twelve to sixteen weeks for one item from item definition through safety validation and the safety case. An independent review of an existing safety case takes two to three weeks, HARA workshops two to five days, and an organisation-wide process deployment three to six months.

They share the item and its interfaces, so we engineer them together. Joint HARA–TARA workshops fix one item definition; an attack that can trigger a hazardous event inherits the severity the HARA assigned; and safety mechanisms are checked against attacks that could disable them. ISO 26262-2 calls for communication with cybersecurity and ISO/SAE 21434 mirrors it, so the safety case and cybersecurity case cite rather than contradict each other.

Confirmation measures are the ISO 26262-2 checks that the safety work is complete and sound: confirmation reviews of key work products such as the HARA, safety plan and safety case; a functional safety audit of the process; and a functional safety assessment of the item. The required independence rises with the ASIL. We prepare and pressure-test the evidence; the assessor's judgement stays with the assessor.

ISO 21448, published in 2022, covers the safety of the intended functionality: hazards caused by functional insufficiencies — a sensor or perception limitation, for example — rather than by faults. It complements ISO 26262 on ADAS and automated-driving features by identifying triggering conditions, reducing the risk from known hazardous scenarios and arguing that residual risk from unknown ones is acceptably low.

Explore next

Go deeper on ISO 26262

Guides to the standard and its terms, safety–security co-engineering, and the verification and test services that produce the evidence.

Functional Safety Guides

Safety and Cybersecurity

Related Engineering

Request a Discussion

A 60-minute call: scope your HARA, review your existing Safety Concept, or pressure-test your FMEDA before a Confirmation Review. We respond to qualified enquiries within one business day.