What Is ARP4754A? A Complete Guide to Civil Aircraft and Systems Development Assurance

A new flight control function looks straightforward in the requirements review until a safety lead asks the question that decides the program: what happens at the aircraft level if this function fails, and how does the architecture catch it before passengers do? That question pushes the discussion out of subsystem code reviews and into the integrated picture ARP4754A is built to manage.

Teams that handle that picture well rarely treat development assurance as paperwork. They use it to keep aircraft, system, hardware, and software views in sync as the design changes, since that is what certification authorities sample later. The sections below cover where ARP4754A sits in the certification stack, how its lifecycle runs, how FDAL and IDAL get assigned, and where most programs trip up.

What Is ARP4754A?

ARP4754A is the SAE guideline for developing civil aircraft and their systems, titled Guidelines for Development of Civil Aircraft and Systems. EUROCAE publishes the same content in Europe as ED-79A, and the two are technically identical, so programs usually refer to them together as ARP4754A / ED-79A.

The “A” revision came out on December 21, 2010. It works at the aircraft and system level, above DO-178C for software and DO-254 for hardware. The FAA accepts it through AC 20-174, and EASA accepts ED-79A through AMC 25.1309.

How ARP4754A Fits Inside Civil Aircraft Certification

The legal obligation on a transport airplane comes from 14 CFR § 25.1309, which applies to any equipment or system installed on a Part 25 airplane and sets the airworthiness bar for failure conditions. ARP4754A is one of the recognized methods for showing a program meets that bar. FAA Advisory Circular 20-174 recognizes ARP4754A as an acceptable method for establishing a development assurance process, and AC 25.1309-1 calls out ARP4754 and ARP4761 as acceptable means of compliance for system safety analysis. EASA references the framework through AMC 25.1309.

The framework was developed in the Part 25 context, but industry practice and program-specific certification basis have carried it into Part 23 small airplane, Part 27 and 29 rotorcraft, Part 33 engine, and Part 35 propeller programs.

The ARP4754A Development Lifecycle

ARP4754A organizes work into five development processes: planning, aircraft and system function development, allocation of functions to systems, allocation of system requirements to items, and integration with verification and validation. The standard treats these as iterative, not a strict waterfall, with findings from one process looping back to revise earlier requirements, since aircraft-level decisions and item-level evidence rarely settle in one pass.

Planning the Development Assurance Process

Planning sets the agreement on how the program produces assurance evidence and ties it back to the certification basis. The plans cover systems engineering approach, validation, verification, configuration management, and process assurance, and identify the functions, systems, and items in scope.

Aircraft and System Function Development

Aircraft-level functions describe what the airplane needs to do, independent of any system. They are refined into system-level functions and operational requirements as the architecture takes shape, producing validated, testable definitions that drive everything below.

Allocation of Functions to Systems

Functions are allocated to specific systems, with interfaces and dependencies captured. Architectural choices about redundancy, partitioning, and dissimilarity influence rigor downstream and change FDAL assignments and item-level objectives.

Allocation of System Requirements to Items

System requirements decompose into item-level requirements that flow to hardware and software teams. Derived requirements (those not directly traceable to a parent) feed back into safety assessment so new failure conditions get evaluated. The trace from aircraft function to item requirement is what auditors sample.

Integration, Verification, and Validation

Integration brings items back together at the system and aircraft levels. Validation confirms the requirements are correct, and verification confirms the implementation meets them. Both run continuously, with test management data feeding evidence packages for design review and approval.

Development Assurance Levels (FDAL and IDAL)

ARP4754A introduced the split between Functional Development Assurance Level (FDAL), assigned at the function level, and Item Development Assurance Level (IDAL), assigned to the hardware or software item that implements the function. The earlier 1996 ARP4754 used a single Design Assurance Level term; the rename clarified which applies where.

How Failure Condition Severity Maps to DAL

DAL is anchored to failure-condition severity classes from AC 25.1309-1. Each class carries a quantitative probability target per flight hour, and DAL assignment follows the worst credible failure the function produces.

Severity	Qualitative Term	Probability per Flight Hour	Mapped DAL
Catastrophic	Extremely Improbable	≤ 1 × 10⁻⁹	A
Hazardous	Extremely Remote	≤ 1 × 10⁻⁷	B
Major	Remote	< 1 × 10⁻⁵	C
Minor	Probable	> 1 × 10⁻⁵	D
No Safety Effect	n/a	n/a	E

The probability target belongs to the failure condition, not the DAL itself. The DAL is the rigor scale the program is held to, inherited from that severity class.

When IDAL Can Be Lower Than FDAL

The IDAL on an item can be lower than the parent FDAL when architectural independence is demonstrated through Common Cause Analysis. For a catastrophic function with FDAL A, decomposition has to keep at least one FDAL A member or two independent FDAL B members, with secondary items potentially at lower DAL once independence is substantiated. Dissimilar redundancy and partitioning let programs avoid pulling every item to the highest level, with real impact on cost.

Integral Processes Inside ARP4754A

Integral processes run alongside the development lifecycle and tie the assurance argument together, holding the trace, evidence, and analysis the program depends on.

Safety Assessment (FHA, PSSA, SSA, CCA)

The safety assessment process runs four interlocking activities. The Functional Hazard Assessment identifies functions, failure conditions, and severity classifications. The Preliminary System Safety Assessment evaluates proposed architectures during requirements and design, producing fault trees and common cause analyses that drive safety requirements. The System Safety Assessment then confirms the implemented design meets FHA and PSSA requirements, while Common Cause Analysis examines events that could cause hazardous or catastrophic failures across otherwise independent items.

The analytical methods (Fault Tree Analysis, Failure Modes and Effects Analysis) come from ARP4761, which runs in lockstep with ARP4754A. Programs that build safety assessment into requirements work from day one keep the safety case current as the design evolves.

Requirements Validation

Validation asks whether the right requirements have been specified. It compares each requirement against higher-level needs, regulatory expectations, and operational context using reviews, analyses, similarity arguments, and tests. Catching a wrong requirement during PSSA is far cheaper than finding it during SSA.

Implementation Verification

Verification confirms the implementation meets the specified requirements, using reviews, analyses, and tests at the system and item levels, with results traced back to the requirements they cover. ARP4754A treats verification and validation as separate processes because conflating them creates evidence gaps auditors flag.

Configuration Management and Process Assurance

Configuration management controls baselines, change tracking, and lifecycle data identification across every artifact the assurance argument depends on. Process assurance confirms the program follows its plans and that deviations are documented and approved. Both run throughout the program, not as cleanup before submittal.

ARP4754A vs. ARP4754B and Companion Standards

ARP4754A is the recognized baseline most active civil programs work under, and it sits inside a family of related documents teams encounter on a program. The table below compares it with ARP4754B and those companion standards.

Standard	Domain	Status	Relationship to ARP4754A
ARP4754A / ED-79A	Aircraft and system development assurance	Current FAA-recognized baseline (2010)	The framework this article describes
ARP4754B / ED-79B	Aircraft and system development assurance	Issued December 20, 2023	Adds Model-Based Safety Analysis, Cascading Effects Analysis, modifications guidance
ARP4761 / ARP4761A	Safety assessment methods	ARP4761 (1996), ARP4761A (December 20, 2023)	Supplies FHA/PSSA/SSA/CCA methods used inside ARP4754A
DO-178C	Airborne software	Current	IDAL flows from ARP4754A to DO-178C objectives
DO-254	Airborne electronic hardware	Current	IDAL flows from ARP4754A to hardware design assurance

ARP4761 and ARP4761A

ARP4761 has supplied the analytical methods inside ARP4754A’s safety assessment since 1996. ARP4761A was issued December 20, 2023, alongside ARP4754B, and the joint update moved detailed safety-assessment activity descriptions into ARP4761A. ARP4754B added Model-Based Safety Analysis, Cascading Effects Analysis, and a section on modifications relevant to Supplemental Type Certificate work.

Model-Based Safety Analysis runs the safety analysis on the same architecture model the design team is using, instead of a separate document, so the safety case stays in step with the design as the model changes. Cascading Effects Analysis examines how a single failure propagates through the architecture once independence assumptions are stressed, which matters when integrated systems share resources that older fault-tree work treated as independent. Together they reflect how ARP4754B handles the highly integrated, model-driven architectures most modern programs are now flying with.

DO-178C for Software

When ARP4754A allocates a system requirement to software, the IDAL determines which DO-178C objectives apply, including structural coverage depth. The ARP4754A trace continues into DO-178C so derived software requirements feed back into PSSA.

