Faa System Safety

FAA System Safety Handbook

Source: FAA (US Government work, public domain) | Chapters: 7

When to use

Use this skill to run system safety as a specialty within systems engineering: framing safety risk management around stated acceptance criteria, describing the system, identifying and analyzing hazards by severity and likelihood, choosing controls down a fixed order of precedence, selecting the right analytical technique, and tracking every hazard to verified closure. It also covers the handbook's specialty domains — acquisition-lifecycle safety and contracting, software safety, test and facilities safety, commercial launch licensing, training, and field-level Operational Risk Management. It is the FAA's "how-to" companion to the policy in FAA Order 8040.4 and the Acquisition Management System.

Prerequisites: none — plain Markdown; no MCP server, API key, or licence tier needed at runtime.

How to Use This Skill

• Without arguments — load the core frameworks below: the five-step process, the risk matrix, the Safety Order of Precedence, the 5M/SHEL(L) models, the hazard-analysis activities, and the analysis-technique toolkit.
• With a topic — ask about a risk management step, a hazard-analysis activity (PHA, SSHA, SHA, O&SHA…), an analysis technique (FTA, FMECA, CCFA, Sneak Circuit, Energy Trace), the risk matrix, the order of precedence, or a specialty domain (software, launch, facilities, ORM).
• With a chapter — ch01 (foundations), ch03 (integrated hazard analysis + activities), ch04 (analysis techniques), ch07 (ORM and human factors).

Supporting files: glossary.md, patterns.md, cheatsheet.md.

One engine, many casings. The whole handbook runs one loop: describe the system, identify hazards, characterize risk by severity and likelihood, control it down the order of precedence, verify, and track to closure. Chapters 1–4 establish that engine; chapters 5–7 apply it to software, test, facilities, launch, training, and operations.

Core Frameworks & Mental Models

What system safety is (FAA framing)

In the FAA's view, system safety is a specialty within systems engineering whose job is to support program risk management — find the risks that matter, then eliminate or control them through design and procedure, in a defined order of preference, across the whole life cycle. It is made mandatory by FAA Order 8040.4 (1998) and carried into acquisition by the Acquisition Management System (AMS). The handbook is deliberately a "how-to"; the when/who/why live in the safety plans it points to (SSMP / SSPP / ISSPP). Safety is balanced against cost, schedule, and performance — there is no zero-risk goal; some risk must be accepted, and that is management's decision.

The five-step safety risk management process

Order 8040.4 frames the discipline as five steps: Plan (set the process and fix the risk-acceptability criteria up front), Identify the hazards, Analyze them by severity and likelihood, Assess them against the plan's criteria (the Comparative Safety Assessment), and Decide — with management owning the residual risk. Qualitative or quantitative assessment is allowed, with a stated preference for quantitative; assumptions must be conservative and documented.

Risk = severity × likelihood → acceptance band

A hazard is a condition that could lead to an undesired event; risk couples severity of consequence with likelihood of occurrence, and both must be characterized. The FAA AMS severity scale runs Catastrophic → Hazardous → Major → Minor → No Safety Effect; the likelihood scale runs Probable → Remote → Extremely Remote → Extremely Improbable. The two combine in a Risk Acceptability Matrix yielding High / Medium / Low bands — High is tracked until reduced, Medium is acceptable only with management review, Low needs no further tracking. (MIL-STD-882C renames the bands R1–R4.) The coupling matters: the more catastrophic the outcome, the lower its allowable probability — fix severity first, then read across to the probability the design must achieve.

The Safety Order of Precedence

The fixed hierarchy for treating any hazard: (1) design for minimum risk (eliminate by design), (2) incorporate safety devices, (3) provide warning devices, (4) develop procedures and training. Procedures/training is the least-preferred option for severe hazards and normally needs concurrence of authority. For a fielded system, redesign is often not cost-effective, so revising procedures becomes the fastest route — but it only cuts likelihood or severity, it does not remove the hazard.

System-description models: 5M and SHEL(L)

