Failure Mode (failureMode)

Failure modes link upward to Failure Conditions (FHA) via a cause relationship, creating the connection between component-level failure analysis and system-level hazard assessment. They also link downward to Risk Controls (mitigation measures) and Characteristics (design parameters being analyzed).

Overview

Aspect	Details
Work Item Type	`failureMode`
Analysis Context	SFMEA, DFMEA, Failure Mode and Effects Analysis
Parent Relations	Linked to `function` (SFMEA) or `characteristic` (DFMEA); can be `causeOf` `failureCondition` (FHA)
Child Relations	Can link to `riskControl` (mitigation), `cause` (root cause), `task` (corrective action)
Module Constraints	RiskTemplates (FMEA documents)
Severity Standard	ARP 4761, DO-178C, MIL-STD-882E
Scoring Method	Risk Priority Number (RPN) or Action Priority (AP)

Core Properties

Property	Type	Default	Description
failureMode	Text	—	The specific manner of failure. Example: “Voltage regulator output exceeds upper limit” or “Sensor signal line open circuit”. Free-text description capturing the failure scenario.
effectOfFailure	Text	`Undetermined`	The immediate consequence or symptom when this failure mode occurs. Example: “FCC computation errors” or “Loss of air data to processing core”. Used to assess functional impact before mitigation.
causeOfFailure	Text	—	The root cause or mechanism driving the failure. Example: “Inadequate thermal design” or “Component manufacturing defect”. Links to `cause` work items for detailed root cause analysis (RCA).

FMEA Severity & Scoring

Property	Type	Default	Description
fmSeverity	Enum	—	Required for FMEA. Failure Mode Severity rating (1–10 scale or qualitative: Low, Medium, High, Critical). Assesses the worst-case impact if the failure occurs. ARP 4761 & DO-178C § 7.3.4.6 require severity classification. Maps to DAL allocation in FHA.
premitigationFMOccurrence	Enum	`0`	Pre-Mitigation Occurrence. Probability or frequency rating (1–10, or categories: Very Low to Very High) for failure mode occurrence before mitigation measures are implemented. Used in RPN calculation.
postmitigationFMOccurrence	Enum	`0`	Post-Mitigation Occurrence. Updated occurrence rating after risk controls (design changes, testing, monitoring) are applied. Enables before/after RPN comparison.
premitigationDetection	Enum	—	Pre-Mitigation Detection. Detectability rating (1–10, or Very High to Very Low) reflecting confidence that the failure mode will be detected before reaching the customer or operational environment. Higher values = harder to detect.
postmitigationDetection	Enum	—	Post-Mitigation Detection. Updated detection rating after implementing detection controls (automated tests, built-in test, inspections). Lower values = better detection coverage.

RPN & Action Priority

Property	Type	Default	Description
premitigationRPN	Integer	—	Pre-Mitigation Risk Priority Number. Calculated as: `Severity × Occurrence × Detection`. Range typically 1–1000. Values ≥ 100–150 flag high-priority failures requiring mitigation. Populated automatically by risksheet formula or manually entered.
postmitigationRPN	Integer	—	Post-Mitigation RPN. RPN after all risk controls are in place. Documents the effectiveness of mitigation. DO-178C § 7.3.4.7 requires tracking both pre and post values to demonstrate risk reduction.

RPN Interpretation:

High Risk (RPN ≥ 100–150): Immediate action required; escalate for engineering review.
Medium Risk (RPN 50–99): Monitor; plan mitigation or accept documented risk.
Low Risk (RPN < 50): Acceptable; document baseline for traceability.

Alternatively, some programs (especially automotive/process FMEA) use Action Priority (AP) — a categorical H/M/L rating based on severity thresholds rather than numeric RPN.

Human Factors & Aerospace-Specific Fields

Property	Type	Default	Description
cognitionError	Text	—	Cognitive Error Potential. Aerospace human factors field capturing how a flight crew or maintenance technician might misinterpret, misunderstand, or fail to recognize the failure mode during operation or maintenance. Example: “Pilot may confuse dual-sensor loss with single-channel mode” or “Technician may not verify cable integrity after installation.” Used in DO-178C § 6.2 human interface analysis.
perceptionError	Text	—	Perception Error Potential. Human factors field documenting the risk that the failure may not be perceived (noticed, seen, heard, felt) by crew or maintenance due to instrument limitations, environmental masking, or design oversights. Example: “Gradual sensor drift undetectable without trend analysis” or “Transient signal glitch masked by signal conditioning noise floor.” Critical for certification of fail-passive vs. fail-active systems.

