AIAG & VDA FMEA: Design FMEA

This section shows how to use the Derisker AIAG & VDA FMEA library to build a Design FMEA (DFMEA) model in SysML v2. Derisker parses these models to extract failure modes, propagate inherited ratings, compute Action Priority (AP), and present results in an interactive table view.

The library implements the AIAG & VDA FMEA Handbook (1st Edition 2019, 2nd Printing 2022) 7-step process for DFMEA. For a full type reference see AIAG & VDA FMEA. For a complete worked example see Electric Vehicle DFMEA.

The 7-Step Process

The DFMEA follows three phases:

Phase 1 — System Analysis (Steps 1–3): Define scope, structure, and functions.
Phase 2 — Failure Analysis & Risk Mitigation (Steps 4–6): Identify failures, assess risk, and define optimization actions.
Phase 3 — Risk Communication (Step 7): Document and share results.

DFMEA Workflow

Step 1 — Planning & Preparation: Create the Analysis Case

Every DFMEA starts with an analysis usage that specializes FMEA_Design. It needs a header (project metadata) and a subject pointing to the top-level system part definition being analysed. Import the library into your file first.

private import Derisker_AIAG_VDA_FMEA::DFMEA::*;

analysis myDFMEA : FMEA_Design {
    doc /* DFMEA for the XYZ System. */

    subject mySystem : LVL0::MySystemDef;   // points to top-level system part def

    part redefines header {
        attribute :>> companyName          = "Company Name";
        attribute :>> engineeringLocation  = "Engineering Site";
        attribute :>> customerName         = "Customer Name";
        attribute :>> modelYearOrPrograms  = "2027";
        attribute :>> subjectName          = "XYZ System";
        attribute :>> fmeaStartDate        = "2026-03-01";
        attribute :>> fmeaRevisionDate     = "2026-03-01";
        attribute :>> crossFunctionalTeam  = "Lead Engineer, Safety Engineer, Test Engineer";
        attribute :>> fmeaID               = "DFMEA-001";
        attribute :>> designResponsibility = "System Engineering";
        attribute :>> confidentialityLevel = Confidentiality::proprietary;
    }
}

Step 2 — Structure Analysis: Define the System Hierarchy

The subject points to a part hierarchy: System (LVL0) → Subsystems (LVL1) → Components (LVL2). The hierarchy can extend to additional levels. There is no base type requirement — use any part def structure that fits your project. The example uses a Defs::SystemType helper, but this is project-specific convenience.

package <LVL0> LVL0_System {
    part def <EV> ElectricVehicle {
        part batterySystem : LVL1::BatterySystem;
        part powertrain    : LVL1::Powertrain;
        part chassis       : LVL1::Chassis;
        // ... more LVL1 subsystems
    }
}

package <LVL1> LVL1_Subsystems {
    part def <Powertrain> Powertrain {
        part inverter     : LVL2::Inverter;
        part electricMotor : LVL2::ElectricMotor;
        part reducer      : LVL2::Reducer;
    }

    part def <BatterySystem> BatterySystem {
        part batteryPack  : LVL2::BatteryPack;
        part bms          : LVL2::BMS;
        part hvCabling    : LVL2::HVCabling;
    }
}

Step 3 — Function Analysis: Define Functions for Parts

Each part definition owns one or more functions declared as action usages. Every function used in the DFMEA chain must specialize Function_AIAG_VDA_FMEA — this enables failure mode collection (FMs) and P-diagram support. You can specialize it directly or via a project-level intermediate action def.

// Direct specialization
part def ElectricVehicle {
    action generateTractiveForce : Function_AIAG_VDA_FMEA {
        doc /* Convert stored electrical energy into tractive force at the wheels. */

        // Lower-level functions cross-reference subsystem functions
        perform action propelVehicle      references powertrain.propelVehicle;
        perform action supplyTractionEnergy references batterySystem.supplyTractionEnergy;

        // Failure modes are declared here (Step 4)
    }
}

// OR via an intermediate action def (project convenience)
action def Function specializes Function_AIAG_VDA_FMEA {
    action lowerLevelFunctions : Function [*] default null;
}

Step 3 (cont.) — Add a P-Diagram

The optional @Pdiagram metadata annotates critical or safety-relevant functions to document their parameter diagram — control factors, noise factors, and unintended outputs.

