ARP4761A Safety Assessment Structure

Traceability gaps in a safety case lead to costly rework when certification teams discover that their Functional Hazard Assessment (FHA), Preliminary System Safety Assessment (PSSA), and System Safety Assessment (SSA) no longer align. When SAE’s S-18 committee released ARP4761A in December 2023, the document grew substantially. That growth reflects the addition of aircraft-level assessment processes that practitioners had been performing informally for years, new analytical methods such as Model-Based Safety Analysis (MBSA), and a structural reorganization with more appendices than in the original version.

For certification teams building safety evidence packages for Designated Engineering Representatives (DERs) or Federal Aviation Administration (FAA) Stage of Involvement (SOI) audits, the revision changes how safety artifacts are organized, where Development Assurance Level (DAL) assignments are documented, and which analytical methods carry formal recognition.

This article covers what changed in the 2023 revision, how the core assessment processes fit together, and where teams most often lose traceability across their safety artifacts.

What Is ARP4761A and What Changed in the 2023 Revision?

ARP4761A is an SAE Aerospace Recommended Practice for the safety assessment process on civil aircraft, systems, and equipment. The 2023 release was also designated ED-135 by the European Organisation for Civil Aviation Equipment (EUROCAE) and supersedes the original ARP4761 published in 1996.

Aircraft-level processes are now formal parts of the standard. The original standard’s single FHA is now split into an Aircraft Functional Hazard Assessment (AFHA) and a System Functional Hazard Assessment (SFHA).

Two aircraft-level processes, the Preliminary Aircraft Safety Assessment (PASA) and the Aircraft Safety Assessment (ASA), fill a gap left undefined by the original standard. ARP4761A also introduces Model-Based Safety Analysis (MBSA) and Cascading Effects Analysis (CEA) as formal analytical methods and adds a dedicated appendix for Functional DAL (FDAL) and Item DAL (IDAL) assignment. The standard’s preface notes that the AFHA, once an emerging practice, is now a standard element of the safety assessment process. The title change reflects a broader scope. “Airborne” was replaced with “Aircraft,” which positions the document more broadly across aircraft-level and system-level work.

How ARP4761A Fits With ARP4754B in the Safety Lifecycle

ARP4761A and ARP4754B were released together in December 2023 and are intended to work as companion standards. Within the ARP4754B aircraft and system development framework, DO-178C and DO-254 connect system-level safety and development requirements to item-level software and hardware development obligations.

The Relationship Between System Development and Safety Assessment

ARP4754B covers the system development lifecycle, including requirements validation, architecture definition, and verification. ARP4761A covers how teams assess the safety of their development. The interaction between them is bidirectional and iterative. ARP4754B feeds architectural definitions into ARP4761A’s safety analyses. ARP4761A feeds DAL assignments and safety requirements back into ARP4754B’s development activities. Neither standard operates in isolation, and a change in one domain’s artifacts typically triggers reassessment in the other.

Where ARP4761A Sits in the DO-178C and DO-254 Certification Path

ARP4761A safety assessment outputs determine the rigor required for airborne software development under DO-178C and airborne electronic hardware under DO-254. The FHA classifies failure conditions by severity. The PSSA allocates IDALs to specific software and hardware items based on architectural decisions. Those IDALs then dictate the number and type of objectives a DO-178C or DO-254 program must satisfy. The safety assessment chain from FHA through PSSA generates those obligations.

The Core Safety Assessment Processes in ARP4761A

ARP4761A provides guidance for the System Safety Assessment process, which is commonly applied within the broader V-model development framework defined by ARP4754B. FHA and PSSA operate top-down on the left side to evaluate preliminary designs. The SSA operates bottom-up on the right side, verifying implemented designs. Common Cause Analysis (CCA) runs iteratively across both sides throughout the lifecycle.

Functional Hazard Assessment (FHA)

The FHA identifies aircraft and system functions, evaluates their failure conditions, and classifies each condition by severity. Classifications range from Catastrophic through Hazardous, Major, and Minor, down to No Safety Effect. ARP4761A formalizes the split into AFHA at the aircraft level and SFHA at the system level, in which each system’s allocated functions are re-examined under single- and combined-failure conditions.

Preliminary System Safety Assessment (PSSA)

The PSSA tests proposed system designs against identified hazards and shapes architecture decisions. It determines how failures can cause the functional hazards identified by the FHA. It evaluates proposed architectures, supports allocation of safety objectives and development assurance levels such as FDALs and IDALs, and generates derived safety requirements. The PSSA is continuous and iterative, with high-level requirements generating lower-level ones. ARP4761A’s revision emphasizes that the PSSA is not a verification exercise performed after the fact.