Mitigation & Traceability Links

Risk Controls (Mitigation)

Failure modes link to Risk Controls via a mitigates relationship (typically stored as a multiItemLink in the risksheet):

Each risk control documents:

Control Type (Design, Test, Monitoring, Process improvement)
Effectiveness (how much does it reduce occurrence or detection class?)
Responsibility (design, manufacturing, support)
Status (Planned, Implemented, Verified)

Cause Chain

Root causes are linked via causeOf relationships, enabling multi-level failure analysis:

SFMEA vs. DFMEA: Function vs. Characteristic Context

Failure modes appear in two complementary FMEA tiers:

System FMEA (SFMEA)

Item Column: function (e.g., “Compute lateral autopilot commands”)
Failure Mode Example: “Autopilot function output remains at previous command value”
Scope: System-level functional failures visible to pilot or downstream subsystem
Upstream Traceability: Links to failureCondition (FHA) for safety assessment

Design FMEA (DFMEA)

Item Column: characteristic (e.g., “Voltage regulator output stability ±2V @ 28V input”)
Failure Mode Example: “Output voltage drifts +3.5V above nominal”
Scope: Component design implementation — physical properties, material, manufacturing
Downstream Traceability: Linked from SFMEA via causes role for requirements allocation

Both share the same custom field set (severity, occurrence, detection, RPN) but analyze different system levels per ARP 4761 § 3.2 and DO-178C § 5.1.

Risksheet Integration

Failure modes are the primary work item type in three risksheet templates:

1. Subsystem FMEA (SFMEA) Risksheet

Columns: Function, Failure Mode, Severity, Occurrence (pre/post), Detection (pre/post), RPN (pre/post), Risk Controls, Verification
Views:
- FMEA Analysis — Severity-driven row coloring (Red = Catastrophic, Orange = Hazardous)
- RPN Trends — Pre vs. post mitigation comparison
- Traceability (Up/Down) — Upstream SFMEA causes + downstream DFMEA effects

2. Component FMEA (DFMEA) Risksheet

Columns: Characteristic, Failure Mode, Severity, Occurrence (pre/post), Detection (pre/post), RPN (pre/post), Risk Controls, Verification
Row Hierarchy: Characteristic → Failure Mode → Cause → Control (multi-level nesting)

3. Risk Control Plan Risksheet

Columns: Risk Control Title, Type, Linked Failure Modes
Role: Centralized mitigation view across all failure modes in the project

Creation & Workflow

Typical FMEA Entry Process

Identify Failure Mode — Answer “What can fail?” for each function or characteristic.
Assess Severity — Rate worst-case impact (1–10 or Catastrophic to Minor).
Estimate Occurrence — Rate probability pre-mitigation.
Rate Detection — Assess how well current design/tests catch the failure.
Calculate Pre-RPN — Severity × Occurrence × Detection.
Assign Risk Controls — Link to mitigation measures or propose new ones.
Re-rate Occurrence & Detection — After control implementation, update post-mitigation scores.
Verify RPN Reduction — Confirm that post-RPN meets program acceptance criteria (often RPN < 100 or all controls verified).
Link to Safety Requirements — Connect high-RPN failures to derived safety requirements in PSSA (Preliminary System Safety Assessment).

Status & Verification

While the failureMode work item itself has no explicit “Status” field, linked riskControl items track mitigation completion:

Risk control status: Planned → In Progress → Implemented → Verified
The risksheet view columns “Verification” indicate whether all controls for a failure mode have been closed

Observe that premitigationOccurrence, premitigationDetection, and premitigationRPN capture the initial risk assessment (before design changes or controls). The postmitigation* fields show the residual risk after mitigation is implemented. This before/after structure is essential for DO-178C § 7.3.4.7 risk management and ARP 4761 § 3.3 PSSA traceability.

Linking to Failure Conditions (FHA)

The critical connection between FMEA and FHA is the causeOf relationship:

This link answers the question: “Which system-level failure condition could result from this component failure mode?” During FHA, each failureCondition may be caused by multiple failure modes from different subsystems, establishing the complete functional hazard causal chain.

Example Structure