action generateTractiveForce : Function_AIAG_VDA_FMEA {

    @Pdiagram {
        controlFactors    = "Battery voltage/capacity; inverter current limit; motor torque curve";
        unintendedOutput  = "EMI from inverter; drivetrain NVH; excess heat to coolant";
        noiseFactors {
            pieceToPieceVariation = "Cell capacity spread; motor magnet flux tolerance";
            changeOverTime        = "Battery capacity fade; bearing wear; solder fatigue";
            customerUsage         = "Sustained high-speed driving; towing near rated payload";
            externalEnvironment   = "Temperature extremes; road salt/moisture ingress";
            systemInteractions    = "Battery voltage sag at peak load; 12 V supply droop";
        }
    }

    // Failure modes follow (Step 4)
}

Step 4 — Failure Analysis: Add Failure Modes

Failure modes are declared inside the function they apply to using the #failureMode keyword. Each function can have multiple failure modes. Use descriptive, domain-specific names (e.g. noACOutput, not lossOfDCtoACConversion).

Placeholder (minimal — for building the chain first):

action convertDCtoAC : Function_AIAG_VDA_FMEA {
    #failureMode <FM1> noACOutput;
    #failureMode <FM2> reducedACOutput;
}

Placeholders auto-collect into the function’s FMs — no subsets FMs needed. Add a body with at least FEs once the failure chain is ready (see Pattern B below).

Fully detailed failure mode (with effects, controls, ratings, and optimization):

#failureMode <FM1> noACOutput {
    doc /* IGBT module failure stops all AC output; zero motor drive. */
    attribute :>> failureModeType = FMType::lossOfFunction;

    // Step 4 — Failure Effects: which higher-level FM does this feed into?
    ref occurrence :>> FEs = LVL0::EV::powertrain.propelVehicle.powertrainInoperative;

    // Step 5 — Risk Analysis
    attribute :>> preventionControls   = "IGBT desat detection; DC-link fuse coordination";
    attribute :>> detectionControls = "Phase-current check at EOL; HIL fault injection";

    // Leaf FM — set O and D directly; S inherited from higher-level effect
    attribute :>> S = InheritSeverityRating(FEs.S.value);
    attribute :>> O = OR::O4_Moderate;
    attribute :>> D = DR::D4_High;
    // AP is auto-calculated from S, O, D — do NOT set manually

    // Step 6 — Optimization
    attribute :>> preventiveAction       = "Add pre-drive inverter health check";
    attribute :>> detectionAction        = "Implement torque-zero fault DTC logging";
    attribute :>> reponsiblePersonName   = "Powertrain Integration Lead";
    attribute :>> targetDate             = "2026-Q3";
    attribute :>> status                 = Status::open;
    attribute :>> actionTaken            = "";
    attribute :>> actionTakenEvidence    = "";
    attribute :>> completionDate         = "";
    attribute :>> remarks                = "";
}

Failure Mode Naming

Name failure modes by how the function fails, not by repeating the type prefix:

Failure Type	Generic (avoid)	Domain-Specific (preferred)
Loss of function	`lossOfDCtoACConversion`	`noACOutput`
Degraded function	`degradedTorqueGeneration`	`reducedTorqueCapacity`
Loss of function	`lossOfSpeedReduction`	`gearboxJam`
Degraded function	`degradedCurrentConduction`	`highResistanceConnection`
Loss of function	`lossOfCellBalancing`	`cellVoltageDivergence`

Step 4 (cont.) — Create Causation Links Between Levels

Use #failureCause inside a higher-level failure mode to link it to the lower-level FM that causes it. This builds the failure chain: LVL0 FM ← LVL1 FM ← LVL2 FM.

Each cause connection carries its own prevention/detection control descriptions.

#failureMode <FM1> powertrainInoperative {
    doc /* Complete inability to produce mechanical torque. */
    attribute :>> failureModeType = FMType::lossOfFunction;

    // Step 4 — Failure Effects (link upward)
    ref occurrence :>> FEs = LVL0::EV::generateTractiveForce.inabilityToGenerateTractiveForce;

    // Step 5 — Risk Analysis
    attribute :>> preventionControls    = "ASIL-D inverter safe-state; dual-resolver sensing";
    attribute :>> detectionControls = "EDU torque verification on dynamometer";

    // Non-leaf FM: inherit O, D from causes below
    attribute :>> S = InheritSeverityRating(FEs.S.value);
    attribute :>> O = InheritOccurrenceRating(FCs.O.value);
    attribute :>> D = InheritDetectionRating(FCs.D.value);

    // Causation links to lower-level FMs (link downward)
    #failureCause <FC1> inverterNoACOutput {
        doc /* IGBT failure stops AC output to motor. */
        end [1] occurrence :>> FC references convertDCtoAC.noACOutput;
        end [1] occurrence :>> FM references FM1;
        attribute :>> currentPreventionControls = "IGBT desat detection with <5 us shutdown";
        attribute :>> currentDetectionControls  = "Phase-current check at EOL";
        attribute :>> confirmationOfPCandDC     = "";
    }
    #failureCause <FC2> motorNoTorque {
        doc /* Winding open-circuit or rotor seizure. */
        end [1] occurrence :>> FC references generateTorque.noTorqueOutput;
        end [1] occurrence :>> FM references FM1;
        attribute :>> currentPreventionControls = "Winding insulation class H; bearing pre-load spec";
        attribute :>> currentDetectionControls  = "Phase impedance at EOL; vibration analysis";
        attribute :>> confirmationOfPCandDC     = "";
    }

    // Step 6 — Optimization (on the FM, not on each cause)
    attribute :>> preventiveAction     = "";
    attribute :>> detectionAction      = "";
    attribute :>> reponsiblePersonName = "";
    attribute :>> targetDate           = "";
    attribute :>> status               = Status::open;
    attribute :>> actionTaken          = "";
    attribute :>> actionTakenEvidence  = "";
    attribute :>> completionDate       = "";
    attribute :>> remarks              = "";
}

``end`` reference syntax:

Syntax	Meaning
`end [1] occurrence :>> FC references <path.to.lower.fm>;`	Cause end — points to the lower-level FM
`end [1] occurrence :>> FM references <enclosing-fm-name>;`	Effect end — points back to the enclosing FM

Step 5 — Risk Analysis

Step 5 is integrated into the failure mode body above (preventionControls — control methods that reduce occurrence — detectionControls, S, O, D). Refer to the rating tables in AIAG & VDA FMEA for full S, O, D criteria.

Step 6 — Optimization

Step 6 fields (preventiveAction, detectionAction, reponsiblePersonName, targetDate, status, actionTaken, actionTakenEvidence, completionDate) are declared on the failure mode, not on individual causes. When a completed action changes the O or D at the leaf level, update the actual rating directly on the leaf FM; inheritance propagates the change upward automatically.

Status Value	Meaning
`Status::open`	No action defined yet
`Status::decisionPending`	Action proposed; decision not yet made
`Status::implementationPending`	Action approved; not yet implemented
`Status::completed`	Action implemented and verified
`Status::notImplemented`	Action explicitly decided against

Step 7 — Results Documentation: Parse with Derisker

Open the Derisker panel (click  in left sidebar)

Enter the top-level package name, e.g.

AIAG_VDA_FMEA_Example_DFMEA_ElectricVeh

Click Parse AIAG & VDA FMEA.

Derisker validates the model, propagates inherited ratings, computes Action Priority for every failure mode, and opens the table view. For details on the table view, failure chain visualization, and export, see AIAG & VDA FMEA.

Modelling Patterns

Pattern A — Full Failure Mode

Use for LVL0 and any level where the failure chain continues downward and risk data is available. Include failure causes, controls, ratings, and optimization fields.

#failureMode <FM1> noOutput {
    doc /* <Enter description of the failure mode, i.e. how function fails.> */
    attribute :>> failureModeType = FMType::lossOfFunction;

    // FEs — link to higher-level effect FM
    ref occurrence :>> FEs = ();                             // LVL0: no higher level
    // ref occurrence :>> FEs = LVL0::System::func.fm;      // LVL1
    // ref occurrence :>> FEs = LVL0::System::part.func.fm; // LVL2

    attribute :>> preventionControls    = "...";
    attribute :>> detectionControls = "...";

    attribute :>> S = SR::S8_High;                           // LVL0: set manually
    // attribute :>> S = InheritSeverityRating(FEs.S.value); // lower levels
    attribute :>> O = InheritOccurrenceRating(FCs.O.value);  // non-leaf
    attribute :>> D = InheritDetectionRating(FCs.D.value);   // non-leaf
    // attribute :>> O = OR::O4_Moderate;                    // leaf: actual rating
    // attribute :>> D = DR::D4_High;                        // leaf: actual rating

    #failureCause <FC1> lowerLevelCause {
        end [1] occurrence :>> FC references subFunc.lowerFM;
        end [1] occurrence :>> FM references FM1;
        attribute :>> currentPreventionControls = "...";
        attribute :>> currentDetectionControls  = "...";
        attribute :>> confirmationOfPCandDC     = "";
    }

    attribute :>> preventiveAction     = "";
    attribute :>> detectionAction      = "";
    attribute :>> reponsiblePersonName = "";
    attribute :>> targetDate           = "";
    attribute :>> status               = Status::open;
    attribute :>> actionTaken          = "";
    attribute :>> actionTakenEvidence  = "";
    attribute :>> completionDate       = "";
    attribute :>> remarks              = "";
}