System Safety Assessment (SSA)

The SSA checks whether the implemented design meets requirements established by the FHA and PSSA. It incorporates quantitative Fault Tree Analysis (FTA), Failure Modes and Effects Summary (FMES) data, and finalized CCA results to demonstrate that catastrophic failure probabilities remain below their thresholds. The SSA sits on the right side of the V-model and works bottom-up, in contrast to the top-down FHA and PSSA.

Common Cause Analysis (CCA)

CCA evaluates susceptibility to events that could simultaneously affect multiple items, defeating redundancy and independence. It comprises three sub-analyses. Zonal Safety Analysis (ZSA) examines physical compartments for hazards affecting co-located components.

Particular Risk Analysis (PRA) evaluates external hazards such as fire, lightning, or rotor burst that can affect redundant systems across zones. Common Mode Analysis (CMA) examines whether redundant components share failure modes through design errors, manufacturing, maintenance, or software. CCA outputs trace directly to implementation.

The Analytical Methods That Support Each Process

ARP4761A integrates qualitative and quantitative methods, enabling teams to connect judgment-based assessments with formal analysis. Its analytical methods are organized across Section 4 and dedicated appendices. Quantitative analysis tools are intended to complement, not replace, qualitative methods based on engineering and operational judgment.

Fault Tree Analysis (FTA)

FTA is the primary quantitative method for architecture evaluation and compliance demonstration. It is a deductive, top-down method in which FHA top-level events generate the root nodes of fault trees.

During PSSA, FTA supports architectural evaluation and failure-probability budgeting. During SSA, cutset analysis demonstrates that no single failure causes a hazardous or catastrophic condition. FTA remains one of the most commonly used methods for demonstrating quantitative compliance.

Failure Modes and Effects Analysis (FMEA)

FMEA evaluates the effect of each possible component failure from the bottom up. It is an inductive method that traces the effect of each component failure on the system and the aircraft. Component-level FMEA data is summarized into an FMES, which feeds quantitative FTA during SSA. FMEA alone is insufficient for hazard identification because it captures only dominant failure modes. It must be combined with top-down methods to provide a complete safety picture.

Dependence Diagrams (DDs) and Markov Analysis (MA)

Dependence Diagrams (DDs) and Markov Analysis (MA) address cases where fault-tree representations are insufficient. DDs represent success logic rather than failure logic and are treated as equivalents to FTA for PSSA and SSA purposes.

MA models state transitions in systems where failure order, repair interactions, or phased missions matter. MA is more computationally intensive and is typically reserved for cases where FTA or DD representations are insufficient. ARP4761A groups FTA, DD, MA, and MBSA together in Section 4.1 as a family of quantitative methods.

How Development Assurance Levels Shape Assessment Rigor

DAL assignments set the rigor of downstream development and verification work. FHA severity classification maps directly to the FDAL, which determines the minimum rigor for all downstream development. Catastrophic conditions require the highest level of assurance, followed by Hazardous, Major, Minor, and No Safety Effect.

During the PSSA, architectural decisions allow the allocation of IDALs to specific items. Where formal independence between components can be demonstrated and verified through CCA, individual items may receive lower IDALs than the function’s FDAL. Without that demonstration, IDALs default to match the FDAL. ARP4761A’s new appendix formalizes the FDAL and IDAL assignment process within the safety assessment standard itself. That procedure previously resided only in ARP4754A.

Higher-assurance software and hardware items carry substantially more development and verification obligations than lower-assurance items. That difference in verification effort, staffing, and schedule often shapes architectural decisions during PSSA.

Where Safety Assessment Teams Lose Traceability

Traceability usually breaks down at the handoffs between safety artifacts, requirements, and design changes. The ARP4761A safety assessment process is formally iterative, but the toolchains teams use to produce safety artifacts often are not.

Disconnected Hazard Data Across Tools and Documents

Disconnected tools make it easy for hazard data and requirements links to drift out of sync. FHA tables, FTA models, and FMEA spreadsheets typically live in separate tools with no automated synchronization.

A failure condition probability threshold from the FHA flows through the PSSA into a system safety requirement, then into software requirements in a separate Application Lifecycle Management (ALM) tool. When the hazard register is a Word document and the requirements baseline is in a different system, the link between the failure condition and the implementing requirement is maintained manually. That link breaks when either artifact is updated independently.

Keeping Safety Artifacts Current Through Design Change

Design changes can invalidate safety analyses faster than teams update them. A system architecture modification, such as removing a redundant path to reduce weight, invalidates the FTA most recently updated at the Preliminary Design Review (PDR).

If the SSA submitted for certification still references the pre-change architecture, the DER will identify the inconsistency. The program then faces an unplanned FTA revision and SSA update before the certification data package is accepted. Without automated change impact analysis, there is no way to flag dependent documents for review when an artifact changes.

Building Certification-Ready Safety Assessments

Certification-ready safety assessments depend on keeping every related artifact aligned as the program evolves. The 2023 revision’s addition of aircraft-level processes, MBSA and CEA, and a dedicated FDAL/IDAL appendix increases the volume and complexity of artifacts that must remain synchronized throughout a certification program.

Programs that wait until the certification data package is due to discover traceability gaps between their FHA, PSSA, and SSA artifacts face the most expensive kind of rework, unplanned analysis revision under schedule pressure. The same discipline applies to other safety-critical avionics programs, where a single late-stage architecture change can ripple through every dependent analysis.

How Jama Connect® Supports ARP4761A Safety Assessment Structure

Jama Connect® is a web-based requirements management and traceability platform for complex, regulated product development, and it addresses the specific challenge of keeping AFHA, SFHA, PSSA, SSA, and CCA artifacts aligned as designs, requirements, and verification evidence change. That alignment problem grows as more safety artifacts, downstream development items, and verification results must remain connected across every revision.

Jama Connect includes pre-built structures aligned to ARP4754B, ARP4761A, DO-178C, and DO-254 that link aircraft functions, safety requirements, downstream development items, and verification evidence in a single traceable chain. Its Live Traceability™ capability surfaces coverage gaps and suspect links before SSA or DER review, enabling upstream assessment of changes across dependent artifacts before they become inconsistencies in the certification package.

Keep Your ARP4761A Safety Case Certification-Ready

The 2023 revision rewards programs that treat the safety case as a living network of connected artifacts rather than a set of documents reconciled at milestone reviews. As aircraft-level processes and new analytical methods add more artifacts to keep synchronized, the cost of discovering misalignment late in certification climbs faster than it did under the original standard.

Jama Connect supports this workflow by maintaining traceable links among functions, hazards, requirements, and verification evidence as designs evolve, keeping the safety case review-ready rather than requiring reconstruction before a DER audit. Start a free 30-day trial of Jama Connect.

Frequently Asked Questions About ARP4761

What is the difference between ARP4761 and ARP4761A?

ARP4761A is the December 2023 revision of the original 1996 ARP4761. It formalizes aircraft-level safety assessment processes, recognizes MBSA and Cascading Effects Analysis as formal methods, and adds guidance for FDAL/IDAL assignment. The revision is designed for use alongside ARP4754B rather than the original ARP4754.

Is ARP4761A mandatory for aerospace certification?

ARP4761A is not a regulation. It is an SAE Aerospace Recommended Practice that the FAA and the European Union Aviation Safety Agency (EASA) may recognize as an accepted means of demonstrating compliance within the broader certification framework. Teams can propose alternative safety assessment methods, but they must be agreed with the relevant certification authority, making it important to keep the resulting safety evidence organized and review-ready.

How does ARP4761A relate to FAA and EASA requirements?

FAA and EASA airworthiness regulations establish the regulatory basis for aircraft safety assessment, while ARP4761A provides guidance on how applicants may perform that work. Some agency materials reference ARP4761A by name, while older guidance still cites the earlier version, creating a documentation alignment challenge for certification teams managing both.

Which analytical methods does ARP4761A recognize?

ARP4761A recognizes Fault Tree Analysis, Dependence Diagrams, Markov Analysis, and Model-Based Safety Analysis as quantitative methods, alongside FMEA and Common Cause Analysis for inductive and dependence-related assessment. Quantitative tools are intended to complement qualitative engineering judgment rather than replace it, and most programs combine top-down and bottom-up methods to cover both hazard identification and probability budgeting.

Author
Recent Posts

Mario Maldari

Director of Product and Solution Marketing at Jama Software

Mario Maldari is Director of Product and Solution Marketing at Jama Software, where he focuses on requirements management and systems engineering solutions for regulated industries. He brings over 2 decades of experience across solution architecture, technical pre-sales, and software quality, and holds patents in traceability and structured data. Before moving into product marketing, he worked directly with engineering teams to solve compliance and requirements challenges.

ARP4761A Introduction for Engineers and Managers