The Failure Mode form is divided into five primary sections, each addressing a distinct phase of FMEA analysis:
Identification Section
| Field Name | Type | Default | Description |
|---|
fmId | Text | Auto-generated | Unique failure mode identifier (e.g., FM-001). System-assigned upon work item creation; used for cross-referencing in reports and traceability matrices. |
fmTitle | Text | Required | Short descriptive title of the failure mode (e.g., Sensor loses lock on target). Appears in column headers and summary reports. |
fmDescription | Long Text | Required | Detailed narrative of how the function or system element fails. Should be observable and testable. Example: Camera sensor enters power-saving mode during highway speed, causing loss of object tracking capability. |
fmCategory | Enumeration | functional | Classification of failure mode type. Options: functional (operation fails), performance (degraded output), safety (hazardous condition), interface (incompatible signals). |
linkedSystemElement | Work Item Link | — | Reference to the System Element (DFMEA) or Process Step (PFMEA) being analyzed for this failure mode. Enforced by RTM model; establishes hierarchical scope. |
Effects and Hazards Section
| Field Name | Type | Default | Description |
|---|
effectOfFailure | Long Text | Required | Description of the consequence when the failure mode occurs. Captures customer-visible impact or downstream system degradation. Example: Braking command ignored; vehicle continues at current speed, increasing collision risk. |
effectSeverity | Enumeration | — | Customer perception of effect severity (DFMEA). Options: safety (hazardous to occupants), major (significant loss of function), minor (reduced capability), none (inconvenience). |
linkedHazard | Work Item Link | — | Traceability link to Hazard work item (if applicable). Establishes bidirectional link to HARA analysis. Optional for DFMEA; PFMEA typically does not link hazards directly. |
linkedHarm | Work Item Link | — | Reference to Harm work item for ISO 14971 risk management integration. Links FMEA to associated patient/user harm scenarios. |
DFMEA Classification Section
| Field Name | Type | Default | Description |
|---|
dfmeaSeverity | Enumeration | — | DFMEA Severity rating (1–10 scale). Assesses customer impact if failure reaches end user. Scale: 1 (no effect) to 10 (safety-critical, uncontrolled hazard). Typically unchanged between pre/post mitigation. |
dfmeaOccurrence | Enumeration | — | DFMEA Occurrence rating (1–10 scale). Estimates frequency of the cause occurring given current design. Scale: 1 (remote) to 10 (frequent). Updated only if design changes. |
dfmeaDetection | Enumeration | — | DFMEA Detection rating (1–10 scale) for existing design controls. Scale: 1 (certain detection) to 10 (certain non-detection). Assesses effectiveness of existing tests, reviews, or monitoring. |
dfmeaRPN | Integer | Auto-calculated | Risk Priority Number: Severity × Occurrence × Detection. Automatically computed field; highlighted red if RPN ≥ 100. Used for action prioritization. |
dfmeaSeverityPost | Enumeration | — | Post-mitigation Severity rating. In DFMEA, severity typically does not change (design failure remains equally severe); left equal to dfmeaSeverity in most cases. |
dfmeaOccurrencePost | Enumeration | — | Post-mitigation Occurrence rating. Updated after design changes (e.g., added redundancy, increased robustness) reduce likelihood of cause. |
dfmeaDetectionPost | Enumeration | — | Post-mitigation Detection rating. Updated after new verification controls (e.g., added sensor monitoring, new diagnostic algorithm) improve early detection. |
dfmeaRPNPost | Integer | Auto-calculated | Post-mitigation RPN: SeverityPost × OccurrencePost × DetectionPost. Automatically computed; shows risk reduction effectiveness of proposed controls. |
PFMEA Classification Section
| Field Name | Type | Default | Description |
|---|
pfmeaSeverity | Enumeration | — | PFMEA Severity rating (1–10 scale). Assesses customer-perceived severity of the effect if process failure reaches production or end user. Scale mirrors DFMEA but focuses on manufacturing/process impact. |
pfmeaOccurrence | Enumeration | — | PFMEA Occurrence rating (1–10 scale). Estimates how frequently the process cause occurs in current manufacturing, supplier process, or operational procedure. Higher if process is immature or uncontrolled. |
pfmeaDetection | Enumeration | — | PFMEA Detection rating (1–10 scale) for current prevention and detection controls in manufacturing. Assesses whether incoming inspection, in-process checks, or SPC detect the failure before shipment. |
pfmeaRPN | Integer | Auto-calculated | PFMEA Risk Priority Number: Severity × Occurrence × Detection. Determines action priority for process control improvements. High RPN (e.g., ≥ 100) triggers immediate corrective action. |
pfmeaSeverityPost | Enumeration | — | Post-mitigation Severity (PFMEA). Like DFMEA, typically unchanged; severity is inherent to failure consequence. |
pfmeaOccurrencePost | Enumeration | — | Post-mitigation Occurrence (PFMEA). Updated after process improvements (e.g., better operator training, enhanced preventive controls, supplier qualification). |
pfmeaDetectionPost | Enumeration | — | Post-mitigation Detection (PFMEA). Updated after new detection controls (e.g., tighter SPC limits, 100% incoming inspection, automated vision system). |
pfmeaRPNPost | Integer | Auto-calculated | Post-mitigation PFMEA RPN. Shows effectiveness of process improvements and detection enhancements. Target is typically RPN < 100 or per AIAG-VDA guidance. |
Risk Controls and Mitigation Section
| Field Name | Type | Default | Description |
|---|
preventionControl | Long Text | — | Design or process control that prevents the cause from occurring. Example (DFMEA): Add hardware watchdog timer to detect ECU lockup and trigger safe shutdown. Example (PFMEA): `Implement automated inspection to detect solder joint defects before assembly.‘ |
detectionControl | Long Text | — | Existing or proposed control that detects the failure or cause before reaching the customer. Example: On-board diagnostics monitor sensor voltage and flag out-of-range conditions. |
linkedRiskControls | Work Item Link | — | Bidirectional traceability to Risk Control work items. Each risk control describes the implementation of prevention/detection measures, responsible party, and closure evidence. One failure mode may link to multiple risk controls. |
actionPriority | Enumeration | — | Post-mitigation Action Priority: H (High), M (Medium), L (Low). Derived from post-mitigation RPN or management judgment. Typically: RPN ≥ 100 = H, RPN 50–99 = M, RPN < 50 = L. Used to schedule mitigation tasks. |
responsibility | Text / Enumeration | — | Name or role of person/team responsible for implementing risk control actions (e.g., Hardware Lead, Manufacturing Engineer). Optional; inherited from Risk Control work item if linked. |
targetClosureDate | Date | — | Planned completion date for risk control implementation and verification. Used for project scheduling and milestone tracking. |
Classification and Traceability Section
| Field Name | Type | Default | Description |
|---|
specialCharacteristic | Enumeration | — | Safety or Critical Characteristic designation. Options: SC (Safety Critical — requires enhanced verification per ISO 26262), CC (Critical Characteristic — requires enhanced control per IATF 16949), None (standard). Drives verification/control plan requirements. |
linkedCharacteristics | Work Item Link | — | Bidirectional link to Characteristic work items affected by this failure mode. Establishes traceability from design parameters to failure analysis. Populated during DFMEA definition or characteristic-centric workflow. |
linkedFailureModes | Work Item Link | — | For hierarchical FMEA (System → Subsystem → Component), links parent failure modes. Example: System-level Power supply failure may link to component-level PMIC overvoltage output. |
linkedRiskRecords | Work Item Link | — | ISO 14971 risk record references (e.g., for medical device integration or dual-standard projects). Optional; used when concurrent ISO 14971 risk management is required. |
documentScope | Text (Read-only) | — | Title of the containing FMEA document (automatically populated). Example: Camera Module — Component DFMEA. Useful for multi-document filtering in reports. |
DFMEA vs. PFMEA Field Usage
| Field | DFMEA | PFMEA | Notes |
|---|
| Failure Mode Name | Required | Required | Primary identifier |
| Failure Effect | Required | Required | Impact description |
| Failure Cause | Required | Required | Root cause analysis |
| Severity Rating | Required | Required | S rating (1-10) |
| Occurrence Rating | Required | Required | O rating (1-10) |
| Detection Rating | Required | Required | D rating (1-10) |
| Current Prevention Controls | Required | Required | Existing controls |
| Current Detection Controls | Required | Required | Detection methods |
| Design Function | Required | — | Design-specific context |
| Process Step | — | Required | Process-specific context |
| Special Characteristics | Optional | Required | PFMEA emphasis |
| Recommended Actions | Optional | Optional | Improvement actions |
Automatic Calculations and Validation
The Risk Priority Number (RPN) is automatically recalculated whenever Severity, Occurrence, or Detection values change. If the calculated RPN exceeds 100, the field highlights red in the form and triggers escalation in dashboard views.
The actionPriority field is mandatory if post-mitigation RPN ≥ 100. Form validation prevents saving until Action Priority is assigned. This enforces management review of high-risk items.
The form layout switches between DFMEA and PFMEA field sets based on the parent document type. For example, if the failure mode is created within a Component DFMEA document, only DFMEA-related severity/RPN fields appear; PFMEA fields are hidden. This prevents user confusion and maintains data integrity.
Enumeration References
Severity Scale (1–10):
- 1 = No effect or very minor cosmetic issue
- 2–3 = Minor inconvenience; workaround available
- 4–5 = Moderate loss of function; customer annoyed
- 6–7 = Significant loss of function; customer dissatisfaction
- 8–9 = Safety or legal concern; major loss of function
- 10 = Safety-critical failure; potential injury or fatality (DFMEA) or product liability (PFMEA)
Occurrence Scale (1–10):
- 1 = Failure is extremely unlikely; remote probability
- 2–3 = Low probability; seen in similar products over years
- 4–5 = Occasional occurrence; seen in similar products in years
- 6–7 = Moderate frequency; seen in similar products within months
- 8–9 = High frequency; seen in similar products within weeks
- 10 = Failure is almost certain; design or process is immature
Detection Scale (1–10):
- 1 = Existing controls will almost certainly detect the failure; automated, foolproof
- 2–3 = High probability of detection; robust inspection or test
- 4–5 = Moderate detection probability; some automated tests, manual oversight
- 6–7 = Low detection probability; informal checks, operator-dependent
- 8–9 = Very low detection probability; control unreliable or bypassed
- 10 = No detection possible; failure reaches customer undetected
Action Priority:
H = High (RPN ≥ 100 or executive decision; immediate action required)M = Medium (RPN 50–99; plan and schedule action)L = Low (RPN < 50; monitor and revisit periodically)
Integration with Risksheet and PowerSheet
The Failure Mode Form Layout integrates with two Nextedy configuration systems:
Risksheet Integration:
Failure Mode work items appear as rows in risksheet documents (DFMEA, PFMEA, Control Plan). The form fields directly populate risksheet columns. For example, when editing a failure mode in the System-on-Chip (SoC) — Component DFMEA risksheet, clicking on a failure mode row opens this form, allowing inline field editing. Changes save immediately to the risksheet and appear in all linked reports.
PowerSheet Integration:
Failure modes are expanded in PowerSheet configurations such as Subsystem Functions and Component Characteristics. The form fields are accessible via drill-down; for example, selecting a failure mode in the characteristics PowerSheet opens this form for detailed review or editing.
The Failure Mode Form Layout is role-aware. Different roles (Safety Engineer, Design Engineer, Configuration Manager) may see different field visibility or editability:
- Safety Engineers: Full access to all DFMEA and ISO 26262 fields; PFMEA fields hidden or read-only
- Design Engineers: Access to design-related fields (Characteristics, Controls); Severity/Detection ratings shown for context
- Manufacturing/Process Engineers: Full access to PFMEA fields; DFMEA fields hidden or read-only
- Configuration Managers: Read-only access to all fields for traceability audits
- Program Managers: Dashboard view; form fields in read-only mode for status review
