Aerospace FMEA Under AS9100 and ARP5580: Compliance, FRACAS Integration, and Criticality Analysis
SAE J1739 sits in the references section of half the aerospace FMEA articles online, but it doesn’t apply to aerospace work. J1739 is a Surface Vehicle Recommended Practice — automotive. The aerospace FMEA standard is ARP5580, and AS9100 expects suppliers to follow it (or an equivalent like MIL-STD-1629A) for safety-critical risk analysis. Practitioners migrating from automotive to aerospace, or running both lines in the same plant, hit this confusion early. This post covers what AS9100 auditors actually check, how ARP5580 differs from AIAG-VDA, where FMECA and criticality analysis fit, and how FRACAS closes the loop with field data.
Why Aerospace FMEA Isn’t SAE J1739
The naming overlap creates real audit findings. SAE J1739 is published by SAE’s ground-vehicle committee. It harmonizes with the AIAG-VDA approach — RPN or Action Priority, severity 1–10, occurrence 1–10, detection 1–10. ARP5580 is published by SAE’s aerospace committee and takes a different starting point. It’s functional-first, integrates with criticality analysis (FMECA), and is designed for non-automobile applications: aircraft, spacecraft, weapons systems, and heavy industrial equipment.
An aerospace supplier that submits a J1739-styled FMEA to a Tier 1 customer will typically get a finding. The auditor asks why the analysis follows automotive methodology when AS9100 references ARP5580 and MIL-STD-1629A. The two are not interchangeable. J1739 ranks risk with multiplicative S×O×D or AP lookup. ARP5580 expects a criticality category that derives from severity class and probability of occurrence per SAE ARP5580.
What ARP5580 Actually Covers
ARP5580 (full title: Recommended Failure Modes and Effects Analysis Practices for Non-Automobile Applications) describes the procedure for performing FMEA outside ground-vehicle automotive contexts. The document covers:
- Pre-analysis activities: FMEA planning, functional requirements analysis, ground rules (mission profile, environmental conditions, operational phases). Aerospace FMEAs often analyze the same hardware across multiple mission phases — takeoff, cruise, descent, landing — with different failure consequences in each.
- Three FMEA types: functional FMEA (analyzes the system at the function level before hardware design is complete), interface FMEA (analyzes failure modes at boundaries between subsystems or with external systems), and detailed FMEA (analyzes hardware down to the part or component level). Programs typically run all three at different phases of the development schedule.
- Post-analysis activities: failure latency analysis (whether a failure is detectable to the crew or only reveals itself at a later mission phase), FMEA verification, and documentation requirements. Latency is the aerospace-specific concept that automotive teams often don’t encounter — an undetected dormant failure that combines with a second failure later is the dual-failure scenario aerospace safety analysis is built to catch.
- Hardware, software, and process FMEA: the standard explicitly covers all three, with software FMEA increasingly important as aerospace systems become more software-defined. ARP5580’s software FMEA section parallels the approach in software FMEA for functional safety standards, though aerospace teams typically work to ARP4754A and DO-178C rather than ISO 26262.
AS9100 Risk Management Expectations
AS9100D Section 8.1.1 (Operational Risk Management) and Section 6.1 (Actions to Address Risks and Opportunities) require suppliers to identify operational risks throughout the product lifecycle. The standard doesn’t mandate a specific FMEA technique — it requires that some structured risk analysis be applied. ARP5580, MIL-STD-1629A, and equivalent functional FMEA approaches all satisfy this in practice. AS9100 auditors care about evidence that the methodology was applied consistently.
What auditors typically look for under AS9100 surveillance:
- Risk analysis traceable to design and process documentation. The FMEA references specific drawings, process specs, and operational scenarios — not generic part categories.
- Severity classifications tied to mission consequences. Aerospace severity scales typically use four categories (Catastrophic / Critical / Marginal / Negligible) rather than a 1–10 scale, mapped to MIL-STD-882E or program-specific severity definitions.
- Identified failure modes traced to control measures. Each failure mode has either a design mitigation, a process control, an inspection point, or a maintenance action assigned. Open failure modes without controls are findings.
- Criticality category for safety-critical items. Items in catastrophic or critical categories are flagged as Critical Items List (CIL) entries, with associated traceability to FRACAS, to test plans, and to the technical data package.
- FMEA review and update cadence. The FMEA is reviewed at design milestones, at production transition, and after fielded incidents. Auditors check for revision history that matches engineering change events.
Functional, Interface, and Detailed FMEA: Sequencing
The three ARP5580 FMEA types feed each other across the development timeline:
| FMEA Type | When | Inputs | Output |
|---|---|---|---|
| Functional FMEA | Concept and preliminary design phases | System functional requirements, mission profile, performance specifications | Function-level failure modes; safety-critical functions identified; allocation of reliability requirements to subsystems |
| Interface FMEA | System architecture phase | Subsystem boundary diagrams, ICDs (interface control documents), external interface specs | Failure modes at system boundaries; interface verification requirements; integration risk register |
| Detailed FMEA | Detailed design through production | Drawings, BOM, process plans, reliability data | Component-level failure modes; criticality assignments; CIL entries; control measures linked to control plans, inspection plans, and maintenance schedules |
Programs that skip the functional FMEA and go straight to detailed FMEA often miss system-level failure interactions — the failures that show up not in any single component but in how components combine. This is the aerospace analog to what automotive teams sometimes call “system FMEA gaps”.
Criticality Analysis: FMECA and the Severity-Probability Matrix
Aerospace FMEA is usually done as FMECA — Failure Mode, Effects, and Criticality Analysis. The criticality layer assigns each failure mode a category based on severity class and probability of occurrence. It’s often presented as a matrix.
The MIL-STD-1629A approach uses two methods:
- Qualitative criticality: severity class (I–IV) by probability category (A–E). A Category I severity (catastrophic) at probability A (frequent) sits in the top-left of the matrix and demands design-level mitigation. A Category IV (negligible) at probability E (improbable) sits in the bottom-right and may not require action beyond documentation.
- Quantitative criticality: criticality number Cm = β × α × λp × t, where β is the conditional probability of failure effect, α is the failure mode ratio, λp is the part failure rate, and t is the mission duration. Quantitative criticality is used when reliability data is available; qualitative is used earlier in the program when only allocation-level estimates exist.
The criticality category drives the Critical Items List. CIL entries get enhanced configuration management, dedicated test articles, and traceability through PPAP-equivalent processes. This is structurally different from AIAG-VDA AP. AP categorizes priorities into H/M/L without the explicit severity-probability matrix or the CIL handoff.
FRACAS Integration: Closing the Loop With Field Data
FRACAS — Failure Reporting, Analysis, and Corrective Action System — is where field failure data flows back into the FMEA. ARP5580 expects FMECA to be a living analysis updated when:
- A field failure occurs that wasn’t anticipated in the FMEA (new failure mode discovered)
- A field failure rate exceeds the predicted rate (occurrence revision)
- An inspection or BIT (built-in test) capability changes (detection revision)
- A design change is implemented (re-analyze affected failure modes)
- A mission profile or operational concept changes (re-evaluate severity by phase)
The auditor signal: the FMEA’s revision history correlates with FRACAS events. An FMEA untouched for three years on a fielded program either means zero FRACAS activity (unlikely for aerospace hardware) or the loop is broken. Customer-supplier FMEA sharing during audits is common. Tier 1 primes review supplier FMEAs and FRACAS records as part of supplier surveillance.
Documentation Auditors Expect
An audit-ready aerospace FMEA package, beyond the analysis itself, typically includes:
- Ground rules document: mission profile, environmental envelope, operational phases analyzed, severity and probability scale definitions, criticality matrix used
- Boundary diagrams or system block diagrams: scope of analysis, interfaces analyzed
- FMECA worksheets: the analysis itself, by hardware/software/process item
- Critical Items List (CIL): extracted Category I and II items with cross-references to test plans and configuration management
- Failure latency analysis: dormant-failure exposure assessment for each undetected failure
- FMECA verification record: review meeting minutes, peer reviews, customer review concurrence
- Action item log: open and closed risk reduction actions with closure evidence (see the post on building audit-ready closure records for the discipline aerospace shares with automotive)
- FRACAS linkage: how field data feeds back into FMEA updates, with examples of past updates triggered by field events
For teams running both aerospace and automotive product lines, the temptation is to use one toolset for both. The methodologies differ enough that a hybrid template typically satisfies neither auditor cleanly. Free FMEA software alternatives covers the tooling landscape. For the automotive standards aerospace practitioners often cross-reference, see FMEA under IATF 16949. The RPN and Action Priority calculator targets the AIAG-VDA side. Aerospace teams using ARP5580 work with criticality categories rather than RPN/AP, so the calculator is most useful when running AIAG-VDA-style supplier FMEAs alongside the ARP5580 program-level analysis.
Practitioners who cross between the two methodologies need to know which framework the customer expects, what the auditor will check for, and how the criticality and FRACAS layers replace the RPN/AP machinery they may already know.
Where to Read the Source Documents
The authoritative references for aerospace FMEA work:
- SAE ARP5580 — the recommended practice itself; current revision is the 2020 update
- International Aerospace Quality Group — AS9100 family standards and oversight; AS9100D is the current series
- MIL-STD-1629A — the original US military FMECA standard; cancelled in 1998 but still referenced contractually on many programs and used as the methodological baseline for ARP5580
Aerospace FMEA sits in a different methodological tradition than automotive AIAG-VDA work. The standards reference list, the criticality category schema, and the FRACAS feedback loop are the three structural differences worth knowing before the next AS9100 surveillance audit.