Pattern B — Placeholder Failure Mode

Use when a FM needs to exist in the chain (so that higher-level FMs can reference it as a cause via #failureCause) but the LVL2 decomposition is not yet complete. Include at minimum the FEs reference.

action regulateTemp : Function_AIAG_VDA_FMEA {
    perform action transferHeat references coolingLoop.transferHeat;
    perform action rejectHeat    references radiator.rejectHeat;

    // Placeholder FMs — FEs only, no causes or ratings yet
    #failureMode <FM1> lossOfTempRegulation {
        ref occurrence :>> FEs = LVL0::EV::maintainThermalBalance.lossOfThermalBalance;
    }
    #failureMode <FM2> degradedTempRegulation {
        ref occurrence :>> FEs = LVL0::EV::maintainThermalBalance.degradedThermalBalance;
    }
}

Promote placeholders to Pattern A failure modes later by adding causes, controls, and ratings.

Pattern C — Shared Failure Mode (common-cause path)

A single lower-level FM can appear as a cause in multiple higher-level FMs, modelling a common-cause failure path. Each higher-level FM creates its own #failureCause referencing the same lower-level FM. The shared FM’s FEs uses tuple syntax.

LVL0: lossOfVehicleStructuralIntegrity ──> Chassis: lossOfStructuralIntegrity (same FM)
LVL0: lossOfOccupantSafety ──────────────> Chassis: lossOfStructuralIntegrity

// In maintainVehicleStructure (LVL0)
#failureMode <FM1> lossOfVehicleStructuralIntegrity {
    #failureCause <FC1> chassisStructuralIntegrityLoss {
        end [1] occurrence :>> FC references provideStructuralIntegrity.lossOfStructuralIntegrity;
        end [1] occurrence :>> FM references FM1;
    }
}

// In ensureOccupantSafety (LVL0) — same lower-level FM referenced again
#failureMode <FM1> lossOfOccupantSafety {
    #failureCause <FC1> chassisStructuralFailureDuringCrash {
        end [1] occurrence :>> FC references provideStructuralIntegrity.lossOfStructuralIntegrity;
        end [1] occurrence :>> FM references FM1;
    }
}

// In Chassis (LVL1) — shared FM lists both higher-level effects
#failureMode <FM1> lossOfStructuralIntegrity {
    ref occurrence :>> FEs = (
        LVL0::EV::maintainVehicleStructure.lossOfVehicleStructuralIntegrity,
        LVL0::EV::ensureOccupantSafety.lossOfOccupantSafety
    );
    // ... controls and ratings
}

The shared FM inherits severity from the highest S among all its parent effects.

Recommendations

Build top-down, iterate bottom-up: Start with LVL0 system functions and failure modes (S set manually). Add LVL1 placeholders (Pattern B) so chains link immediately. Fill in LVL2 leaf FMs last (actual O and D). Re-parse after each level to catch reference errors early.
Never set AP manually: actionPriorityRating (AP) is computed by CalcAP(S.value, O.value, D.value). Setting it directly will produce inconsistent results. If AP shows TBD, one or more of S, O, D is missing.
Set S at the right level: Severity represents end-user impact — assign it manually at LVL0 only. All lower levels inherit via InheritSeverityRating(FEs.S.value). The only exception is a FM that has no higher-level effect (FEs = ()), which can carry a direct S.
Leaf O and D only: Only assign actual O and D values at leaf-level FMs (those with no #failureCause children). Non-leaf FMs at any level must inherit using InheritOccurrenceRating(FCs.O.value) / InheritDetectionRating(FCs.D.value).
Don’t write subsets FMs: The #failureMode metadata automatically collects FMs into the enclosing function’s FMs. Adding subsets FMs manually is redundant.
Causation direction: The FC end of #failureCause always points to the lower-level FM (the cause). The FM end points back to the enclosing FM (the effect). Do not swap them.
Always add FEs on placeholder FMs: Even a bare placeholder should have a body with FEs so higher-level chains can reference it and Derisker can resolve traceability correctly.