{
  "id": "FM-023",
  "failureMode": "Sensor ADC output stuck at previous value",
  "effectOfFailure": "Air data input to FCC remains stale; processing core operates with outdated sensor readings",
  "causeOfFailure": "ADC input multiplexer selection line open circuit",
  "fmSeverity": 9,
  "premitigationFMOccurrence": 3,
  "postmitigationFMOccurrence": 1,
  "premitigationDetection": 5,
  "postmitigationDetection": 2,
  "premitigationRPN": 135,
  "postmitigationRPN": 18,
  "cognitionError": "Pilot may not immediately recognize sensor failure if cross-checked against standby instrument",
  "perceptionError": "Stale data condition not visible in cockpit display; requires continuous data validation logic",
  "linkedCause": "CRT-045 (Manufacturing: Solder joint fracture on mux select line)",
  "linkedControls": [
    "Implement redundant data validation: compare against prior N readings",
    "Add flight-test monitoring: detect stale data rate > X seconds",
    "Design review: specify solder joint reliability per IPC-J-STD-001"
  ],
  "linkedFailureCondition": "FC-012 (Air data invalid — Hazardous)"
}

Enumeration Values

fmSeverity (1–10 Scale)

Standard FMEA severity levels align with ARP 4761 failure condition classification:

Rating	Qualitative	ARP 4761 Mapping
9–10	Critical/Catastrophic	Catastrophic (cat) — potential loss of aircraft or multiple fatalities
7–8	High/Hazardous	Hazardous (haz) — potential serious injury or degraded safety margins
5–6	Medium/Major	Major (maj) — reduced capability; moderate inconvenience; minor injury
3–4	Low/Minor	Minor (min) — minor inconvenience; no safety impact
1–2	Very Low/No Effect	No Safety Effect (nse) — no observable impact

premitigationFMOccurrence & postmitigationFMOccurrence (1–10 Scale)

Higher values = more frequent / likely to occur.

Rating	Frequency	Likelihood
9–10	Very High	Failure almost certain during life of component (> 10% of fleet)
7–8	High	Frequent failures; multiple occurrences per aircraft (1–10% fleet)
5–6	Medium	Occasional failures (0.1–1% fleet)
3–4	Low	Rare; few failures per 100 aircraft (0.01–0.1% fleet)
1–2	Very Low	Extremely rare; < 0.01% fleet exposure

premitigationDetection & postmitigationDetection (1–10 Scale)

Higher values = harder to detect; control is less effective.

Rating	Detectability	Control Effectiveness
9–10	Not Detectable	No practical means to detect before customer impact (e.g., latent intermittent fault)
7–8	Remote	Detection requires extensive testing or post-field inspection
5–6	Moderate	Detection during normal testing or operational use
3–4	High	Good detection via design review, automated test, or visual inspection
1–2	Very High	Certain detection; failure mode prevented by design constraints or always caught

Custom Field Dependencies

The failure mode scoring fields have a hidden dependency on risksheet formulas:

The premitigationRPN and postmitigationRPN integer fields are calculated by the risksheet via JavaScript formula in most templates, but can also be manually entered for programs that use external FMEA tools or non-numeric Action Priority schemes.Always verify which calculation method your project uses (numeric RPN vs. categorical AP) before relying on automatic formulas.

Common Pitfalls

Pitfall	Impact	Prevention
Severity overrated	Inflated RPN causes unnecessary design changes; wastes resources	Calibrate severity to actual safety impact per ARP 4761; peer-review high-severity assignments
Occurrence/Detection confusion	Occurrence should reflect pre-control failure rate; Detection reflects control capability, not severity	Severity is independent. Separate: “Will it fail?” (occurrence) from “Will we catch it?” (detection)
Missing root cause link	Failure mode appears orphaned; traceability to RCA and corrective actions lost	Always populate `causeOfFailure` and link to formal `cause` work items (RCA)
RPN < 100 = acceptable	Program may overlook low-RPN failures that still violate DAL or ARP 4761 classification	Classification must be checked independently; RPN alone is insufficient for safety-critical systems
Post-RPN never updated	Cannot demonstrate risk reduction; fails DO-178C § 7.3.4.7 requirement evidence	Enforce post-mitigation RPN entry as part of control verification workflow
No link to failure condition	Breaks FMEA↔FHA traceability; gaps in hazard assessment invisible	For each SFMEA failure mode, confirm a corresponding FHA failure condition exists via `causeOf` role

A failure mode cannot be marked “closed” or “verified” until all linked risk controls have been implemented and verified. The risksheet provides a “Verification” view to track control closure status per failure mode.

Getting Started

Concepts

How-To Guides

Reference

FAQ

Overview

Core Properties

FMEA Severity & Scoring

RPN & Action Priority

Human Factors & Aerospace-Specific Fields