Before any risk work, describe the system. The 5M model decomposes it into Mission, Man, Machine, Management, and Media; the SHEL(L) model uses Software, Hardware, Environment, and Liveware (human). Both force the analyst to examine every element and every interface — interface matches and mismatches matter as much as the elements themselves. Description trades breadth against depth: a wide system (the NAS) gets a general description; a narrow component gets a detailed one.

The hazard-analysis activities (lifecycle order)

Seven design-phase activities run in lifecycle order: PHL (early hazard seed list carried into the RFP) → PHA (the foundational analysis, before preliminary design review) → RHA (turns hazards into design requirements) → SSHA (component → whole) → SHA (whole + interfaces → subsystem safety) → O&SHA (procedurally controlled operation/support, usually completed last) → HHA (hazardous materials). A proactive program shapes the design via the PHL before it starts; a reactive one justifies redesign after milestones.

Integrated system hazard analysis

An accident in a complex system is almost never a single failure, so neither a single technique nor a single analysis can capture the risk. Integrated system hazard analysis logically combines the separate analyses around human–machine–environment interactions — reasoned integration, not stapled reports. Risk is a chain: an initiating hazard plus contributory hazards (unsafe acts, unsafe conditions) leads to a primary catastrophic/critical event. A failed safeguard is itself a hazard. Reliability and safety are complementary but not interchangeable — a reliability failure rate is usually too coarse to satisfy a safety requirement.

The analysis-technique toolkit

Hazards present from two directions, so the techniques are chosen to cover each other's blind spots:

• Event-driven / top-down (deductive) — Fault Tree Analysis (FTA) maps failure paths down from one defined undesired event; Fault Hazard Analysis is a safety-focused subset of an FMEA.
• Consequence-driven / bottom-up (inductive) — FMEA / FMECA walk component failures up to their effects; FMECA adds a purpose-specific criticality figure of merit (hardware/software only).
• Specialty — Common Cause Failure Analysis (CCFA) extends FTA to test whether redundancy is real; Sneak Circuit Analysis finds latent conditions that misbehave with no component failing; Energy Trace inventories controlled/uncontrolled energy and seeds fault-tree top events.

Always do the qualitative pass first; quantify only when the value justifies the cost and the limits of the numbers are explicit. A recurring caution: false precision — chasing exact numbers from inexact data — is one of the field's biggest pitfalls.

Closed-loop hazard tracking

Hazard Tracking and Risk Resolution makes risk control a closed loop, gated by explicit management risk acceptance. The Safety Action Record (SAR) carries each hazard's description, causes, initial and residual risk, suggested and implemented controls, verification and validation, and the concurrences required to close it. A hazard is closed only after its controls are verified, and residual risk is knowingly accepted and documented.

Operational Risk Management (the operational counterpart)

Where the hazard analyses engineer safety into a system before it is fielded, ORM manages risk while the system is operated, run pre-emptively (e.g., before each flight). It is a six-step loop — identify, assess, analyze controls, decide, implement, supervise/review — governed by four principles (accept no unnecessary risk; decide at the level that controls the resources; accept risk only when benefits outweigh costs; integrate into planning at every level). Match rigor to the situation (time-critical / deliberate / strategic), drive controls up the user-involvement ladder toward user ownership, and measure risk directly rather than waiting on accident statistics. The 5M model and the human-as-most-variable-element framing carry into human factors and organizational data-sharing (GAIN, FOQA).

Chapter Index

Topic Index

