Skip to main content

​
What’s the difference between DFMEA and PFMEA?

Design FMEA (DFMEA) analyzes failure modes in the product design across system/subsystem/component levels, using the AIAG-VDA Action Priority methodology (Severity × Occurrence × Detection → H/M/L). Process FMEA (PFMEA) analyzes failure modes in manufacturing processes, focusing on process steps and control methods with Risk Priority Number (RPN = S × O × D). DFMEA asks “what can fail in the design?” while PFMEA asks “what can fail during manufacturing?” See AIAG-VDA FMEA Methodology for detailed comparison.

​
How do System, Subsystem, and Component FMEA levels relate?

TestAuto2 implements a three-level DFMEA hierarchy following AIAG-VDA guidelines. System FMEA analyzes top-level functions and customer requirements, Subsystem FMEA analyzes allocated functions within subsystems (e.g., AEB Sensor Unit, Brake Controller), and Component FMEA analyzes characteristics of individual parts. Failure modes can link upstream using the “Link to Upstream SFMEA” workflow, creating traceability from component failures → subsystem failures → system-level impacts. See Create System FMEA and Link to Upstream SFMEA.

​
What is Action Priority and how is it different from RPN?

Action Priority (AP) is the AIAG-VDA FMEA methodology’s risk classification system, categorizing failure modes as High (H), Medium (M), or Low (L) priority based on a lookup table combining Severity, Occurrence, and Detection ratings (1-10 scale each). Unlike the older Risk Priority Number (RPN) which multiplies S×O×D to produce a number 1-1000, Action Priority uses defined combinations to avoid mathematical artifacts. TestAuto2 uses AP for DFMEA and RPN for PFMEA per industry practice. See Action Priority Methodology and Calculate Action Priority.

​
How do I track pre-mitigation vs post-mitigation risk ratings?

FMEA work items include separate custom fields for before and after risk controls: premitigationFMOccurrence, premitigationDetection, premitigationAP capture the initial risk, while postmitigationFMOccurrence, postmitigationDetection, postmitigationAP capture the risk after implementing controls. The risksheet configuration includes progressive workflow views that guide you through initial assessment → control definition → post-mitigation assessment. Traffic light indicators show completion status for each phase. See Track Post-Mitigation Ratings and Failure Mode Custom Fields. Yes. Failure modes can link to multiple work item types through the RTM domain model. While the primary FMEA workflow links failure modes to characteristics (via assesses relationship) and functions (also via assesses), you can create custom link roles to trace failure modes back to hazards or safety goals. The Risk Control Effectiveness Report shows how risk controls (linked from failure modes) trace to safety goals, creating ISO 26262 compliance evidence. See RTM Domain Model for relationship configuration.

​
Why does the FMEA risksheet show different columns than my template?

The risksheet configuration is stored in .polarion/nextedy/sheet-configurations/*.yaml and can be customized per document using the nextedySheetConfig custom field. TestAuto2 includes five risksheet templates: HARA, HAZID, System FMEA, Design FMEA, and Process FMEA — each with different column layouts matching their methodology. If your document shows unexpected columns, check the nextedySheetConfig field value and verify it matches your intended analysis type (e.g., sfmea-risksheet for System FMEA). See Customize Risksheet Columns.

​
How do I generate FMEA reports?

Navigate to Documentation → FMEA Reports dashboard to access both DFMEA and PFMEA summary reports with live failure mode counts. The system provides dedicated report pages: System DFMEA Report, System PFMEA Report, and FMEA Coverage Report. Each report uses Velocity macros to query failure mode work items, format risk ratings with visual indicators, and generate traceability matrices. For PDF export, see Export Reports to PDF. Step-by-step instructions: Generate FMEA Reports.

​
What are the “Effect of Failure” and “Cause of Failure” fields?

These are core FMEA analysis fields distinguishing WHAT happens (Effect) from WHY it happens (Cause). Effect of Failure (effectOfFailure) describes the consequences when the failure mode occurs (e.g., “Brake system fails to decelerate vehicle”), helping determine the Severity rating. Cause of Failure (causeOfFailure) describes the root causes triggering the failure (e.g., “Sensor calibration drift beyond tolerance”), which drives Occurrence rating and identifies prevention controls. Both fields default to “Undetermined” to prompt completion. See Define Failure Modes and Failure Mode Custom Fields.

​
FMEA Analysis Workflow

diagram
The FMEA risksheet includes 7 workflow views that progressively reveal columns as you complete each analysis phase. Start with “1-Structure” view showing only system elements and functions, then advance through “2-Function Analysis”, “3-Failure Analysis”, etc. This prevents information overload and guides systematic completion. See Use Progressive Workflow Views.