What Is DO-254? A Guide to Design Assurance for Airborne Electronic Hardware
Aviation moves slowly when it comes to standards — and for good reason. DO-254, formally titled Design Assurance Guidance for Airborne Electronic Hardware, was published by RTCA in 2000 and accepted by the FAA via Advisory Circular AC 20-152 in 2005. More than two decades later, it remains the governing framework for certifying complex electronic hardware in commercial and military aviation.
If your avionics program includes an FPGA, ASIC, or programmable logic device, DO-254 is not optional. It defines how you demonstrate to a certification authority — the FAA, EASA, or Transport Canada — that your hardware design process is rigorous enough to be trusted in flight. This guide explains what that demonstration actually requires.
The Hardware Analog to DO-178C
Software engineers on avionics programs are typically familiar with DO-178C, the software considerations standard that governs avionics software development. DO-254 occupies the same structural role for hardware. Both standards:
- Define multiple criticality levels tied to the severity of failure conditions
- Demand documented, traceable processes rather than just verified outputs
- Require independence between development and verification at higher assurance levels
- Feed into a system-level safety process governed by ARP4754A
The parallel is intentional. On a real avionics program, the two standards don’t operate in isolation — they share system safety objectives and must produce coordinated compliance evidence. More on that interaction below.
Design Assurance Levels: DAL A Through E
DO-254 uses the same five-level Design Assurance Level (DAL) classification as DO-178C, tied directly to the failure condition categories defined in ARP4754A and SAE ARP4761.
DAL A — Catastrophic. Failure of the hardware item could cause or contribute to a catastrophic failure condition, meaning loss of the aircraft or fatalities. Full DO-254 compliance is required: complete requirements traceability, formal verification coverage, independent review at every process stage, and comprehensive configuration management.
DAL B — Hazardous/Severe-Major. Failure could cause severe injury or death to a small number of occupants, or incapacitation of crew. Most of the DAL A process rigor applies, with minor relaxations in areas like formal methods.
DAL C — Major. Failure could result in a significant reduction in safety margins or crew workload increase. Verification and traceability requirements are still substantial, but some independence requirements are relaxed relative to DAL A/B.
DAL D — Minor. Failure causes a slight reduction in safety margin or slight increase in crew workload. DO-254 applies, but with considerably reduced documentation and verification overhead.
DAL E — No Safety Effect. The standard does not impose process requirements for DAL E hardware. Most teams still apply internal quality processes, but certification authorities do not audit these items.
The DAL assignment comes from the system safety assessment — not from the hardware team. The aircraft-level failure condition analysis, conducted under ARP4761, assigns a criticality to each function. ARP4754A then allocates that criticality to systems and items. Your FPGA’s DAL is determined before your first schematic is drawn.
The Six Core Process Areas
DO-254 structures compliance around six process areas. Each has defined objectives. Your planning documents (the Hardware Plans, discussed below) commit to how you will satisfy those objectives for your specific item.
1. Requirements Capture
This is where most programs underinvest — and where audits find the most gaps. DO-254 requires that hardware requirements be:
- Derived from system-level requirements allocated to the hardware item
- Complete, unambiguous, and verifiable
- Traced bidirectionally: from system requirements down to hardware requirements, and from hardware requirements back up to system requirements
Derived requirements — requirements your hardware team generates that are not explicitly stated at the system level — must be explicitly identified and fed back into the system safety process for evaluation. Missing this feedback loop is a common DO-254 finding.
2. Conceptual Design
The conceptual design process establishes the hardware architecture from the requirements. The objective is to demonstrate that the proposed design approach can satisfy all requirements and that failure modes of the architecture have been identified. Safety analysis is introduced here — block-level failure mode analysis begins at this stage and feeds back into requirements.
3. Detailed Design
Detailed design translates the conceptual architecture into an implementable specification: HDL code structure, schematic capture, timing constraints, interface definitions. The outputs of detailed design are what implementation will build from. DO-254 requires that detailed design descriptions trace to the requirements they implement.
4. Implementation
Implementation covers the actual build: HDL coding, synthesis, place-and-route, and production of the hardware item. For FPGAs, this includes the bitstream or programming file. DO-254 treats the tools used in implementation (synthesis tools, P&R tools) as potentially introducing errors and requires either tool qualification or verification coverage sufficient to catch tool-induced errors.
5. Verification
Verification under DO-254 is process-based, not just results-based. The standard requires that verification be planned, that coverage of requirements be demonstrable, and that verification activities be independent of development activities at DAL A and B. Verification methods include:
- Review: Inspection of requirements, design descriptions, and code against defined checklists
- Analysis: Timing analysis, worst-case analysis, stress analysis
- Test: Functional simulation, hardware-in-the-loop testing, environmental qualification
Critically, verification must trace back to requirements. Every requirement must have at least one verification method assigned to it, and every verification result must trace to the requirement it covers.
6. Configuration Management
DO-254 requires that every artifact — requirements documents, design descriptions, HDL source, tool outputs, test cases, test results — be placed under configuration control. This means unique identification, change control, and the ability to reconstruct any baseline on demand. For FPGA programs, this includes the complete tool chain and associated license versions needed to reproduce a build.
The Hardware Accomplishment Summary
The Hardware Accomplishment Summary (HAS) is the compliance capstone document — the artifact your Designated Engineering Representative (DER) or certification authority reviews to confirm that all DO-254 objectives have been satisfied. The HAS does not contain all the evidence; it summarizes and indexes it.
A complete HAS covers:
- The hardware item’s identification, function, and DAL
- A summary of the Hardware Plans and any approved deviations
- A description of each process area and what was done
- A list of all compliance artifacts and where they reside
- A summary of open problem reports and their dispositions
- The tool qualification status for all critical tools
- Sign-offs from development and verification leads
The HAS is typically the last document completed on a program, but it is one of the first you should outline. Writing the HAS structure early forces clarity about what evidence you need to generate — and identifies gaps before they become schedule problems.
How DO-254 and DO-178C Interact
On any integrated avionics system, hardware and software do not certify independently. They share a common system-level safety process.
ARP4754A governs system development and defines how safety requirements are allocated to hardware and software items. The aircraft-level safety analysis (ARP4761) produces failure condition classifications. ARP4754A translates those into development assurance requirements — the DALs for hardware items and the software levels for software items.
This means your DO-254 hardware requirements have direct counterparts in the DO-178C software requirements for the processor your FPGA interfaces with. Shared interface control documents, common timing budgets, and partitioning requirements must be consistent across both compliance efforts. When a change propagates — say, a latency budget changes at the system level — both the hardware and software teams need visibility into the impact simultaneously.
Programs that treat DO-254 and DO-178C as separate workstreams managed by separate teams with separate tools routinely discover late in the program that their interface assumptions are inconsistent. The integration of the two compliance efforts lives at the system level, which is why systems engineering discipline — not just document management — is the real lever.
How Modern Tools Support DO-254 Compliance
The Requirements Traceability Problem
The most labor-intensive and audit-vulnerable part of DO-254 is requirements traceability. A DAL A FPGA on a complex avionics program may have hundreds of hardware requirements, each derived from system-level allocations, each mapped to one or more verification methods, each carrying a verification result. Managing this in a spreadsheet or a document-based requirements tool is not just inefficient — it is fragile. Any change to a system-level requirement propagates manually, and coverage gaps are invisible until an auditor finds them.
Legacy tools like IBM DOORS and DOORS Next handle traceability through link-and-attribute structures that can support DO-254, but require significant module configuration and tend to be rigid when system architecture evolves. Jama Connect and Polarion offer more modern interfaces with better review workflow support, and both are used on certified programs. Each is a legitimate option for teams already standardized on those platforms.
What Graph-Based, AI-Native Tools Add
Where the newer generation of systems engineering platforms differentiate themselves is in the connection between system-level architecture, requirement allocation, and verification status — maintained as a live model rather than a document snapshot.
Flow Engineering (flowengineering.com) takes this approach directly. Hardware requirements in Flow Engineering are nodes in a graph, with typed relationships to the system-level requirements they derive from and to the verification cases that cover them. When a system-level requirement changes, the impact on downstream hardware requirements and affected verification cases is immediately visible — not discovered through a manual change impact analysis.
For DO-254 programs, this matters in two specific ways. First, derived requirements — the requirements your FPGA team generates that aren’t explicitly in the system specification — can be captured with explicit derivation relationships, creating the upstream traceability that DO-254 auditors check first. Second, verification coverage reports are generated from the live model, not assembled from separate documents, so coverage gaps appear during development rather than during DER review.
Flow Engineering is built for systems and hardware teams, not adapted from a generic document management platform. Its focus on the systems engineering workflow — allocation, decomposition, interface definition, verification planning — maps more naturally to the DO-254 process areas than tools designed primarily for software requirements.
The deliberate trade-off is depth in configuration management: Flow Engineering is a requirements and model management platform, not a full PLM or document control system. Programs still need a separate configuration management solution for controlled hardware artifacts. That is not a gap in the tool’s intent — it is a clear scope boundary.
Practical Starting Points
If you are beginning a DO-254 program or are mid-program and finding traceability gaps, three actions have the highest return:
Start with the HAS outline. Write the shell of your Hardware Accomplishment Summary before you write your Hardware Development Plan. This forces you to inventory every compliance artifact you will need to produce and identifies where your process has holes.
Map requirement derivation explicitly. Every hardware requirement your team generates should have a documented link to the system-level requirement or safety analysis output that drove it. This is the most common audit finding and the easiest to address proactively.
Connect verification planning to requirements before implementation begins. Each requirement should have a verification method assigned — test, analysis, or review — before the detailed design phase is complete. Teams that defer verification planning until implementation is done routinely discover requirements with no coverage and no efficient path to closing the gap.
DO-254 is a demanding standard, but it is also a precise one. Its objectives are specific, its evidence requirements are defined, and the path to compliance is traceable — provided your engineering process is disciplined enough to generate and maintain the right artifacts throughout the development lifecycle.