DO-254 for Hardware

When the allocation lands on complex airborne electronic hardware, the IDAL becomes the Hardware Design Assurance Level under DO-254. FAA AC 20-152A is the corresponding hardware AC, and the trace from aircraft function down to hardware test result has to stay current as derived requirements feed back into safety assessment.

Common Compliance Challenges Under ARP4754A

The recurring challenge is keeping the aircraft, system, and item pictures aligned while the design is still moving. A few patterns show up on most programs:

• Trace gaps from disconnected tools. Spreadsheets and siloed systems introduce gaps in bidirectional traceability that stay invisible until an auditor samples them, and rebuilding the trace before a review is one of the most expensive kinds of unplanned work.
• Safety assessment lagging the design. PSSA becomes a documentation step that happens after architecture is locked in, which means hazards get cataloged instead of driving requirements.
• Allocation drift at the item level. Item-level changes never make it back into FHA or PSSA, and the safety case starts describing an aircraft that no longer matches the build.

Each of these is fixable, but only if the trace stays connected day to day instead of rebuilt before each review.

How Jama Connect Supports ARP4754A Development Assurance

A safety finding lands in the middle of integration testing, and the team needs to know which functions, allocations, item requirements, and verification activities are affected before they can size the rework. When that information lives in disconnected spreadsheets and tools, the answer takes days, and the certification milestone does not wait for it.

Jama Connect® keeps aircraft functions, system requirements, item allocations, derived requirements, safety analyses, and verification evidence linked across the ARP4754A lifecycle. Live Trace Explorer™ compares required trace patterns against actual project data and surfaces coverage gaps before SSA or DER review. Pre-built frameworks aligned to ARP4754A and safety-tool integrations keep the safety case current as the design changes.

Bringing ARP4754A Traceability Under Control

ARP4754A success depends on keeping the trace from aircraft function through item-level evidence current as the program iterates. Programs that treat that trace as a daily artifact, not an audit deliverable, absorb less rework when safety findings move into PSSA and SSA updates without breaking downstream work.

The teams that handle ARP4754A well make the path from FHA through item verification visible across the program. Jama Connect keeps that trace live across requirements, design, and test, so a change at the function level updates the picture for hardware, software, and verification at once. If you want to see how that holds up on your program, start a free 30-day trial of Jama Connect.

Frequently Asked Questions About ARP4754A

Is ARP4754A mandatory for civil aircraft certification?

It is not formally mandated. FAA AC 20-174 recognizes it as an acceptable method, and EASA AMC 25.1309 references it the same way, but applicants can propose an equivalent process if they show comparable rigor. Most civil programs plan around it because it is the reference framework certification authorities expect.

What is the difference between FDAL and IDAL?

FDAL is assigned to an aircraft or system function based on the most severe failure condition it can produce, set during the FHA. IDAL is assigned to the hardware or software item that implements the function, and it can be lower than the parent FDAL when architectural independence is shown through Common Cause Analysis.

How does ARP4754A relate to ARP4761?

ARP4754A defines the development assurance framework, and ARP4761 supplies the analytical methods used inside its safety assessment process, including Fault Tree Analysis and Failure Modes and Effects Analysis. ARP4761A (December 2023) was released alongside ARP4754B to keep the coordination current.

What is new in ARP4754B compared with ARP4754A?

ARP4754B was published December 20, 2023, mainly to align with ARP4761A and clarify the boundary between system development and safety assessment. It adds Model-Based Safety Analysis, Cascading Effects Analysis, and a section on modifications to existing aircraft. ARP4754A and AC 20-174 remain the recognized baseline most programs work under.

What is the difference between validation and verification under ARP4754A?

Validation asks whether the right requirement was specified, meaning the requirement actually captures what the aircraft needs to do safely. Verification asks whether the implementation meets the requirement that was specified. ARP4754A treats them as separate processes because conflating them creates evidence gaps auditors flag during SSA review.

What is Common Cause Analysis?

Common Cause Analysis examines events that could cause failures in items the design assumes are independent, such as a shared power supply, a single development team writing two redundant channels, or a common library reused across both. CCA is the activity that substantiates the independence claims that let an IDAL fall below its parent FDAL.

This article was authored by Mario Maldari and published on May 6, 2026.