• Acquisition lifecycle / AMS / IPDS → ch01, ch02
• ASOR / Target Level of Safety → ch02
• Behavioral-based safety / safety culture → ch01
• Comparative Safety Assessment (CSA) → ch02, ch01
• Common Cause Failure Analysis (CCFA) → ch04
• Contracting / SOW / CDRL / specification → ch02
• Contributory and initiating hazards → ch03, ch01
• Cost-versus-safety balance → ch01
• Cut sets / minimal cut sets → ch04, ch03
• DAMP / Maximum Probable Loss (MPL) → ch06
• Energy Trace → ch04
• Expected casualty → ch06
• Facilities safety / Facility Acquisition Life Cycle → ch05
• Fault Hazard Analysis → ch04
• Fault Tree Analysis (FTA) → ch04, ch03
• FMEA / FMECA → ch04, ch03
• Hazard versus risk → ch01
• Hazard analysis activities (PHL/PHA/RHA/SSHA/SHA/O&SHA/HHA) → ch03
• Hazard tracking / Safety Action Record (SAR) → ch01
• Health Hazard Assessment (HHA) → ch03
• Human factors / Total System Concept → ch07
• Integrated system hazard analysis → ch03
• Launch licensing / AST → ch06
• Operational Risk Management (ORM) → ch07
• Operational Safety Assessment (OSA / OSED / OHA) → ch02
• Order 8040.4 / policy spine → ch01
• Preliminary Hazard Analysis (PHA) → ch03, ch01
• Preliminary Hazard List (PHL) → ch03, ch01
• Reliability versus safety → ch03
• Risk matrix / acceptance bands → ch01
• Safety Order of Precedence → ch01, ch03, ch02
• Severity and likelihood scales → ch01
• SHEL(L) model → ch01
• Sneak Circuit Analysis → ch04
• Software safety / control capability / SHCM → ch05, ch06
• Software safety process (five-step) → ch05
• System Safety Program Plan (SSPP) / ISSPP → ch02, ch01
• Test and evaluation safety → ch05
• Training / learning objectives → ch06
• Voluntary safety data sharing (GAIN / FOQA / ASPRAM) → ch07
• 5M model → ch01, ch07, ch03

Supporting Files

• glossary.md — key system-safety terms, alphabetical, with chapter references
• patterns.md — reusable patterns (the five-step process, 5M/SHEL(L) description, coupling severity to probability, working the order of precedence, integrated hazard analysis, technique selection, software safety, ORM) with When / How / Trade-offs
• cheatsheet.md — quick decision rules, the five-step process, the risk matrix, the hazard-analysis activities, the technique table, acquisition hooks, and tells & smells

Scope & Limits

Covers: system safety as the FAA practiced and taught it in the System Safety Handbook (Dec 30, 2000) — the policy spine (Order 8040.4, the AMS), the five-step safety risk management process, the severity/likelihood scales and Risk Acceptability Matrix, the Safety Order of Precedence, the 5M and SHEL(L) system-description models, the seven hazard-analysis activities, integrated system hazard analysis, the analysis-technique toolkit (FTA, FMEA/FMECA, Fault Hazard, CCFA, Sneak Circuit, Energy Trace), closed-loop hazard tracking via the Safety Action Record, and the specialty domains the handbook addresses (acquisition-lifecycle safety and contracting, software safety, test and facilities safety, commercial launch licensing, training, and Operational Risk Management with human and organizational factors).

Thin on / does not cover: the source is a year-2000 how-to and predates the modern FAA/ICAO Safety Management System (SMS) and Just Culture regulatory frameworks — it gestures at the underlying ideas (non-punitive reporting, positive culture) but does not present SMS as later formalized. Many cited FAA orders, advisory circulars, and commercial-launch-licensing rules date to 2000 and have since been restructured — confirm current citations before relying on them. It is FAA/NAS-centric and leans heavily on MIL-STD-882C. It does not define the systems- engineering life-cycle processes themselves (use nasa-npr-7123 / dau-se-guidebook / nasa-se-handbook), nor does it reproduce third-party standard text — MIL-STD-882, RTCA DO-178B, NASA 8719.13A, and ISO/IEC/IEEE material is named and described in original words but not reprinted (for the broader landscape see se-standards-signpost; for the FAA's general SE process see faa-sem; for the defense severity matrix lineage see mil-std-882).

Source version: FAA System Safety Handbook, December 30, 2000 (the full 17-chapter handbook; this pack synthesizes it into 7 chapters). It is a US Government work in the public domain.