SAE ARP4754B: SAE ARP4754B – Tutorial (about 60 minutes)

SAE ARP4754B is the aerospace industry's guide to developing aircraft and the systems inside them so that design mistakes are found and fixed before an aircraft is certified and flown. Aircraft manufacturers, system suppliers, systems and safety engineers, certification specialists and the designees who act for aviation authorities use it to plan development work, manage requirements, set the level of rigour for each function and show compliance. After this tutorial you will be able to explain what development assurance means, follow the top-down development process from aircraft functions to software and hardware items, and recognise the evidence an authority expects at the end.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the current edition is SAE ARP4754B, Guidelines for Development of Civil Aircraft and Systems, an Aerospace Recommended Practice (ARP) issued by SAE International on 20 December 2023 and listed as current. It was prepared by the SAE S-18 committee jointly with EUROCAE, which publishes the same guidance as EUROCAE ED-79B (December 2023, listed by EUROCAE as its latest version). Revision B replaces ARP4754A / ED-79A from December 2010. It was released in the same month as its companion safety assessment guide, ARP4761A (ED-135). Revision B is a focused update: it aligns the text with ARP4761A and takes in errata and industry comments; secondary sources describe larger changes as left for a future revision. Note for practitioners: the long-standing FAA recognition document, Advisory Circular AC 20-174 (2011), was written for Revision A, so the edition you follow on a programme must be agreed with your certification authority. Verified 2026-10-29 against the DIN Media catalogue entry for SAE ARP4754B (issue date 2023-12-20, status current) and the EUROCAE ED-79B product page.

Who it is for: systems engineers, safety engineers, requirements managers, software and hardware leads who receive requirements from the system level, quality and configuration managers, certification engineers, programme managers and procurement people who are new to civil aircraft development. It also helps people moving into aerospace from automotive, rail, defence, medical devices or drone and advanced air mobility start-ups.

Prerequisites: none. A general idea of how engineering projects are planned, specified and tested helps. Every aviation and certification term is explained the first time it appears.

By the end of this tutorial:

You will be able to explain why aircraft systems need development assurance and what ARP4754B covers and deliberately leaves to other documents.
You will be able to define the core vocabulary: function, system, item, failure condition, development assurance level (FDAL and IDAL), functional failure set, independence, derived requirement, validation, verification and process assurance.
You will be able to describe how the guidance is organised: planning, the development process, the integral processes and changes to existing aircraft.
You will be able to follow the development process from aircraft functions through system architecture to items, and back up through integration and verification.
You will be able to explain how compliance is shown to an authority, who reviews it and why there is no ARP4754B certificate for companies or people.
You will be able to apply the guidance to a realistic aircraft system and spot the decisions that drive cost and risk.
You will be able to place ARP4754B next to ARP4761A, DO-178C, DO-254, DO-297, DO-326A, ISO 26262 and IEC 61508.

Lesson 1 – Origins, purpose and scope

Why aircraft systems need a structured development approach

A modern aircraft is a network of interacting systems. Flight controls, engines and their controllers, landing gear, brakes, hydraulics, electrical power, fuel, cabin pressure, navigation and displays all depend on each other, and many of them contain computers running software and custom electronic hardware. A single airliner function, such as slowing the aircraft after landing, can involve the brakes, the thrust reversers, the spoilers, the wheel speed sensors, the flight crew displays and several computers that talk to each other.

For simple mechanical parts, engineers can estimate how often something will fail by testing and by service experience, then add redundancy until the probability of a dangerous outcome is low enough. Aviation rules for large aeroplanes (for example 14 CFR 25.1309 in the United States and CS 25.1309 in Europe) require exactly this kind of reasoning: the more severe the effect of a failure, the less likely it must be.

Complex, highly integrated systems break this simple picture. Their most dangerous weaknesses are often not random hardware failures but development errors: a missing requirement, a wrong assumption about how another system behaves, an interface that two teams understood differently, or a design that works in every test but not in an unusual combination of conditions. Such errors are built in from the start, appear in every aircraft of the type, and cannot be given a credible failure rate. Testing alone cannot prove they are absent, because a complex system has far too many possible states.

