What Is DO-254 and How Does It Govern Airborne Electronic Hardware
Aviation certification rests on the principle that you can demonstrate—not merely assert—that your hardware will behave correctly under all anticipated conditions. DO-254, formally titled Design Assurance Guidance for Airborne Electronic Hardware, is the standard that defines what that demonstration requires for electronic hardware in aircraft. Published by RTCA in 2000 and accepted by the FAA through Advisory Circular 20-152, it occupies a specific position in a broader framework of aviation standards that most engineers encounter simultaneously and often struggle to disentangle.
This article defines what DO-254 actually requires, explains how it relates to DO-178C and ARP4754A, and then gets specific about where requirements traceability sits in the compliance argument—and what that means for the tools you use.
The Standards Framework: Where DO-254 Sits
Three documents form the backbone of civil aviation certification for complex systems:
ARP4754A (Guidelines for Development of Civil Aircraft and Systems) governs the systems engineering process. It defines how aircraft-level functions are allocated to hardware and software, how failures are analyzed, and how development assurance levels are assigned. ARP4754A sits at the top of the hierarchy. It produces requirements and safety objectives that flow down to the hardware and software domains.
DO-178C (Software Considerations in Airborne Systems and Equipment Certification) governs software. It is the standard your software engineers live inside.
DO-254 governs electronic hardware—specifically what it calls complex electronic hardware. That term has a precise meaning: programmable logic devices (FPGAs, CPLDs), custom ASICs, and any other hardware whose function cannot be fully verified by exhaustive testing alone. A resistor is simple hardware. A Xilinx Zynq implementing flight control logic is not.
The relationship between the three is hierarchical and bidirectional. ARP4754A assigns development assurance levels and allocates requirements to both hardware and software. DO-254 and DO-178C then define how those requirements must be developed, implemented, and verified. When the hardware and software interact—which they always do—the two domains must trace to compatible system-level requirements and their verification results must collectively close the safety objectives defined at the system level.
A common misconception: DO-254 governs the design process, not just the hardware artifact. The FAA and EASA do not simply test your FPGA. They audit the evidence that your design process was disciplined enough to produce trustworthy hardware.
Design Assurance Levels
DO-254 inherits its assurance levels from the aircraft-level failure analysis conducted under ARP4754A and the related safety standard, SAE ARP4761. The mapping is:
| DAL | Failure Condition | Effect |
|---|---|---|
| A | Catastrophic | Could cause loss of aircraft |
| B | Hazardous | Severe reduction in safety margins or crew capacity |
| C | Major | Significant increase in crew workload or injury to passengers |
| D | Minor | Slight reduction in safety margins |
| E | No safety effect | No impact on operational capability |
DAL A imposes the full weight of DO-254 objectives. DAL D requires substantially less rigor. DAL E hardware is outside the standard’s scope entirely.
For FPGAs implementing flight-critical functions—navigation, flight control, engine monitoring—DAL A or DAL B is typical. That means you are producing a full set of lifecycle data: plans, requirements, design descriptions, validation and verification data, and a traceability structure that connects every requirement to its verification evidence.
The Hardware Design Lifecycle DO-254 Prescribes
DO-254 does not dictate a specific development methodology, but it does require that certain process objectives are satisfied. Those objectives map to a recognizable lifecycle:
1. Planning Before any design work, you produce a set of plans. The central document is the Plan for Hardware Aspects of Certification (PHAC), discussed in detail below. Supporting plans cover hardware design, validation, verification, configuration management, and quality assurance. These plans are submitted to the certification authority and, once accepted, become contractual commitments.
2. Requirements Capture Hardware requirements must be captured, traceable, and complete. DO-254 distinguishes between derived requirements—those created by the hardware designer that have no parent at the system level—and allocated requirements that flow down from the system design. Derived requirements require special handling: they must be reported to the system safety process because they represent design decisions the system engineer did not make.
3. Conceptual Design The architecture of the hardware—partitioning, interfaces, technology choices—is documented and reviewed against the requirements. Safety-relevant architectural decisions, such as protection of dissimilar redundancy, are analyzed here.
4. Detailed Design Implementation-level artifacts: schematics, FPGA RTL source files, ASIC netlist, timing constraints, power analysis. These must be placed under configuration control and traceable to requirements.
5. Implementation Manufacturing, programming, or fabrication. The process controls that ensure implementation matches design are documented.
6. Production Transition Procedures that ensure production units match the certified design baseline. This is where configuration management disciplines become operationally critical.
7. Verification Test and analysis that closes the requirements. Verification must demonstrate coverage: every requirement has at least one associated verification record, and every verification activity traces back to a requirement. Gaps are findings.
8. Configuration Management and Quality Assurance These are ongoing across the lifecycle, not a phase. DO-254 expects a configuration management system that gives you a reproducible, auditable record of what was built, when, and under what process.
The PHAC: Your Compliance Contract
The Plan for Hardware Aspects of Certification is the document that makes all the other plans coherent to a certification authority. The PHAC identifies:
- The hardware items in scope and their assigned DALs
- The lifecycle processes you commit to following
- The standards and tools used in design and verification
- The tool qualification approach, if applicable
- How you will interface with the certification authority
- How compliance with each DO-254 objective will be demonstrated
Submitting the PHAC is not a formality. FAA and EASA DERs (Designated Engineering Representatives) review it and provide feedback before significant design work is committed. A PHAC that promises a process you cannot sustain is a problem discovered late, at the worst possible time. The PHAC establishes the evidentiary framework; everything that follows must fit within it.
One practical implication: the PHAC must reflect your actual toolchain. If you capture requirements in one tool, manage design in another, and track verification in a spreadsheet, each of those needs to appear in your PHAC—and you need to explain how they interoperate and how the data remains consistent across them.
FPGAs and ASICs: Why DO-254 Exists
The standard was written specifically because FPGAs and ASICs introduced a class of hardware that could not be adequately validated by the methods used for simple electronic hardware. A 1990s-era ASIC implementing a flight management function might contain millions of logic gates. Exhaustive testing is physically impossible. The design itself—the RTL, the synthesis constraints, the timing closure—becomes the primary evidence of correctness, which means the process that produced the design must be trustworthy.
For FPGAs specifically, DO-254 adds complexity because programmability introduces the possibility of field changes. Any change to the FPGA configuration—even a one-bit fix to an unrelated register—requires re-evaluation of impact and, depending on the change, re-verification of affected functionality. This is why FPGA configuration files must be under strict configuration management with immutable identifiers.
ASICs bring different challenges: the tape-out process is irreversible, so verification completeness before silicon becomes existential. Simulation, formal verification, and static timing analysis must collectively close the requirements before the design is committed to fabrication.
Requirements Traceability: The Evidentiary Spine
Here is where the practical difficulty lives for most programs.
DO-254 Section 5.2 is explicit: hardware requirements must be traceable to the system requirements from which they were derived or allocated. DO-254 Section 6.1 is equally explicit: verification must demonstrate coverage of requirements, which means verification records must trace to requirements, which means you need a closed loop from system requirements through hardware requirements to verification results.
This is not incidental to compliance—it is the mechanism by which a certification authority can audit your argument. The question they are asking is: “How do we know that every safety-relevant function the system requires of this hardware has been verified?” Traceability is how you answer that question with evidence rather than assertion.
The failure modes for traceability in practice are predictable:
Orphaned requirements. A system requirement is allocated to hardware but never appears in the hardware requirements database. The function was implemented—it works—but there is no documented path from the system allocation to a hardware requirement to a verification record.
Untraceable verification. A test was run and passed, but it was written to cover an implementation behavior that was never formally stated as a requirement. The verification record exists but has no requirement to trace to.
Derived requirements not escalated. A hardware designer makes an architectural decision that has safety implications—say, choosing to implement a watchdog timer in logic rather than in the processor subsystem—without flagging it as a derived requirement. The system safety process never sees it.
Change propagation failures. A system requirement changes. The hardware requirement is updated. The verification is not re-run. The traceability matrix says the requirement is verified, but it is verified to the old version of the requirement.
Each of these failure modes is a finding in a DO-254 audit. Collectively, they describe the failure mode of a requirements management process built on documents and spreadsheets: the structure is correct at a point in time but degrades under change.
How Modern Platforms Support DO-254 Traceability
Traditional DO-254 programs have managed traceability through a combination of requirements management databases (IBM DOORS is the canonical example), manually maintained traceability matrices, and Word or Excel documents serving as the formal records. This approach works, but it is expensive to maintain and fragile under change.
DOORS and DOORS Next provide the requirements database and basic link management. Jama Connect adds review workflows. Polarion integrates requirements with test management. These tools have real maturity and established DER acceptance. Their limitation is that they model requirements as structured documents with links, not as nodes in a genuine graph, which means complex, multi-level traceability—system to subsystem to hardware to verification to configuration baseline—requires substantial manual discipline to maintain correctly.
A newer category of tool approaches the problem differently. Flow Engineering (flowengineering.com) is built specifically for hardware and systems engineering teams working in this space. It models requirements, design elements, and verification evidence as nodes in a connected graph rather than as documents with link lists. That distinction matters operationally: when a system requirement changes, the graph structure makes impact propagation visible immediately—you can see exactly which hardware requirements, design elements, and verification records are downstream of the change, without running a report or manually tracing links through a document tree.
For DO-254 compliance, this translates to specific capabilities: allocated requirements from ARP4754A system design flow directly into hardware requirement nodes; derived requirements are flagged and visible; verification records are linked to requirements with status that updates as tests execute; and the full traceability chain from system requirement to verification record can be extracted as an artifact for the compliance package.
Flow Engineering is intentionally focused on this domain—hardware and systems engineering for regulated industries. It is not a general-purpose ALM platform, and teams that need integrated software development workflows (CI/CD pipelines, software test management, defect tracking for code) will need to interface it with complementary tools. That is a deliberate specialization, not an omission.
Practical Starting Points
If you are entering a DO-254 program or trying to improve an existing one, the highest-leverage actions are:
Lock down your requirements taxonomy before design starts. Distinguish clearly between system-allocated requirements, hardware-derived requirements, and design constraints. These have different process handling requirements under DO-254, and conflating them creates audit findings later.
Write the PHAC for the process you can actually execute. The temptation is to write an aspirational PHAC that describes best-in-class processes. If your team cannot sustain formal configuration audits at every design milestone, do not commit to them. A PHAC that matches your actual capability is defensible. A PHAC that overpromises creates evidence gaps.
Invest in traceability tooling before the program is in full swing. The worst time to rebuild your traceability structure is during a Stage of Involvement (SOI) audit. The structure needs to be correct from the first requirements baseline.
Treat derived requirements as first-class artifacts, not footnotes. Derived requirements represent design decisions made at the hardware level that have system-level implications. Escalate them consistently and document the system safety team’s response.
Run requirement coverage reports regularly, not just at milestones. Traceability gaps are easy to close when they are small and recent. They are expensive to close when discovered during an audit.
Honest Assessment
DO-254 is not a compliance checkbox exercise that produces paperwork alongside real hardware development. It is a discipline that, done correctly, produces hardware whose behavior is genuinely understood—where the team can tell you not just that the FPGA passes all tests but why those tests constitute adequate evidence for the failure consequences at stake.
The process overhead is real. A DAL A FPGA program will generate a substantial volume of lifecycle data. That data has to be accurate, consistent, and current—which means the processes and tools that produce it need to be reliable under change, under schedule pressure, and under personnel turnover.
Requirements traceability is where that discipline becomes most visible and where the gap between capable and marginal programs is widest. A traceability structure that is built on connected, queryable data—rather than documents and manual links—is not a luxury for large programs. It is the difference between an audit you can navigate confidently and one where you are reconstructing evidence under pressure.