SAE J1739 is the SAE International standard for Failure Mode and Effects Analysis. It covers Design FMEA (DFMEA), Process FMEA (PFMEA), and a supplemental method for systems with built-in monitoring and response capability (FMEA-MSR). J1739 introduces FMEA-MSR primarily in the context of mechatronic systems, but the underlying principle — that in-field diagnostic monitoring can reduce the effective severity of a failure — applies to any domain. The current edition (2021, stabilized 2026) is harmonised with the AIAG/VDA FMEA Handbook: it uses the same Action Priority (AP) table and compatible S-O-D rating criteria, and is referenced by IATF 16949.
The six-step process — Planning, Preparation, Technical Risk Analysis, Risk Assessment, Reduce and Communicate Risks, Document Results — applies to both DFMEA and PFMEA.
The most important concept in J1739 for KF users is the Generic FMEA (§3.8):
A generic FMEA contains both historical and potential failure modes, causes, controls, etc., not related to a specific project. It is used as a starting point for a new DFMEA or PFMEA because, when maintained, it reflects failures that occur after product and process validation and start of regular production and beyond.
This is exactly what a KF type is. A type item carries the accumulated failure modes, causes, effects, and corrective actions for a class of components or processes. When a new project DFMEA 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 so future projects inherit them.
J1739 §5.6.5.2 lists four options for keeping lessons learned in the generic FMEA. KF handles options (b) and (c) structurally:
| J1739 option | KF mechanism |
|---|---|
| (a) Reference lessons learned in the DFMEA at project start | Inherited events from the type, visible in the FMEA report |
| (b) Update the generic FMEA | Promote new events to the type via the inverted checklist |
| (c) Update all variants as a look-across | Inverted checklist run at the type level: shows what instances have learned that the type does not yet know |
| (d) Maintain a separate lessons learned database | Not the KF approach; lessons live in the type structure, not a separate register |
J1739 defines three cases for scoping a DFMEA. All three map naturally to KF's instance-vs-type model:
| J1739 case | Description | KF approach |
|---|---|---|
| Case 1 | New design or new technology | Full type hierarchy inherited; all historical failure modes are present as the baseline |
| Case 2 | Modification to existing design | New events added to the instance (not inherited from the type) represent the change-specific concerns — see DRBFM |
| Case 3 | Existing design in a new environment | Instance-specific events capture the concerns introduced by the new context, against the type's carry-over failure modes |
The J1739 DFMEA worksheet has the following core columns: Item, Function(s)/Requirement(s), Failure Mode, Effect(s), Cause(s), Prevention Controls, Detection Controls, S-O-D, Risk Prioritization, Recommended Actions, Actions Taken, New S-O-D.
KF maps these to its four-column format:
| J1739 DFMEA columns | KF equivalent |
|---|---|
| Item | Item |
| Failure mode, Effect(s), Cause(s) | Event (failure mode, cause, and effect stacked vertically) |
| Prevention and detection controls | Actions (preventive and detection actions linked to the event) |
| S, O, D | Native fields on each event |
| Risk Prioritization (RPN / AP) | Calculated automatically |
| Recommended Actions / Actions Taken | Actions with status (pending → done) |
| Responsibility and target date | Action owner and due date |
| Before/after S-O-D | Original S-O-D preserved; actions carry updated values |
Functions are documented in the item's description. Requirements are modeled as Action items tagged requirement on the same item — a requirement is something that must be done or ensured, so an action is the appropriate representation and compliance is task completion. The gap against J1739's column structure is that there is no explicit data-model link from a failure mode event to the specific requirement it violates; all three elements are present on the item but not cross-referenced in a queryable way.
J1739 supports four risk methods. KF implements:
| Method | J1739 | KF |
|---|---|---|
| RPN (S × O × D) | Optional | Native, calculated |
| SO (S × O) | Optional supplement | Derivable from native S and O values |
| Criticality Analysis | Optional S&O graph | Risk matrix view |
| Action Priority (AP) | Optional, from AIAG/VDA table | Native, automatic |
The AP table in J1739 Appendix I is identical to the one in the AIAG/VDA 2019 Handbook and is the same table KF uses for automatic AP calculation.
FMEA-MSR (Supplemental FMEA for Monitoring and System Response) extends the DFMEA for any system that has built-in monitoring and response capability. Its purpose is to document that in-field diagnostic mechanisms can detect a failure during operation and trigger a system response — limp mode, warning, safe shutdown, alarm — that replaces a high-severity effect with a lower-severity one. The approach is domain-agnostic: it applies equally to automotive ECUs, medical devices, industrial controllers, and aircraft warning systems.
It introduces three additional fields per failure scenario:
These map directly onto KF's before/after risk model:
| FMEA-MSR concept | KF equivalent |
|---|---|
| Failure scenario (operating conditions + failure chain) | Event description |
| Frequency (F) | Occurrence (O) field, assessed for field conditions |
| Diagnostic monitoring mechanism | A detection action on the event, representing the in-product sensor/algorithm |
| System response (limp mode, warning, etc.) | Described in the action; the action's status reflects whether it is implemented |
| Monitoring effectiveness (M) | D field of the monitoring action |
| New effect after system response | Described in the action |
| SEV after MSR | New S on the monitoring action (the before/after severity) |
In practice: take a high-severity event (S=9), add a detection action that represents the diagnostic mechanism, set its D to the M rating and its new S to the mitigated severity. The before/after risk display then shows the original DFMEA risk alongside the MSR-mitigated risk — exactly the two separate indicators that §5.4.6.10 requires.
The MSR risk prioritisation (Appendix K) uses F × M × SEV_after — the same three-factor logic as the DFMEA AP table (Appendix I, using O × D × S), just applied to different inputs. The verbal anchors on the scales differ between the two contexts (F=4 in Appendix D means "low field frequency"; O=4 in Appendix B means "moderate design-phase occurrence") but the prioritisation logic — severity is paramount, frequency/occurrence second, detection/monitoring third — is structurally identical. A separate AP table for MSR is not needed. KF's configured AP table applies to the MSR before/after values (SEV_after, F as O, M as D) just as it does to the DFMEA values.
Special characteristics are product or process features where variation has a significant influence on safety, regulatory compliance, fit, or service life. The norm defines a two-stage process:
Stage 1 — Identification in the FMEA. The DFMEA team flags potential candidates during the risk analysis. The norm explicitly states that formal company symbols are not required in the DFMEA — it is an input to the selection process, not the selection itself. In KF, a tag (e.g., SC, CC, KCC) on the item or event is the entire contribution the FMEA tool is expected to make. Tags are searchable, visible in the FMEA report, and propagate through the type system — a type-level event tagged SC passes the flag to every instance.
Stage 2 — Designation and downstream workflow. The company's review process determines which candidates are formally designated. Once designated: they are marked on engineering drawings and specifications (outside KF); they are referenced in the PFMEA with their controlling process parameters; and they must appear on the process control plan. These steps fall outside the FMEA tool's scope — they involve drawing management and manufacturing systems that no FMEA tool, including spreadsheet-based ones, would handle.
J1739's PFMEA applies the same six-step process to manufacturing and assembly operations. Items become process steps; failure modes are process defects; effects and causes are assessed from the plant, ship-to-plant, and end-user perspectives. The S-O-D scales use PFMEA-specific criteria (Appendices F, G, H) but the AP table is the same as for DFMEA.
KF applies the same item-event-action-risk model to process analyses without change. Process steps are modelled as items, failure modes as events, and controls as actions. The PFMEA severity, occurrence, and detection scales (which differ from DFMEA scales for the same numerical values) must be selected and documented by the team; KF does not enforce scale type.
J1739's companion PFMEA tools — the process flow diagram (PFD) and process control plan (PCP) — are not implemented in KF. These documents are typically maintained in separate tools and referenced from the PFMEA.
| J1739 aspect | KF support | Status |
|---|---|---|
| DFMEA structure (item, failure, cause, effect, action) | Four-column format with stacked events | ✅ |
| Severity, Occurrence, Detection fields | Native fields | ✅ |
| RPN and SO | Native, automatic | ✅ |
| Action Priority (AP) | Native, automatic (same AIAG/VDA table) | ✅ |
| Before/after S-O-D | Original values preserved; actions carry updated values | ✅ |
| Actions with owner and due date | First-class action items | ✅ |
| System hierarchy (bill of materials) | Item component tree | ✅ |
| Fault tree | Native fault tree view | ✅ |
| Generic FMEA / lessons learned baseline | Type hierarchy with inherited failure modes | ✅ |
| Lessons learned update (look-across) | Inverted checklist and type promotion | ✅ |
| DFMEA Cases 1, 2, 3 | Instance vs type event distinction | ✅ |
| PFMEA (same model applied to process items) | Fully applicable | ✅ |
| PFMEA-specific S-O-D scales | Must be selected by team; not enforced | ⚠ |
| Function and requirement columns | Functions in item description; requirements as tagged actions; no explicit cross-reference from event to the specific requirement it violates | ⚠ |
| Special characteristics identification (DFMEA/PFMEA flagging) | Via item tags; formal designation and control plan are downstream of the FMEA tool | ✅ |
| FMEA-MSR (F, M, SEV after MSR) | Modelled via before/after S on a detection action; same AP table applies | ✅ |
| Process flow diagram (PFD) | Out of scope | ❌ |
| Process control plan (PCP) | Out of scope | ❌ |