The aviation answer is development assurance. Instead of trying to measure the probability of a design error, the applicant applies a disciplined, planned set of activities, scaled to how severe the consequences would be, to find and remove errors in requirements, design and implementation. ARP4754B is the industry guidance that describes those activities at the aircraft and system level.

A short history

The first version of ARP4754, titled Certification Considerations for Highly-Integrated or Complex Aircraft Systems, was published by SAE in 1996, the same year as the safety assessment guide ARP4761. Both grew out of a joint industry and authority effort to give practical guidance for the system safety rules of large aeroplanes. Revision A, published in December 2010 under the new title Guidelines for Development of Civil Aircraft and Systems, was a major rewrite: it widened the scope from individual systems to the aircraft as a whole, introduced the split between a function development assurance level and an item development assurance level together with functional failure sets, and summarised the process objectives for each level in an appendix table. The FAA recognised Revision A through AC 20-174 in 2011, and EASA material for large aeroplanes has long referred to the ARP4754 / ED-79 guidance as well.

Revision B arrived in December 2023 alongside ARP4761A, the long-awaited update of the safety assessment guide. Its main purpose was to make the two documents fit together cleanly. The principles of function and item assurance levels were kept, while the detailed safety analysis methods, including the way levels are derived from the safety assessment, are described in ARP4761A. Revision B also corrected known errata, took in comments collected since 2010, folded authority coordination into the planning guidance and extended the modification guidance to cover reuse.

What ARP4754B covers

The guidance covers the development cycle of aircraft and of the systems that carry out aircraft functions: planning, defining functions, allocating them to systems, creating architectures, capturing and validating requirements, allocating requirements to items, integrating and verifying the result, managing configuration, assuring the process and coordinating with the certification authority. It was written with large aeroplane rules in mind (14 CFR Part 25 and CS-25), but it is also used for small aeroplanes, rotorcraft, engines and propellers, and many new entrants such as electric vertical take-off aircraft apply it too.

What it leaves to other documents

ARP4754B is deliberately a "top-of-the-pyramid" document. It hands detailed guidance to specialist documents:

software development to RTCA DO-178C / EUROCAE ED-12C;
airborne electronic hardware to RTCA DO-254 / EUROCAE ED-80;
integrated modular avionics platforms to RTCA DO-297 / EUROCAE ED-124;
airworthiness security to RTCA DO-326A / EUROCAE ED-202A;
the safety assessment methods themselves to SAE ARP4761A / EUROCAE ED-135;
in-service safety monitoring to other SAE guidance (ARP5150A and ARP5151A) and authority rules.

Aircraft structures and aerodynamics are outside its scope, as is the preparation of the master minimum equipment list (MMEL) and the configuration deviation list (CDL), for which authority guidance applies. Figure 1 shows how this family fits together.

Figure 1 – ARP4754B sits between the safety rules and the item-level documents, working hand in hand with ARP4761A.

Guidance, not law

An important point for newcomers: ARP4754B is not a regulation. It is a recommended practice written by industry and authority experts. Authorities recognise it, through advisory material, as an acceptable way to show that development errors have been adequately addressed, but an applicant may propose another method. In practice, almost every civil programme uses ARP4754 guidance because it is the shared language between manufacturers, suppliers and regulators, and because proposing an alternative means more negotiation and more risk.

Lesson 2 – Key concepts and vocabulary

ARP4754B uses words that sound familiar but have precise meanings. Learn these before reading anything else; most misunderstandings in aerospace programmes come from people using them loosely.

