Standard Properties
| Name | Type | Default | Description |
|---|
| ID | Text | Auto-generated | Unique identifier assigned by Polarion. Follows project prefix convention (e.g., FM-001). Read-only after creation. |
| Title | Text | Required | Brief name of the failure mode (e.g., “Sensor loses signal”). Appears in all risksheet and powersheet views. Limited to 200 characters for readability. |
| Description | Text | Empty | Detailed narrative describing how and when the failure mode occurs. Include operational context, triggering conditions, and system state. Recommended 100–500 words. |
| Status | Enumeration | Draft | Workflow state: Draft → In Progress → In Review → Pending Approval → Approved / Rejected / Obsolete. Controls visibility in reports and dashboard compliance metrics. |
| Assignee | User Reference | Unassigned | Team member responsible for FMEA analysis of this failure mode. Used for workload tracking and review routing. |
| Priority | Enumeration | Medium | Initial priority for analysis: Low, Medium, High. Updated post-mitigation based on Action Priority. |
| Category | Multi-select Enum | Empty | Classification tags for grouping: Power, Communication, Sensor, Processing, Environmental, Interface. Enables filtering in dashboards and reports. |
| Comments | Text | Empty | Discussion thread for collaborative analysis. Supports markdown and @mentions for stakeholder engagement. |
| Hyperlinks | URL/Reference | Empty | External references to design documents, standards, customer specifications, or supporting evidence. |
| Attachments | File | Empty | Linked analysis files: FMEA spreadsheets, simulation results, failure photos, test data. |
DFMEA-Specific Properties (Design FMEA)
| Name | Type | Default | Description |
|---|
failureModeDescription (custom) | Text | Empty | Detailed description of the failure scenario. Required field for DFMEA. Example: “Camera module loses video signal due to degraded connector contact resistance.” |
severity (custom) | Integer (1–10) | Empty | Initial severity rating (S): likelihood and magnitude of harm if failure occurs. Scale: 1=negligible, 5=moderate, 10=catastrophic. Used in Action Priority (AP) calculation: AP = S × O × D. |
severityNew (custom) | Integer (1–10) | severity | Post-mitigation severity rating after risk controls implemented. Usually unchanged from initial severity unless control reduces failure consequence. Read-only formula field in some configurations. |
occurrence (custom) | Integer (1–10) | Empty | Initial occurrence rating (O): likelihood the cause will occur. Scale: 1=very unlikely, 5=moderate, 10=very likely. Reflects design maturity and component reliability data. |
occurrenceNew (custom) | Integer (1–10) | occurrence | Post-mitigation occurrence rating after prevention controls implemented. Typically lower than initial if effective prevention controls assigned. |
detection (custom) | Integer (1–10) | Empty | Initial detection rating (D): likelihood failure will escape to customer if it occurs. Scale: 1=certain detection, 10=detection impossible. Reflects design verification testing capability. |
detectionNew (custom) | Integer (1–10) | detection | Post-mitigation detection rating after enhanced detection controls (testing, monitoring). Often improved to account for additional verification activities. |
actionPriority (custom) | Calculated | Formula: S × O × D | Initial RPN (Risk Priority Number). Three-tier Action Priority (AP): High (RPN ≥ 125), Medium (40–124), Low (1–39). Used to prioritize mitigation efforts. |
actionPriorityNew (custom) | Calculated | Formula: severityNew × occurrenceNew × detectionNew | Post-mitigation RPN. Determines whether residual risk is acceptable. Target: reduce High → Medium or Low per project risk acceptance criteria. |
riskControlType (custom) | Enumeration | Empty | Type of mitigation: Prevention (eliminates cause), Detection (identifies failure), Containment (limits consequence). Influences which rating (O/D) is affected by control effectiveness. |
safetyClassification (custom) | Enumeration | Empty | Safety role of this failure mode: SC (Safety-Critical) or CC (Critical Component). Determines control rigor and verification requirements per ISO 26262 or IATF 16949. |
causeOfFailure (custom) | Text | Empty | Root cause description (DFMEA Level 3). Example: “Connector pin corrosion due to moisture ingress.” Appears in risksheet Level 3 rows when editing multi-level FMEA. |
currentControlsDescription (custom) | Text | Empty | Description of existing design or manufacturing controls that address this failure mode. Documents preventive mechanisms already in place before mitigation. |
recommendedAction (custom) | Text | Empty | Proposed mitigation or design change to reduce S/O/D. Example: “Redesign connector with sealed IP67 housing.” Reviewed during FMEA approval. |
designRecommendationStatus (custom) | Enumeration | Open | Workflow for recommended actions: Open → In Progress → Completed / Deferred / Not Feasible. Tracks implementation of FMEA recommendations. |
Process FMEA Properties (PFMEA)
| Name | Type | Default | Description |
|---|
effectOfFailure (custom) | Text | Empty | Customer-visible consequence of the process failure. Example: “Sensor housing has reduced moisture protection.” Distinct from DFMEA failure consequences. |
pfmSeverity (custom) | Integer (1–10) | Empty | Process FMEA severity: likelihood and severity of customer impact. Scale identical to DFMEA but context is manufacturing/assembly process, not design. |
pfmSeverityNew (custom) | Integer (1–10) | pfmSeverity | Post-mitigation severity after process control improvements. |
pfmOccurrence (custom) | Integer (1–10) | Empty | Process failure occurrence: frequency the root cause manifests during manufacturing. Influenced by process capability (Cpk), material batch variation, operator skill. |
pfmOccurrenceNew (custom) | Integer (1–10) | pfmOccurrence | Post-mitigation occurrence after process controls (fixture improvements, operator training, SPC monitoring). |
pfmDetection (custom) | Integer (1–10) | Empty | Detection likelihood for PFMEA: ability of in-process or final inspection to catch defect before shipment. Reflects sampling plans, inspection automation, test effectiveness. |
pfmDetectionNew (custom) | Integer (1–10) | pfmDetection | Post-mitigation detection after enhanced process inspection or 100% testing. |
pfmAP (custom) | Calculated | Formula: pfmSeverity × pfmOccurrence × pfmDetection | Initial Process RPN. Prioritizes manufacturing risk mitigation. |
pfmAPNew (custom) | Calculated | Formula: pfmSeverityNew × pfmOccurrenceNew × pfmDetectionNew | Post-mitigation Process RPN. Acceptance threshold typically 125 for High, 40 for Medium. |
preventionControl (custom) | Text | Empty | Process control that prevents the root cause from occurring (e.g., “Automated sealant application with visual verification”). Improves occurrence rating. |
detectionControl (custom) | Text | Empty | Process control that detects failure after it occurs but before customer delivery (e.g., “Moisture chamber test at 95% RH for 48 hours”). Improves detection rating. |
processStepLink (link) | Reference (Process Step) | — | Links this failure mode to a parent Process Step (Level 1 in PFMEA hierarchy). Establishes which manufacturing step is being analyzed. |
Traceability and Risk Control Links
| Link Role | Target Type | Cardinality | Description |
|---|
analyzedIn (inbound) | Function / System Element | Many | Indicates which function or component this failure mode analyzes. Establishes parent-child relationship in risksheet hierarchy. |
mitigatedBy (outbound) | Risk Control | Many | Links to risk controls (design changes, additional testing, monitoring) that address this failure mode. Justifies post-mitigation ratings (S_New, O_New, D_New). |
linkedTo (bidirectional) | Characteristic | Many | Links failure modes to design characteristics (measurable parameters). Enables traceability from design specification to failure analysis. Appears in Characteristics PowerSheet as expanded failure mode columns. |
verifiedBy (outbound) | Test Case / Validation Test Case | Many | Links to verification or validation tests that confirm the failure mode is adequately mitigated or eliminated. Tracks V&V evidence per ISO 26262 Part 4/5. |
refines (outbound) | Requirement | Many | Associates failure mode to related requirements being refined or validated. Improves traceability coverage reports. |
assesses (inbound) | Hazard (HARA) | One | Relates to parent hazard identified in ISO 26262 HARA. Connects design-level FMEA back to system-level HARA for bidirectional traceability. Optional but recommended for safety-critical functions. |
relatedTo (bidirectional) | Failure Mode | Many | Cross-references similar or dependent failure modes for knowledge reuse and consistency review. |
Risksheet Integration
Failure Modes appear as Level 2 rows in DFMEA/SFMEA risksheet configurations. Hierarchical organization:
In risksheet editors, click the + icon on a failure mode row to expand associated causes. RPN values aggregate upward: sum of all cause RPNs rolls up to failure mode level for quick prioritization.
Safety Classification (SC/CC)
| Classification | Meaning | Visual Badge | Verification Rigor | Example |
|---|
| SC | Safety-Critical | Orange 🛡️ | Requires ASIL-compliant verification, formal analysis | Sensor signal loss analyzed in HARA → Safety Goal → FMEA |
| CC | Critical Component | Red | Enhanced verification, process controls, enhanced testing | Connector robustness failure mode flagged for design review |
| Unclassified | Non-critical | Gray | Standard verification | Cosmetic wear on non-functional surface |
If a failure mode is classified as SC/CC, the linked Characteristic and Design Requirement should also be marked SC/CC. PowerSheet views filter and highlight these for review.
Action Priority (AP) Interpretation
| AP Range | RPN | Risk Level | Typical Response |
|---|
| High | ≥ 125 | Critical | Immediate design change required. No production release until mitigated to Medium or Low. Escalate to design leadership. |
| Medium | 40–124 | Significant | Design change or enhanced testing recommended. Document rationale if deferred. Review in design gate approvals. |
| Low | 1–39 | Acceptable | Monitor and include in control plan. No immediate action required unless new information changes risk assessment. |
Creating and Editing Failure Modes
In Risksheet Editor
- Add Row: Click + Add Failure Mode or right-click parent function/system element.
- Enter Description: Type failure mode name and description inline.
- Set Ratings: Enter S, O, D values. AP calculates automatically.
- Link to Characteristics: Use dropdown in Characteristics column to select design parameters affected.
- Add Causes: Press Tab or Enter to create Level 3 cause rows with separate S/O/D ratings.
- Assign Risk Controls: Click Risk Controls column to link mitigation work items.
- Update Post-Mitigation: After risk controls assigned, enter S_New, O_New, D_New. AP_New recalculates.
- Save Document: Changes persist to Polarion database.
Via Polarion UI
- Navigate to Risks space → select DFMEA/SFMEA/PFMEA module.
- Click Create Work Item → select Failure Mode.
- Fill mandatory fields: Title, Description, Severity, Occurrence, Detection.
- Link to parent Function or Process Step via analyzedIn relationship.
- Assign to safety engineer or FMEA team lead.
- Publish and add to risksheet document.
Validation and Compliance
- Mandatory Fields: Title, Description, Severity (S), Occurrence (O), Detection (D), Status.
- ISO 26262 Compliance: All Failure Modes linked to SC/CC Characteristics or Requirements must have verification test cases (verifiedBy link).
- Post-Mitigation Threshold: RPN_New must meet project risk acceptance criteria (often ≤ 100 or ≤ 80 for ASIL D items).
- IATF 16949/APQP: Process Failure Modes must have linked Prevention and Detection Controls documented.
- Workflow Approval: Status must progress to Approved before FMEA release. Rejected items must be reworked.
Common Relationships and Usage Patterns
Link Failure Mode to Risk Control
- Failure Mode: “Sensor loses signal”
- mitigatedBy: Risk Control RC-042 “Implement dual sensor redundancy”
- mitigatedBy: Risk Control RC-043 “Add firmware watchdog timer”
- Detection (new): 3 (improved from 8 with redundancy + watchdog)
Multi-Level FMEA (System → Subsystem → Component)
System FMEA:
- FM-001: Loss of AEB system braking capability (System Element: AEB System)
- Causes: ECU power failure, sensor degradation, CAN communication loss
Design FMEA (Component Level):
- FM-201: Camera module image corruption (System Element: Camera Module)
- FM-202: Radar signal attenuation (System Element: Radar Module)
- Cause: Antenna connector corrosion > RPN 140 > Risk Control: sealed connector redesign
Traceability Chain for Safety-Critical Failure Mode
Customer Requirement: "Vehicle must brake within 0.5 seconds"
↓ (refined by)
System Requirement SR-12: "AEB system shall activate braking within 400 ms"
↓ (refined by)
Design Requirement DR-05: "Sensor signal latency ≤ 50 ms"
↓ (linked to)
Characteristic: "Sensor signal response time" (SC)
↓ (assessedBy)
Failure Mode FM-088: "Sensor signal latency exceeds 50 ms" (SC)
├── mitigatedBy: Risk Control RC-120 "Dedicated CAN priority channel"
└── verifiedBy: Test Case TC-456 "Measure sensor signal latency across temperature range"
PowerSheet Views
Failure modes appear in these read-only or interactive PowerSheets:
- Whole RTM Sheet: Shows failure modes in complete traceability matrix context.
- Characteristics Sheet: Displays failure modes as expanded columns linked to each characteristic.
- Component Characteristics: Scoped to single component, failure modes with post-mitigation Action Priority color-coded.
- Subsystem Functions: Shows functions with linked failure modes, enabling function-level risk review.
For deeper guidance on FMEA workflow, risk control assignment, and verification:
