Overview
Failure Mode work items in TestAuto2 use 11 custom fields to implement AIAG-VDA FMEA methodology. These fields organize into four functional domains:
- Failure Description — What fails and why
- Risk Assessment — Pre-mitigation severity, occurrence, detection ratings
- Mitigation & Controls — Prevention and detection control descriptions
- Post-Mitigation Tracking — Effectiveness after improvements
Severity (fmSeverity) rating does not change between pre- and post-mitigation assessment. Severity reflects the consequence if the failure occurs—a property of the effect, not the control. Only occurrence and detection ratings improve through mitigation.
Failure Description Fields
| Field ID | Type | Default | Description |
|---|
effectOfFailure | Text | Undetermined | Describes the customer-visible or downstream consequences if the failure mode occurs. Explains WHAT happens when failure manifests (e.g., “Loss of braking capability”, “Sensor signal dropout”). Guides severity rating assignment—catastrophic effects receive S9-S10, minor effects receive S1-S3. |
causeOfFailure | Text | Undetermined | Free-text description of root causes that can trigger the failure mode. Identifies WHY failure occurs (e.g., “CAN bus contention during high-frequency message bursts”, “Thermal stress on solder joint”). Used to design prevention controls. Can be complemented by linked Cause work items for complex failure scenarios. |
cognitionError | Text | Undetermined | Documents human cognitive errors (thinking/decision errors) that could contribute to the failure. Part of ISO 26262-3 systematic hazard identification considering human factors. Examples: “Operator misinterprets warning signal”, “Technician incorrect calibration procedure”. Distinct from perceptionError (sensing/input errors). |
perceptionError | Text | Undetermined | Documents human perception errors (sensing/input errors) that could contribute to the failure. Covers visual, auditory, and tactile perception gaps (e.g., “Driver cannot see pedestrian due to sensor blind spot”, “Audible alarm volume insufficient in noisy environment”). Used with cognitionError to systematically analyze human error contribution. |
Risk Assessment Fields
The following fields implement the AIAG-VDA FMEA pre-mitigation risk assessment using a 1–10 rating scale:
| Field ID | Type | Default | Scale | Description |
|---|
fmSeverity | Enum (1–10) | Unrated (0) | See Severity Scale | Rates the seriousness of the failure effect on a 1–10 scale (1=minor, 10=catastrophic). Reflects inherent consequence of the failure, independent of controls. Does not change during mitigation—only occurrence and detection improve. Used in pre-mitigation RPN calculation: RPN = S × O × D. |
premitigationFMOccurrence | Enum (1–10) | Unrated (0) | See Occurrence Scale | Likelihood rating of failure occurring before controls are implemented. Assesses how frequently the root cause occurs under normal operation. Lower occurrence (1–3) indicates rare event; higher occurrence (8–10) indicates frequent occurrence. Required field for FMEA completion per traffic lights. |
premitigationDetection | Enum (1–10) | Unrated (0) | See Detection Scale | Effectiveness of current controls at detecting the failure before it reaches customer. Note inverted scale: 1 = guaranteed detection (best), 10 = no detection (worst). Reflects ability of existing design controls, process controls, or test coverage to catch the failure. Combined with severity and occurrence for RPN. |
FMEA Severity Scale (fmSeverity)
1: No effect — Barely noticeable
2: Very minor — Slight customer dissatisfaction
3: Minor — Customer notices degraded performance
4: Low — Effects below specification limit
5: Moderate — Operational degradation
6: Significant — Performance loss but functional
7: Serious — Serious operational failure or safety concern
8: Very serious — System failure with potential injury
9: Hazardous — Potential safety-critical failure
10: Catastrophic — Unsafe condition; failure to perform intended function
FMEA Occurrence Scale (premitigationFMOccurrence)
1: Remote — ≤1 in 1,000,000 parts
2: Very low — 1 in 100,000 to 1 in 500,000
3: Low — 1 in 10,000 to 1 in 100,000
4: Relatively low — 1 in 2,000 to 1 in 10,000
5: Moderate — 1 in 400 to 1 in 2,000
6: Moderately high — 1 in 80 to 1 in 400
7: High — 1 in 20 to 1 in 80
8: Very high — 1 in 8 to 1 in 20
9: Extremely high — 1 in 3 to 1 in 8
10: Failure is almost certain — Occurs in every unit or almost every unit
FMEA Detection Scale (premitigationDetection)
1: Absolute certainty of detection — 100% inspection/test effectiveness
2: Very high probability — 99% detection
3: High probability — 90–99% detection
4: Moderate to high — 80–90% detection
5: Moderate — 50–80% detection
6: Moderate to low — 30–50% detection
7: Low — 10–30% detection
8: Very low — 1–10% detection
9: Remote — <1% detection; design control unreliable
10: Detection impossible — No control exists; failure undetectable
Mitigation & Control Fields
| Field ID | Type | Default | Description |
|---|
preventionControl | Text | (empty) | Describes process controls or design actions that prevent the cause from occurring. Prevention controls eliminate the root cause upstream (e.g., “Add redundant sensor input validation”, “Implement CAN bus prioritization protocol”, “Design thermal management with 20°C margin”). More effective than detection controls—reduces occurrence rating. Document specific design changes, process steps, or validation criteria. |
detectionControl | Text | (empty) | Describes controls that detect the failure after it occurs but before reaching the customer. Detection controls mitigate effects through warning, isolation, or shutdown (e.g., “Add watchdog timer for processor hang detection”, “Implement hardware safety check on CAN message validity”, “Add pressure sensor limit check with automatic brake release”). Lower effectiveness than prevention—improves detection rating but not occurrence. |
Post-Mitigation Assessment Fields
After implementing prevention and detection controls, update the following fields to demonstrate risk reduction:
| Field ID | Type | Default | Description |
|---|
postmitigationFMOccurrence | Enum (1–10) | Unrated (0) | Likelihood rating of failure occurring after implementing prevention controls. Reflects reduced occurrence due to root cause elimination (e.g., redundant validation reduces occurrence from 7 to 3). Used in post-mitigation RPN calculation and action priority determination. Required field for FMEA completion workflow. |
postmitigationDetection | Enum (1–10) | Unrated (0) | Effectiveness of detection controls implemented. Reflects improved detection capability after design/process improvements. Combined with post-mitigation occurrence and severity to calculate post-mitigation RPN and demonstrate risk reduction. Required to close out FMEA and transition to control plan. |
premitigationAP | Enum (H/M/L) | (unset) | Action Priority indicating urgency of mitigation before controls are implemented. Typically derived from Severity × Occurrence × Detection using AIAG FMEA-4 methodology or direct S-O-D lookup table. Common mapping: RPN ≥200 or S≥7 = H (High), RPN 50–199 = M (Medium), RPN <50 = L (Low). Guides resource allocation—H-priority actions require immediate mitigation. May be auto-calculated via Risksheet formula. |
After implementing controls, copy the pre-mitigation ratings to post-mitigation fields as a baseline, then adjust based on control effectiveness:
- Occurrence typically improves through prevention controls
- Detection improves through additional test/monitoring
- Severity remains unchanged (inherent to the effect)
Compare pre/post RPN to quantify risk reduction and justify control investments.
DFMEA vs PFMEA Field Differences
While Failure Mode work items share these core fields, Design FMEA (DFMEA) and Process FMEA (PFMEA) documents use field variants:
| Scenario | Field ID | Scale | Notes |
|---|
| DFMEA Pre-Mitigation | premitigationFMOccurrence | 1–10 | Design failure likelihood; may reference failure rate databases or historical design data |
| PFMEA Pre-Mitigation | pfmOccurrence | 1–10 | Process failure frequency; assessed from process capability studies, machine downtime, or material batch failure rates |
| DFMEA Detection | premitigationDetection | 1–10 | Effectiveness of prototype testing, design review, FEA simulation, or engineering analysis to catch design flaws |
| PFMEA Detection | pfmDetection | 1–10 | Effectiveness of process inspection, in-process testing, sample verification, or statistical process control |
The core methodology is identical; context-specific field names support domain-specific rating justification in Risksheet and report generation.
Custom Field Lifecycle
Integration with Risksheet
These custom fields map directly to Risksheet column bindings in DFMEA and PFMEA documents. Example DFMEA Risksheet configuration:
columns:
- binding: effectOfFailure
title: Effect of Failure
type: text
width: 300
- binding: fmSeverity
title: Severity
type: enum
enumRef: failureModeSeverity
- binding: premitigationFMOccurrence
title: O (Pre)
type: enum
enumRef: fmOccurrence
formula: "=IF(isBlank(value), 0, value)"
- binding: premitigationDetection
title: D (Pre)
type: enum
enumRef: fmDetection
- binding: premitigationAP
title: AP (Pre)
type: formula
formula: "=rpnToActionPriority(fmSeverity * premitigationFMOccurrence * premitigationDetection)"
readOnly: true
Risksheet automatically cascades updates: change premitigationFMOccurrence and the premitigationAP formula recalculates in real time.