Aircraft function – something the aircraft must do, described independently of how it is done, such as "control lateral attitude", "decelerate on the ground" or "provide cabin pressure".
System – a combination of related items arranged to perform one or more specific functions, for example a wheel braking system or a fuel management system.
Item – a hardware or software element with its own requirements and configuration control, such as a computer, a sensor, an electronic component or a software load. Item development is where DO-178C and DO-254 take over.
Failure condition – a situation, caused by one or more failures or errors, that affects the aircraft or its occupants, together with the flight phase and conditions in which it occurs. Example: "total loss of wheel braking during landing roll".
Failure condition classification – the severity of a failure condition: catastrophic, hazardous, major, minor or no safety effect. It comes from the functional hazard assessment described in ARP4761A.
Development assurance – all the planned and systematic actions used to show, with adequate confidence, that errors in requirements, design and implementation have been identified and corrected so that the aircraft or system meets its certification basis.
Development assurance level (DAL) – a letter from A (most rigorous) to E (no assurance objectives) that sets how much rigour, independence and evidence are needed. Its value follows the severity of the failure conditions a function or item could contribute to.
Function development assurance level (FDAL) – the level assigned to a function at aircraft or system level. It governs how rigorously the requirements and architecture for that function are developed, validated and verified.
Item development assurance level (IDAL) – the level assigned to an item. It is handed to the software or hardware team and becomes the software level of DO-178C or the hardware design assurance level of DO-254.
Functional failure set (FFS) – a group of independent members (functions or items) whose combined errors or failures would lead to a given failure condition. The idea lets architecture reduce the level needed by each member.
Independence – the property that two members cannot be affected by the same error. Functional independence means the functions are specified differently, so one requirement error cannot affect both. Item development independence means the items are developed differently enough (different teams, methods, tools, technologies) that a single development error is unlikely to affect both.
Requirement – an identifiable statement of what must be done or achieved. ARP4754B distinguishes types such as safety, functional, operational, performance, physical and installation, maintainability and interface requirements, plus additional certification requirements.
Derived requirement – a requirement created by a design decision rather than traced directly from a higher-level requirement. Derived requirements must be fed back to the safety assessment because they can introduce new behaviour.
Assumption – a statement taken as true without proof at the time, for example about crew response time or the behaviour of another system. Assumptions must be recorded and later confirmed.
Validation – showing that requirements are correct and complete: are we building the right thing?
Verification – showing that the implementation meets its requirements: did we build the thing right?
Process assurance – independent checking that the plans are followed and that the planned activities and outputs actually happened.
Configuration management – identifying and controlling the requirements, designs, data and items so that every piece of evidence refers to a known version.

Levels and severity

The heart of ARP4754B is the link between severity and rigour. A function whose malfunction or loss could contribute to a catastrophic failure condition gets the most demanding level, A. Hazardous conditions lead to level B, major to C, minor to D, and functions with no safety effect get level E. Rigour here means more validation and verification methods, more independence between the people producing and checking work, more complete traceability and more formal evidence.

The level is not a quality grade and it is not chosen by the engineering team for convenience. It flows from the safety assessment. A level E function can still be engineered carefully; it simply carries no development assurance objectives for certification.

Figure 2 – Assurance levels flow from failure condition severity, through the architecture, down to software and hardware items.

Why architecture matters so much

Suppose a catastrophic failure condition can only happen if two separate functions both fail or both contain an error. If those two functions are truly independent, the chance that a single development error defeats both is much smaller than the chance that it defeats one. ARP4754B and ARP4761A therefore allow the levels of the members of a functional failure set to be lower than the level of the failure condition, within limits and only when independence is demonstrated. This is one of the most valuable and most misused parts of the guidance. Done well, it lets a team put the heaviest rigour where it matters. Done badly, it hides a common error that defeats all the "independent" members together.

Simple versus complex

Some items are simple enough to be checked completely by test and analysis, for example a switch or a basic analogue circuit with few states. Others, such as programmable logic devices and software, are too complex for that. Development assurance matters most for complex items, where errors cannot be ruled out by exhaustive testing. Part of system design is deciding which items are complex and therefore need the item-level documents.

Lesson 3 – Structure of the guidance

