![\"Commercial](\"https:\/\/www.jamasoftware.com\/media\/2021\/04\/ARP4761A-1.png\")
<\/h1>\n<\/p>\n
<\/h1>\nTraceability 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<\/span> ARP4761A<\/span><\/a> 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.<\/span><\/p>\n 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.\u00a0<\/span><\/p>\n 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.<\/span><\/p>\n 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.<\/span><\/p>\n 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).\u00a0<\/span><\/p>\n 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.<\/span><\/p>\n ARP4761A and<\/span> ARP4754B<\/span><\/a> were<\/span> released together<\/span><\/a> in December 2023 and are intended to work as companion standards. Within the ARP4754B aircraft and system development framework,<\/span> DO-178C<\/span><\/a> and <\/span>DO-254<\/span><\/a> connect system-level safety and development requirements to item-level software and hardware development obligations.<\/span><\/p>\n ARP4754B covers the<\/span> system development<\/span><\/a> 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.<\/span><\/p>\n 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.<\/span><\/p>\n 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.<\/span><\/p>\n The FHA identifies aircraft and system functions, evaluates their failure conditions, and classifies each condition by severity. Classifications range from<\/span> Catastrophic through Hazardous<\/span><\/a>, 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.<\/span><\/p>\n 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.<\/span><\/p>\n 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<\/span> catastrophic failure probabilities<\/span><\/a> 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.<\/span><\/p>\n 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.\u00a0<\/span><\/p>\n 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.<\/span><\/p>\n 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.<\/span><\/p>\n 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.\u00a0<\/span><\/p>\n 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.<\/span><\/p>\n FMEA<\/span><\/a> 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.<\/span><\/p>\n Dependence Diagrams (DDs) and <\/span>Markov Analysis (MA)<\/span><\/a> 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.\u00a0<\/span><\/p>\n 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. <\/span>ARP4761A<\/span><\/a> groups FTA, DD, MA, and MBSA together in Section 4.1 as a family of quantitative methods.<\/span><\/p>\n 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.<\/span><\/p>\n 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.<\/span><\/p>\n Higher-assurance software and hardware items carry substantially more development and verification obligations than lower-assurance items. That difference in<\/span> verification<\/span><\/a> effort, staffing, and schedule often shapes architectural decisions during PSSA.<\/span><\/p>\n Traceability<\/span><\/a> 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.<\/span><\/p>\n 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.\u00a0<\/span><\/p>\n A failure condition probability threshold from the FHA flows through the PSSA into a system safety requirement, then into software requirements in a separate<\/span> Application Lifecycle Management<\/span><\/a> (ALM) tool. When the hazard register is a Word document and the<\/span> requirements baseline<\/span><\/a> 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.<\/span><\/p>\n 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).\u00a0<\/span><\/p>\n 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<\/span> change impact analysis<\/span><\/a>, there is no way to flag dependent documents for review when an artifact changes.<\/span><\/p>\n 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.\u00a0<\/span><\/p>\n 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<\/span> safety-critical avionics<\/span><\/a> programs, where a single late-stage architecture change can ripple through every dependent analysis.<\/span><\/p>\n Jama Connect\u00ae<\/span><\/a> 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.<\/span><\/p>\n 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\u2122 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.<\/span><\/p>\n 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.<\/span><\/p>\n 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<\/span> free 30-day trial of Jama Connect<\/span><\/a>.<\/span><\/p>\nWhat Is ARP4761A and What Changed in the 2023 Revision?<\/b><\/h2>\n
How ARP4761A Fits With ARP4754B in the Safety Lifecycle<\/b><\/h2>\n
The Relationship Between System Development and Safety Assessment<\/b><\/h3>\n
Where ARP4761A Sits in the DO-178C and DO-254 Certification Path<\/b><\/h3>\n
The Core Safety Assessment Processes in ARP4761A<\/b><\/h2>\n
Functional Hazard Assessment (FHA)<\/b><\/h3>\n
Preliminary System Safety Assessment (PSSA)<\/b><\/h3>\n
System Safety Assessment (SSA)<\/b><\/h3>\n
Common Cause Analysis (CCA)<\/b><\/h3>\n
The Analytical Methods That Support Each Process<\/b><\/h2>\n
Fault Tree Analysis (FTA)<\/b><\/h3>\n
Failure Modes and Effects Analysis (FMEA)<\/b><\/h3>\n
Dependence Diagrams (DDs) and Markov Analysis (MA)<\/b><\/h3>\n
How Development Assurance Levels Shape Assessment Rigor<\/b><\/h2>\n
Where Safety Assessment Teams Lose Traceability<\/b><\/h2>\n
Disconnected Hazard Data Across Tools and Documents<\/b><\/h3>\n
Keeping Safety Artifacts Current Through Design Change<\/b><\/h3>\n
Building Certification-Ready Safety Assessments<\/b><\/h2>\n
How Jama Connect\u00ae Supports ARP4761A Safety Assessment Structure<\/b><\/h2>\n
Keep Your ARP4761A Safety Case Certification-Ready\u00a0<\/b><\/h2>\n
Frequently Asked Questions About ARP4761<\/b><\/h2>\n
What is the difference between ARP4761 and ARP4761A?<\/b><\/h3>\n