What Is DO-254? A Practitioner’s Guide to Airborne Hardware Design Assurance
DO-254 — formally titled Design Assurance Guidance for Airborne Electronic Hardware — is the primary guidance document that the FAA and EASA recognize as an acceptable means of compliance for complex programmable and custom electronic hardware used in aircraft. If your avionics program includes an FPGA, an ASIC, a PLD, or a custom microcontroller in a function that contributes to aircraft safety, DO-254 is the framework the certification authority expects you to follow.
Published by RTCA in 2000 (as DO-254) and mirrored by EUROCAE as ED-80, it carries the same practical weight as a regulation even though it is technically guidance. FAA Order 8110.105A, issued in 2008, formalized the expectation that DAL A and DAL B electronic hardware programs use DO-254 as their compliance framework. Most airworthiness authorities worldwide have adopted comparable positions.
Understanding what DO-254 actually requires — not just that it exists — is what separates programs that budget and plan correctly from those that discover the standard’s scope mid-certification.
What DO-254 Covers and What It Does Not
DO-254 applies specifically to complex electronic hardware. The standard defines complexity in practical terms: if you cannot exhaustively test a device by stimulating every combination of inputs, it is complex. FPGAs, ASICs, and PLDs almost always meet this threshold. A discrete relay or a passive filter does not.
The standard does not cover software. That domain belongs to DO-178C (Software Considerations in Airborne Systems and Equipment Certification). In practice, most avionics programs are subject to both standards simultaneously — the processor runs DO-178C-compliant firmware while the FPGA next to it operates under DO-254. The two standards share architectural philosophy (hierarchical requirements, life cycle planning, independence in verification) but differ significantly in their verification methods, because hardware behavior is deterministic at fabrication while software behavior is deterministic at execution.
DO-254 also does not specify design techniques. It does not tell you what HDL to use, what synthesis tool to buy, or how to partition your logic. It specifies what evidence you must produce and what processes must generate that evidence.
Design Assurance Levels: A through E
The Design Assurance Level (DAL) assigned to a piece of hardware is determined during system safety assessment, not by the hardware team. The system-level safety process — typically governed by ARP4761 — establishes the failure condition severity associated with each function. DO-254’s DAL classification then determines how much rigor the hardware development process must demonstrate.
DAL A — Catastrophic. Failure could cause loss of the aircraft. Complete DO-254 compliance is required, including independent verification of requirements, design, and test procedures. Certification authority involvement is typically expected at multiple review gates.
DAL B — Hazardous/Severe. Failure could cause serious injury or significant aircraft capability reduction. Full DO-254 process compliance required, though the certification authority involvement is somewhat less intensive than DAL A.
DAL C — Major. Failure causes significant reduction in safety margins or crew workload increase. DO-254 compliance required; some activities have reduced rigor compared to DAL A/B.
DAL D — Minor. Failure causes noticeable but manageable effects. Reduced DO-254 process rigor; planning documentation still required but verification independence requirements are relaxed.
DAL E — No Safety Effect. No DO-254 compliance required by the standard itself, though some programs apply lightweight process discipline for engineering quality reasons.
The DAL designation follows the function, not the hardware. A single FPGA implementing multiple functions may carry different DALs for different portions of its logic — a situation called design assurance level mixing — which is one of the more demanding implementation challenges the standard presents.
The Four Core Life Cycle Processes
DO-254 structures hardware development around four interrelated process areas. These are not phases in a waterfall sense — they overlap and iterate — but they have distinct objectives and required outputs.
1. Planning
Before any design work begins, DO-254 programs must produce a Hardware Development Plan (HDP), a Hardware Verification Plan (HVP), a Hardware Configuration Management Plan (HCMP), and a Hardware Process Assurance Plan (HPAP). Collectively, these plans define how every other process will be executed and how compliance will be demonstrated.
The planning documents are not bureaucratic formalities. Certification authorities review them early specifically because they establish the ground rules. A program that discovers mid-development that its verification plan doesn’t address independence requirements has a serious problem, because retroactively demonstrating independence on already-completed work is expensive and sometimes impossible.
2. Requirements Capture
DO-254 draws a sharp distinction between hardware requirements derived from the system and software level (hardware requirements flowing down from the system safety and functional decomposition) and the hardware design data that implements those requirements.
The requirements capture process must produce a documented set of hardware requirements — functional, performance, interface, safety — that can be independently traced. Each requirement must be verifiable. Requirements that cannot be verified by analysis, test, inspection, or similarity are not acceptable under DO-254, because the verification life cycle cannot close without a traceable path from the requirement to its evidence.
This is where many programs experience their first serious difficulty. System engineers often write requirements in prose that mixes rationale, constraints, and verifiable assertions without distinguishing between them. DO-254 programs need requirements that are atomic enough to be traced and specific enough to be tested.
3. Design
The design process covers everything from conceptual architecture through HDL coding, synthesis, implementation, and the resulting design data (schematics, netlists, FPGA bitfiles, layout data). DO-254 requires that design decisions be documented and traceable to the requirements they satisfy.
Design reviews are explicitly required at appropriate life cycle stages. The standard does not prescribe exactly when these occur, but the program’s planning documents must define the review points and what criteria each review evaluates. For DAL A and B, an independent review of design outputs — by personnel not responsible for the design itself — is expected.
4. Verification
Verification under DO-254 is broader than testing. The standard defines four acceptable verification methods: review, analysis, simulation, and test. The mix of methods applied to any given requirement depends on the DAL, the nature of the requirement, and what can realistically be demonstrated.
For DAL A FPGAs, requirements-based testing is the primary verification method, but it must be complemented by coverage analysis — structural coverage of the HDL (statement, branch, condition/decision coverage) to demonstrate that the test suite exercises the implemented logic adequately. Achieving coverage closure on a complex FPGA is a significant engineering effort.
Verification independence — requiring that the person checking the work is not the person who produced it — applies at DAL A and B and is one of the standard’s most operationally consequential requirements. It affects team structure, schedule, and cost.
Traceability: The Connective Tissue of DO-254 Compliance
If DO-254 has a single structural obligation that touches every other process, it is traceability. The standard requires bidirectional traceability across the entire hardware life cycle:
- System requirements → Hardware requirements: Every hardware requirement must be traceable to the system-level function or safety requirement that motivated it.
- Hardware requirements → Design: Every hardware requirement must be implemented, and the design data must indicate which requirements each design element addresses.
- Design → Verification: Every design element and every hardware requirement must be covered by verification evidence.
- Verification → Requirements: Verification results must trace back to the requirements they satisfy, demonstrating closure.
The Hardware Traceability Matrix (sometimes called the Requirements Traceability Matrix or RTM in practice) is the artifact that captures these links. In small programs, teams have historically maintained RTMs in spreadsheets. This approach is auditable in principle but fragile in practice: a requirement change on row 47 of a spreadsheet does not automatically propagate its impact to the forty-three downstream design and verification artifacts that reference it. Change impact analysis becomes a manual, error-prone search process exactly when certification schedules are most compressed.
How Modern Systems Engineering Platforms Support DO-254 Programs
The traceability and requirements management burden that DO-254 imposes is substantial, and the industry’s response to it has historically been either legacy requirements management tools built for document workflows or manual spreadsheet discipline. Neither scales well.
Document-centric tools like IBM DOORS and Jama Connect provide requirements capture and traceability, and they have genuine strengths in structured requirements authoring and review workflows. The limitation is that they model requirements as rows in a database with links attached, which makes comprehensive change impact analysis — understanding what is affected when a requirement changes — a manual query process rather than an automated graph traversal.
This is where graph-based platforms represent a meaningful architectural difference. Flow Engineering (flowengineering.com) models the entire DO-254 artifact set — system requirements, hardware requirements, design descriptions, verification procedures, test results — as nodes in a connected graph. A change to a hardware requirement doesn’t just mark the requirement as modified; it propagates through the graph, surfacing every downstream design element and verification artifact that is now suspect and requires review.
For a DAL A FPGA program where a single functional change can invalidate dozens of test procedures and coverage claims, this automated impact propagation is not a convenience feature — it is what makes change management tractable without adding weeks of manual RTM reconciliation.
Flow Engineering’s AI-assisted requirements analysis also addresses the quality problem at requirements capture, flagging ambiguous, non-verifiable, or contradictory requirements before they enter the design baseline. In DO-254 programs, requirements that enter the baseline without these defects identified create verification debt: they become the requirements that resist closure in the final certification push.
The platform is purpose-built for hardware and systems engineering teams rather than adapted from a software-centric or document-management lineage, which means the data model reflects how hardware programs actually structure their artifact hierarchies — system, subsystem, hardware item, hardware requirement, design detail — rather than forcing hardware programs into a document-paragraph model.
Practical Starting Points for DO-254 Programs
If you are standing up a DO-254 program, the following priorities will save you the most pain:
Start with DAL allocation, not with design. The system safety assessment determines DAL; the hardware team cannot self-assign. If the safety assessment is incomplete when hardware development begins, you will plan your verification program against the wrong level of rigor.
Write requirements before architecture, not simultaneously. It is tempting to begin FPGA design while requirements are still being drafted. DO-254 requires that design decisions be traceable to requirements. A design that precedes its requirements creates a retroactive documentation problem that auditors are experienced at recognizing.
Define independence early. Who verifies the requirements? Who reviews the test procedures? These cannot be the same people who wrote them at DAL A and B. Building independence into team structure from the start is far cheaper than trying to construct it after development.
Choose your requirements tooling before your first review gate. Switching requirements tools mid-program is expensive. The configuration management implications alone — versioning, baselining, and audit trail continuity — make mid-program migration painful. The tool you choose at program start will likely carry you through certification.
Plan for coverage analysis from the first HDL commit. Structural coverage on a mature FPGA design that was not written with coverage closure in mind is a significant rework risk. Establish HDL coding standards, simulation infrastructure, and coverage targets before the design is written, not after the first internal review.
Honest Assessment
DO-254 is a rigorous framework, but it is also a predictable one. Programs that struggle with it most often do so because they underestimate the planning investment required at the front end, treat traceability as a documentation task rather than an engineering practice, or allow requirements quality to degrade under schedule pressure.
The standard does not prescribe how to design good hardware. It prescribes how to demonstrate that your design process is disciplined enough to produce hardware whose behavior is assuredly correct for its safety function. That demonstration is built on requirements, traceability, and verification evidence — and investing in tooling and process discipline that keeps those three things coherent through the program’s life is the most direct path to a predictable certification outcome.