ARP4754B is a guidance document of roughly 170 pages. The outline below paraphrases its main topics; it does not reproduce the text or section numbering, which you should read in the purchased document itself.

Introduction, scope and the document family

The opening part explains the purpose, the intended users, the regulatory background and the relationship with the other documents shown in Figure 1. It also sets out the basic idea of development assurance and why it is needed for complex and integrated systems.

Development planning

Planning defines how the programme will meet the guidance. In Revision B it also contains the guidance on coordinating with the certification authority, which Revision A had treated as a separate integral process. Typical plans are a certification plan (the agreement with the authority), a development plan, a safety programme plan, a requirements validation plan, an implementation verification plan, a configuration management plan and a process assurance plan. Small programmes may combine them. Plans also set transition criteria: the conditions that must be met before work moves from one phase to the next, such as "requirements reviewed and baselined before detailed design starts".

The aircraft and system development process

This part describes the top-down flow: identify aircraft functions and their requirements, allocate functions to systems, develop the system architecture, allocate system requirements to items, implement the items and then integrate and verify upwards. It stresses that the process is iterative, not a strict waterfall, and that it runs in parallel with the safety assessment.

The integral processes

Integral processes run throughout the life cycle, not just at one stage. Revision A listed eight of them; in Revision B the eighth, certification and authority coordination, is described as part of development planning instead, though the activity matters as much as ever. The integral processes are:

Safety assessment – performed with the methods of ARP4761A; it feeds the development process with failure conditions, safety requirements and assurance levels, and receives back the architecture and derived requirements.
Development assurance level assignment – deciding the FDAL and IDAL values; Revision B keeps the principles and refers to ARP4761A for the detailed method.
Requirements capture – identifying and writing requirements of all types, including derived requirements and assumptions.
Requirements validation – confirming requirements and assumptions are correct and complete.
Implementation verification – confirming the implementation meets the validated requirements.
Configuration management – identification, baselines, change control and traceability of the data and items.
Process assurance – confirming that plans exist, are followed and produce the planned outputs.

Alongside them, certification and regulatory authority coordination (planning with the authority, sharing evidence and closing compliance) runs for the whole programme; Revision B places its guidance in the planning part.

Modifications to aircraft and systems

A separate part covers changes to existing aircraft and systems and, since Revision B, the reuse of existing systems, equipment and items, such as a new software release, an added function or a supplemental type certificate for a modification. The key activity is a change impact analysis: identify what the change affects, re-run the parts of the safety assessment and development process that are touched, and decide how much of the previous evidence can be reused. Reuse of previously approved systems and service experience can reduce the effort, but only with justification.

Appendices and process objectives

The guidance summarises its process objectives and outputs in tabular form, showing which apply at each assurance level and where independence is recommended. Applicants often build a compliance matrix from these objectives: one row per objective, with the plan section, the method and the evidence that satisfies it. Informative appendices give examples and further explanation. Because the tables are copyrighted and detailed, programmes work from the purchased document.

Figure 3 – The main building blocks of ARP4754B: planning with authority coordination, the development process, the integral processes and guidance for changes.

Lesson 4 – How it works in practice

Step 1 – Plan

Every programme starts with planning. The applicant (usually the aircraft type certificate holder or the company seeking a supplemental type certificate) writes a certification plan that explains the product, the certification basis, the means of compliance and how development assurance will be achieved. Suppliers write their own development and verification plans for the systems they deliver, and these flow down from the aircraft-level plans. Plans should be agreed with the authority early. A plan that the authority sees only near the end gives it no chance to raise concerns while changes are still cheap.

Step 2 – Define aircraft functions and requirements

Engineers list the aircraft functions and write their requirements, drawing on customer needs, operational scenarios, regulations and lessons from earlier aircraft. In parallel, safety engineers perform the aircraft-level functional hazard assessment (AFHA in ARP4761A terms), which identifies failure conditions for each function, classifies them and assigns preliminary FDALs. Safety requirements, such as "no single failure shall lead to total loss of braking", are captured as requirements like any other.

