ARP4761A flight-deck
ARP4761A safety assessment evidence review for flight-deck equipment
This review examines a flight-deck equipment package against ARP4761A and reports where the safety-assessment evidence does not hold together. It suits a supplier's certification or safety team, run before submittal or when a finding is open. The focus is whether the functional hazard assessment, the failure analysis beneath it, and the safety requirements fed back into the design are all present, consistent, and traceable for the crew-interface functions. You receive a standards map, a gap list, and an order for closing each open item.
When this review is needed
- A flight-deck equipment package needs its ARP4761A safety-assessment posture read before submittal.
- A hazard classification for a crew-interface failure was set early and never revisited against the current design.
- A reviewer has asked how a safety requirement traces back to the failure condition that generated it.
- A finding response depends on knowing which safety-assessment objectives the current analysis actually satisfies.
The problem
On flight-deck equipment the safety assessment turns on how a crew-interface failure is classified, and that classification depends on assumptions about crew response that are hard to pin down. A functional hazard assessment can be written early and then drift as the design evolves, so the failure analysis no longer matches the hazards it was meant to cover. Worse, the safety requirements that should feed back into the design often are not traced to the failure conditions that generated them, which is exactly what ARP4761A asks to see.
What gets reviewed
- Functional hazard assessment for the flight-deck functions and its currency against the design
- Failure analysis supporting each hazard classification
- Safety requirements traced back to the failure conditions that generated them
- Crew-response assumptions behind each hazard classification made explicit
- The link between the safety assessment and the development-assurance evidence it drives
- Configuration control so the assessed and submitted baselines match
What gets validated
- Each hazard classification reflects the current design, not an early version that has since changed
- Failure analysis supports the severity assigned to each crew-interface failure condition
- Safety requirements trace to the failure conditions that generated them
- Crew-response assumptions behind each classification are stated rather than implied
- The safety assessment and the development-assurance evidence reference a consistent function set
Evidence normally required
- The flight-deck equipment certification plan and its ARP4761A objectives
- The functional hazard assessment and supporting failure analysis
- Safety requirement sets with their origin traceability
- Crew-response assumptions used in the hazard classifications
- The development-assurance evidence the safety assessment feeds
Common discrepancies
- A hazard classification set early that no longer matches the evolved design
- A safety requirement with no trace to the failure condition it was meant to address
- A crew-response assumption that drives a severity but is never stated
- Failure analysis that supports a different function set than the safety assessment references
What is at stake
A hazard classification that no longer reflects the design invites a reviewer to reopen the whole assessment, and every downstream requirement built on it comes back into question. When safety requirements do not trace to their originating failure conditions, the feedback loop ARP4761A relies on cannot be shown, and the objective stays open until the trace is rebuilt.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Test the classification currency
Check that each hazard classification reflects the design as it stands, not an earlier version.
Surface crew-response assumptions
Make explicit the assumptions about crew action that each severity depends on.
Trace requirements to failures
Confirm each safety requirement traces back to the failure condition that generated it.
Order the closures
Sequence so a refreshed hazard assessment precedes the requirement traces that rest on it.
What the buyer receives
Who uses the output
- Safety and certification engineers assembling the flight-deck submittal
- Engineering leads deciding whether a hazard classification still holds
- Compliance managers tracking safety-objective closure before a finding response
How the work fits into the transaction or program
The review runs before submittal or after a first finding, giving the flight-deck team a clear view of whether the safety assessment still matches the design and traces cleanly to its requirements. Its closure order lets the certification plan refresh stale classifications first, before the requirement traces that depend on them.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both accept ARP4761A methods but can differ on how crew-response credit is taken in a hazard classification and how failure conditions are categorized. The review notes where a classification defensible to one authority may draw questions from the other.
Regulatory limits
The review maps evidence to ARP4761A objectives and identifies gaps. It does not set a hazard classification on the authority's behalf, agree a compliance finding, or make an airworthiness determination on the flight-deck equipment.
What this review does not cover
- Authoring the functional hazard assessment or failure analysis
- Performing DO-160G qualification or DO-178C lifecycle work
- Agreeing the safety classification with the authority
Specific to this review
- Flight-deck hazard classifications hinge on crew-response assumptions that are rarely written down, so a severity can rest on reasoning no reviewer can see.
- A functional hazard assessment written early is the most common stale artifact, because the design keeps evolving while the assessment sits untouched.
- The ARP4761A feedback loop only holds when safety requirements trace to their originating failure conditions, and that trace is the first thing to break on a package built in parallel by different teams.
Sources
SAE International. Safety assessment methods (FHA, PSSA, SSA, FTA, FMEA) supporting development assurance level assignment.
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Frequently asked questions
How does this differ from an ARP4754B review of the same equipment?
The ARP4754B review looks at development assurance, whether requirements were captured, allocated, and verified. This ARP4761A review looks at the safety assessment that generates those requirements: hazard classification, failure analysis, and the feedback into the design. They cover the same package from two connected angles.
Relevant glossary terms
Related pages
Where this fits
Talk to an engineer who has done this work
We will walk through your current state, the records or evidence involved, and a scoped first engagement.
Talk through the aircraft, records, evidence, deadline, and next useful step.