The AIAG/VDA FMEA Handbook (2019) is a joint publication from the US Automotive Industry Action Group (AIAG) and the German automotive association (VDA). It defines a seven-step process for Design FMEA (DFMEA), Process FMEA (PFMEA), and Supplemental FMEA for Monitoring and System Response (FMEA-MSR). Its central innovation over earlier approaches is replacing the Risk Priority Number (RPN) with Action Priority (AP) — a table-driven H/M/L ranking that treats severity, occurrence, and detection as factors of unequal weight rather than multiplying them into a single number. The same AP table was subsequently adopted by SAE J1739.
Step 1 of the handbook introduces the Base FMEA: an existing FMEA for a product or process family, used as the starting point for a new analysis. A well-maintained Base FMEA reflects all failures known from past projects and validation results. The new project FMEA is built by extending it, not from scratch.
This is precisely what a KF type does. A type item carries the accumulated failure modes, causes, effects, and corrective actions for a class of products or processes. When a new project FMEA is started, the project item is created as an instance of the relevant type; all historical failure modes are inherited automatically. When the project surfaces new failures, those can be promoted back to the type via the inverted checklist, updating the Base FMEA for all future projects.
| Step | Handbook | KF |
|---|---|---|
| 1. Planning and preparation | Define scope, intent, team, timing; identify the Base FMEA | Create the project item; inherit structure and failure history from a type (the Base FMEA) |
| 2. Structure analysis | Decompose the system: system → subsystem → component → characteristic | Build a component hierarchy using item relationships |
| 3. Function analysis | Define the function and requirements of each structural element | Document functions in item descriptions; requirements as sub-items or text |
| 4. Failure analysis | Identify failure modes, effects (upward), and causes (downward) for each function | Record events on items; effects, failure mode, and cause stack vertically in a single event |
| 5. Risk assessment | Assign S to effects, O to causes, D to controls; compute AP | Native S-O-D fields on each event; AP calculated automatically |
| 6. Optimization | Define recommended actions; assign responsibility and due date; re-assess S-O-D after completion | Actions are first-class items with owner, due date, and before/after S-O-D |
| 7. Documentation | Archive the FMEA; record lessons learned; link to DVP&R and control plan | All items are versioned and searchable; lessons promoted to the type become the updated Base FMEA |
Steps 2 and 3 are the most explicit addition in the AIAG/VDA handbook compared to earlier FMEA practice. The structural decomposition (step 2) is required to map the interface between system levels, and the function analysis (step 3) provides the bridge from structure to failure: a failure mode is always the failure of a function.
In KF, the structural tree is the item component hierarchy — the same hierarchy that drives the FMEA report, the fault tree, and the checklist. Functions are documented in the item's description or as sub-items. Requirements are modeled as Action items tagged requirement on the same item, following the model described in the ISO 26262 page: a requirement is something an agent must do or ensure, so an action is the correct representation. Compliance is then task completion — the requirement is met when its action is marked done.
The remaining gap against the handbook's column structure is that there is no explicit data-model link from a failure mode event to the specific requirement it violates. In a handbook-compliant DFMEA spreadsheet, a single row traces function → requirement → failure mode explicitly. In KF, all three are present on the same item — functions in the description, requirements as tagged actions, failure modes as events — but a column-by-column audit would not find a queryable cross-reference between them.
The handbook defines a vertical failure chain: a failure effect (impact on the next-higher level or the end user) linked to a failure mode (how the element fails to perform its function) linked to a failure cause (why the failure mode occurs). Severity is rated on the effect; occurrence on the cause; detection on the controls for that cause.
KF groups all three in a single event: the event title is the failure mode, and the description carries the cause and effect. This keeps the FMEA compact and readable. The S-O-D fields are on the event and map to the corresponding handbook fields. The slight divergence is that effect, mode, and cause are not in separate columns — they are in a single structured view.
The AP table from the handbook's Appendix — now also part of SAE J1739 Appendix I — is the same table KF uses for automatic AP calculation. RPN remains available as an optional field; the handbook advises against using RPN thresholds as the sole decision criterion, which is consistent with KF's approach of displaying both RPN and AP.
Before/after S-O-D is natively supported: each action on an event carries updated severity, occurrence, and detection values that reflect the risk after the action has been completed. The FMEA report shows both the original and the residual risk.
The handbook covers FMEA-MSR for any system with built-in monitoring and response capability, using the same three additional fields as SAE J1739: Frequency (F), Monitoring (M), and SEV after system response. KF supports FMEA-MSR through the before/after risk model: the in-field diagnostic mechanism is modelled as a detection action on the event, its D field carries the M rating, and its new S carries the mitigated severity. The same AP table applies — the MSR risk prioritisation uses the same three-factor logic with the same H/M/L output. See the SAE J1739 page for the detailed mapping.
| Aspect | KF support | Status |
|---|---|---|
| S, O, D fields | Native on each event | ✅ |
| Action Priority (AP) | Native, automatic; same table as handbook | ✅ |
| Before/after S-O-D | Original values preserved; actions carry updated values | ✅ |
| Base FMEA / lessons learned reuse | Type hierarchy with inherited failure modes; inverted checklist for promotion | ✅ |
| System hierarchy (structure analysis) | Item component tree | ✅ |
| Failure chain (effect → mode → cause) | Single event with stacked description | ✅ aligned |
| Function → requirement → failure mode traceability | Functions in item description; requirements as tagged actions; no explicit cross-reference from event to the specific requirement it violates | ⚠ |
| FMEA-MSR | Modelled via before/after S on a detection action; same AP table applies | ✅ |
| Responsible person per action | Action owner field | ✅ |
| RPN | Optional, calculated | ✅ |
| Process control plan | Not supported | ❌ |