Step 3 – Allocate functions to systems and create the architecture

Functions are allocated to systems, and each system gets an architecture: the channels, computers, sensors, actuators, power supplies and data links that perform the functions. The architecture is where redundancy, monitoring, dissimilarity and partitioning are chosen. The safety team performs a system-level functional hazard assessment and a preliminary system safety assessment, and identifies functional failure sets. If the architecture relies on independence to reduce assurance levels, the independence claims are written down so they can be validated and later confirmed by common cause analysis.

Step 4 – Allocate requirements to items

System requirements are allocated to items. A brake control computer, for example, receives requirements for its software and for its circuit boards. Each item gets an IDAL. Design decisions create derived requirements, such as a specific monitoring threshold or a particular start-up sequence; these go back to the safety process to check they do not create new hazards. Interface requirements between items, and between systems built by different suppliers, deserve special attention because they are a classic source of errors.

Step 5 – Item development

Software teams develop to DO-178C, electronic hardware teams to DO-254, and mechanical items through normal engineering and qualification processes. ARP4754B does not tell them how to code or design circuits; it tells the system level what to give them (validated requirements, an assurance level, assumptions about the environment) and what to expect back (verified items with evidence, plus any new derived requirements).

Step 6 – Integrate and verify

Items are integrated into systems and systems into the aircraft. Verification methods include inspection and review, analysis, test and, in some cases, the use of service experience from a similar design. Testing happens at several levels: item tests, system integration benches (often called an "iron bird" for flight controls and hydraulics), aircraft ground tests and flight tests. Each requirement must be traced to the verification that shows it is met, and every verification result must refer to a known configuration.

Step 7 – Close out

The safety assessment is completed with the system and aircraft safety assessments, which show that the safety objectives are met. Process assurance confirms that the plans were followed. The applicant produces summary data, such as a development assurance or certification summary and a configuration index, and presents its compliance findings to the authority.

Figure 4 – The development process runs top-down to items and bottom-up through integration, with the safety assessment exchanging data at every stage.

Validation in more detail

Validation is the activity newcomers most often underestimate. Many accidents and serious incidents in complex systems have come from requirements that were wrong or incomplete, not from code that failed to meet its requirements. Validation asks whether each requirement is correct (it states the right thing, unambiguously) and whether the set is complete (nothing needed is missing, including behaviour in failure and abnormal situations).

Methods include traceability (each requirement is linked to a parent or justified as derived), analysis, modelling and simulation, test on prototypes or simulators, similarity with a previously validated system, and structured engineering review by people with relevant experience. The higher the assurance level, the more methods and independence are expected. Validation starts early and continues as the design matures, because requirements change. A requirements validation matrix records each requirement, the method used, the result and any open issues.

Assumptions get the same treatment. A brake system design may assume that the crew can apply the parking brake within a certain time, or that a hydraulic supply is available in certain conditions. If an assumption is wrong, every requirement built on it may be wrong. Programmes keep an assumptions register and close each assumption with evidence before certification.

Verification in more detail

Verification asks whether the implementation does what the validated requirements say. The four broad methods are review or inspection, analysis, test and service experience or similarity. Tests should be written from requirements, so that each test shows a requirement is met, and the coverage of requirements by verification is tracked. Higher levels again expect more independence: for example, the person who verifies a requirement should not be the person who implemented it.

Configuration management and process assurance

Configuration management makes the evidence trustworthy. Every requirement document, model, drawing, software load and test result carries an identifier and a version, baselines are taken at agreed points, changes go through a controlled process, and problem reports are tracked to closure. Without it, nobody can say which version of the system the test results apply to.

Process assurance is independent of the engineering work. Its staff audit activities and records against the plans, check that transition criteria were met, record deviations and confirm that corrective actions were taken. It does not re-do the engineering; it checks that the agreed process was really followed.

Roles

Typical roles include the aircraft or system chief engineer, systems engineers, safety engineers, requirements and verification engineers, configuration managers, process assurance staff and certification engineers. On the authority side there are certification teams and, in the United States, designees (individual Designated Engineering Representatives or engineers within an Organization Designation Authorization) who make findings on the authority's behalf. In Europe, design organisations hold a Design Organisation Approval from EASA and use their own independent checking function, with EASA involvement scaled to risk.

Lesson 5 – Assessment, certification and compliance

There is no ARP4754B certificate

Unlike ISO management system standards, ARP4754B has no certification scheme for organisations or people. No body issues an "ARP4754B certified" company certificate, and a training course certificate shows only that someone completed training. What is approved is the product: an aircraft type, an engine, a propeller or a modification. Compliance with the development assurance guidance is part of the evidence that the product meets its airworthiness requirements, especially the system safety rules such as 25.1309.

How compliance is shown

The applicant proposes, in the certification plan, to use ARP4754B (or another agreed revision) as the means of showing that development errors are adequately addressed. The authority reviews the plan, decides how deeply it wants to be involved, and agrees any deviations or alternative methods. During the programme, the authority or its designees review data, attend tests and audits and may examine particular systems in depth. At the end, the applicant submits summaries showing that the planned objectives were met, open problems are assessed and closed or justified, and the safety objectives are satisfied.

Suppliers are not certified separately either. A system supplier shows compliance to the aircraft manufacturer through contract requirements, plans, reviews and delivered evidence, and the manufacturer remains responsible to the authority. Many manufacturers audit their suppliers' development assurance processes before and during a programme.

Which edition is accepted

Because ARP4754B is guidance recognised through authority material, the applicable revision is part of the agreement with the authority. The FAA's AC 20-174, the classic recognition document, was issued in 2011 for Revision A, so check which revision your authority's current advisory material recognises. Many programmes certified under Revision A will continue on it, while new programmes may propose Revision B together with ARP4761A. Always state the revision in the certification plan and record any differences agreed with the authority.

Gap analysis and readiness

Organisations new to aerospace, or moving from Revision A to B, often perform a gap analysis: they compare their processes and templates with the objectives of the guidance and plan improvements. Typical gaps are weak requirements validation, unmanaged assumptions, missing independence, unclear traceability between system and item levels, and process assurance that exists only on paper. Readiness reviews before major milestones check that plans, data and staffing are in place.

What reviewers look for

Plans that match the real organisation and were agreed early.
Assurance levels derived from the safety assessment, with justified independence claims.
Complete, bidirectional traceability from aircraft functions to items and verification results.
Evidence that requirements and assumptions were validated, not just written.
Verification results tied to identified configurations.
Process assurance records showing deviations found and resolved.
Derived requirements fed back to safety and item teams.

Lesson 6 – Worked example: an electrically controlled wheel braking system

This example is illustrative. It follows a fictional company, Northwind Aero, which is developing a new mid-size business jet, and its supplier, Kestrel Systems, which provides the wheel braking system. Classifications and levels below are examples of reasoning, not values to copy.

Planning

Northwind's certification team writes the aircraft certification plan, naming ARP4754B with ARP4761A as the means of addressing development errors and safety assessment, and discusses it with the authority in early meetings. Kestrel writes a system development plan, a validation plan, a verification plan, a configuration management plan and a process assurance plan for the braking system, and Northwind reviews them. Transition criteria are agreed: for example, no detailed item design starts until the system requirements have passed a validation review.

Functions and hazards

The aircraft function is "decelerate the aircraft on the ground", shared by the wheel brakes, spoilers and thrust reversers. The aircraft functional hazard assessment identifies failure conditions such as total loss of deceleration capability during a landing roll, loss of normal braking with an alternate means still available, uncommanded braking during take-off and asymmetric braking at high speed. Northwind's safety team classifies total loss of deceleration on landing as catastrophic, which leads to an FDAL of A for the aircraft-level function. Less severe conditions receive lower classifications.

Architecture

Kestrel proposes an architecture with a normal braking mode controlled by a dual-channel brake control computer and an alternate mode using a different hydraulic supply with simpler, mostly mechanical control. Total loss of braking needs both modes to be lost. The safety team identifies a functional failure set with two members: the normal braking function and the alternate braking function.

The team argues functional independence: the alternate function is specified separately from the normal one, uses different sensors and does not depend on the brake control software. Using the level assignment guidance in ARP4761A, it proposes levels for the members that are lower than A for at least one of them, and records the independence claims as requirements to be confirmed. Common cause analysis is planned to check shared power supplies, shared hydraulic lines in the wheel well, shared installation zones and the risk of a tyre burst damaging both paths.

Requirements and derived requirements

Kestrel writes system requirements: braking performance, anti-skid behaviour, response to pilot pedal inputs, autobrake modes, monitoring and failure annunciation to the crew. Design decisions add derived requirements, for example a monitor that disconnects a channel if its two processors disagree for longer than a set time. Each derived requirement is sent back to Northwind's safety team, which checks whether a false disconnect could create a new failure condition. One review finds that a combination of monitor trips could disconnect both normal channels during landing; the safety team confirms the alternate mode covers it but adds a requirement for a crew alert.

Validation

Kestrel validates requirements by tracing each to an aircraft requirement or recording it as derived, by modelling anti-skid behaviour in simulation, and by structured reviews with Northwind pilots and engineers. The validation matrix shows one assumption still open: that the alternate hydraulic supply is available after a specific engine failure. Northwind's hydraulic team supplies analysis that closes the assumption. Because the aircraft-level function is level A, the reviews include people independent of the authors.

Items

The brake control computer's software receives its IDAL, which becomes the DO-178C software level, and its programmable logic devices receive an IDAL for DO-254. Kestrel's software team raises a question: a timing requirement for the anti-skid loop is ambiguous. The question goes back to the system level, the requirement is clarified and re-validated, and the change goes through configuration control.

Integration and verification

The software and hardware are verified at item level. Kestrel then tests the complete braking system on a rig with real valves and simulated wheels, including failure injection to confirm monitors and mode changes. Northwind tests the system on its aircraft systems bench, during ground tests and in flight tests, including rejected take-off demonstrations. Every test procedure lists the requirements it verifies and the configuration under test.

Process assurance and close-out

Kestrel's process assurance engineer audits a sample of reviews and finds that two requirement changes were made without updated validation records. Corrective action is recorded and the records are completed. At the end, Northwind completes the aircraft safety assessment and common cause analysis, confirming independence between the braking modes. Kestrel delivers a system configuration index and a development assurance summary, and Northwind includes the braking system in its compliance findings for the type certificate.

What the example shows

The architecture decision about independence had a bigger effect on cost than any later choice.
Derived requirements feeding back to safety caught a real issue early.
Validation found a wrong assumption before it became a test failure or an in-service event.
The supplier's evidence only had value because configuration management tied it to known versions.

Lesson 7 – Relationship to other standards and frameworks

ARP4754B is rarely used alone. In civil aviation it is the system-level layer above the item-level documents, and it works in a closed loop with the safety assessment guide. Outside aviation, other industries solve the same problem with their own standards, and comparing them helps people who move between sectors.

Standard	Main subject	Relationship to ARP4754B
SAE ARP4761A / ED-135	Safety assessment methods for civil aircraft and systems	Companion document; provides hazard assessments, fault tree and common cause analyses and the detailed level assignment method
RTCA DO-178C / ED-12C	Airborne software development assurance	Receives software requirements and the IDAL (software level) from the system process
RTCA DO-254 / ED-80	Airborne electronic hardware development assurance	Receives hardware requirements and the IDAL from the system process
RTCA DO-297 / ED-124	Integrated modular avionics	Covers shared computing platforms that host functions from several systems
RTCA DO-326A / ED-202A	Airworthiness security process	Adds analysis of intentional unauthorised electronic interaction alongside the safety process
ISO 26262	Functional safety of road vehicles	Similar ideas in automotive: hazard analysis, integrity levels (ASIL), requirement decomposition and V-model
IEC 61508	Functional safety of electrical, electronic and programmable systems	Generic industrial basis using safety integrity levels; aviation uses ARP4754B instead

Similarities and differences worth knowing

ISO 26262 and IEC 61508 also assign integrity levels from risk and allow requirements to be decomposed across redundant elements. People with automotive experience will recognise the idea behind functional failure sets in ASIL decomposition. The differences matter, though. Aviation development assurance is tied to an authority approval of each aircraft type, uses severity-driven levels A to E, and relies heavily on separate documents for software and hardware. Automotive functional safety relies on manufacturer self-assessment and confirmation measures rather than a government type approval of the safety process.

Systems engineering standards such as ISO/IEC/IEEE 15288 describe life cycle processes in general terms and fit well with ARP4754B, but they do not set aviation assurance levels or certification expectations. Model-based systems engineering tools can support ARP4754B well, provided the models themselves are validated and under configuration control.

The "closed loop" with safety

The single most important relationship is with ARP4761A. Development produces functions, architectures and derived requirements; safety assessment produces failure conditions, safety requirements, assurance levels and independence requirements; each feeds the other repeatedly until the design is stable and the safety objectives are shown to be met. Organisations that run the two as separate departments exchanging documents only at milestones tend to find problems late.

Common pitfalls and best practices

Common pitfalls

Treating development assurance as paperwork produced after the design is finished, instead of a process that shapes the design.
Claiming independence between members of a functional failure set to lower assurance levels without evidence, then discovering a shared sensor, power supply, requirement source or tool late in the programme.
Skipping requirements validation because "testing will catch it"; tests only check the requirements you wrote.
Letting assumptions live in engineers' heads or emails rather than in a register that is closed with evidence.
Not feeding derived requirements back to the safety assessment, so new hazards go unnoticed.
Agreeing plans with the authority too late, or changing processes without updating the plans.
Weak interface control between systems from different suppliers.
Process assurance staffed by the same people who do the engineering work.

Best practices

Run safety assessment and development as one integrated team activity with frequent exchanges.
Write clear, atomic, verifiable requirements and validate them early with independent reviewers.
Keep bidirectional traceability in a tool from aircraft functions to items and verification results.
Make independence claims explicit requirements and confirm them with common cause analysis.
Agree the certification plan, revision of the guidance and any deviations with the authority at the start.
Flow down plans, assurance levels and evidence expectations to suppliers in the contract, and audit them.
Perform a change impact analysis for every modification and reuse previous evidence only with justification.
Use simulation and models for early validation, under configuration control.

Summary and key takeaways

ARP4754B (ED-79B), issued in December 2023, is the current industry guidance for developing civil aircraft and systems with adequate development assurance.
Development assurance exists because design errors in complex systems cannot be given a credible probability; rigour is applied instead, scaled to severity.
Assurance levels A to E come from the safety assessment: FDALs for functions and IDALs for items, with independence allowing justified reductions.
Development runs top-down from aircraft functions to items and bottom-up through integration and verification, iteratively and in parallel with ARP4761A safety assessment.
Validation checks the requirements are right; verification checks the implementation meets them; both matter.
Configuration management, process assurance and authority coordination make the evidence trustworthy and acceptable.
There is no ARP4754B certificate; compliance forms part of a product approval, and the accepted revision is agreed with the authority.
Software and hardware detail belongs to DO-178C and DO-254, which receive their requirements and levels from the system process.

Reflection questions

Pick a function in a product you know. What failure conditions could it contribute to, and how severe would each be?
In an architecture you have worked on, which independence claims would be hardest to defend, and what common causes could defeat them?
How does your organisation currently validate requirements and record assumptions, and what would need to change to meet ARP4754B expectations?
If a supplier delivered a system with excellent test results but weak configuration records, what risks would you see and what would you ask for?
Your company plans a modification to an existing certified system. How would you scope the change impact analysis and decide which evidence can be reused?