What Is DO-254? Design Assurance Guidance for Airborne Electronic Hardware, Explained

Aviation certification is built on evidence. Regulators don’t take your word for it that a flight control computer works correctly — they require a structured, documented process that demonstrates every design decision was intentional, every requirement was verified, and every piece of hardware you’re shipping behaves the way your requirements say it should.

For software, that discipline is codified in DO-178C. For the complex electronic hardware that software runs on — FPGAs, ASICs, programmable logic devices — it’s codified in DO-254.

If your team is designing airborne electronic hardware and you’re not already living inside DO-254, here is what the standard requires, how it parallels DO-178C, and what compliant execution actually looks like in practice.

What DO-254 Is and Why It Exists

DO-254 — formally titled Design Assurance Guidance for Airborne Electronic Hardware — was developed by RTCA in collaboration with EUROCAE (where it carries the designation ED-80) and published in 2000. The FAA formally recognized it as an acceptable means of compliance for complex electronic hardware certification in AC 20-152, and EASA followed with equivalent guidance.

The standard applies specifically to complex electronic hardware (CEH): devices whose functionality cannot be fully verified by testing alone because the state space is too large to exhaustively exercise. FPGAs, ASICs, and PLDs are the canonical examples. Simple hardware — resistors, capacitors, discrete transistors — is out of scope. The dividing line is complexity: if you can’t test your way to confidence without also relying on design process rigor, DO-254 applies.

The reason the standard exists is a pattern regulators observed as programmable logic became ubiquitous in avionics during the 1990s. Software certification processes were maturing, but hardware was being designed with ad hoc processes that didn’t generate sufficient evidence of correctness. When hardware fails in flight, the consequences are the same whether the root cause is firmware or silicon. The FAA and EASA needed a process framework that treated hardware design with the same rigor as software.

Design Assurance Levels: DAL A Through DAL E

Like DO-178C, DO-254 ties required rigor to the consequences of failure. The framework uses Design Assurance Levels (DALs), assigned through the system safety process defined in ARP4761 and allocated through the system development process in ARP4754A.

  • DAL A — Catastrophic failure condition. Loss of the hardware function could cause loss of the aircraft or fatalities. Highest level of rigor required.
  • DAL B — Hazardous/Severe-Major. Failure could cause serious injury or significantly reduce aircraft capability.
  • DAL C — Major. Failure causes significant reduction in safety margins or increases crew workload substantially.
  • DAL D — Minor. Failure causes slight reduction in safety margins, slight crew workload increase.
  • DAL E — No safety effect. DO-254 processes are not required.

The DAL assigned to a hardware item determines which DO-254 processes are mandatory, which are recommended, and how deeply each must be executed. A DAL A FPGA implementing flight control surfaces demands design reviews, formal verification methods, and complete bidirectional traceability from every requirement through every verification result. A DAL D component in a cabin entertainment system faces substantially lighter obligations.

This isn’t a loophole. The tiered structure reflects rational risk allocation. What matters is that the DAL assignment itself is justified through safety analysis — teams cannot self-assign convenient DALs without ARP4761 backing.

The Four Activity Streams of DO-254 Compliance

DO-254 organizes required activities into four coordinated streams. They run in parallel rather than sequentially, feeding artifacts into one another throughout the program.

1. Planning

Before hardware design begins, DO-254 requires documented plans that describe how each subsequent activity will be executed. The key planning documents are:

  • Hardware Development Plan (HDP): Describes the design lifecycle, methodologies, tools, and environments.
  • Hardware Validation Plan (HVP): Defines how hardware requirements will be validated against the system-level allocation.
  • Hardware Verification Plan (HVP): Defines test and analysis methods for confirming the implementation meets requirements.
  • Hardware Configuration Management Plan (HCMP): Controls baselines, change management, and traceability of artifacts.
  • Hardware Process Assurance Plan (HPAP): Describes how compliance with all other plans will be monitored.

These plans must exist and be approved before substantive design work proceeds. Regulators review them early. If your plans describe a process you aren’t actually following, you have a certification problem that no amount of late-stage test coverage will fix.

2. Design

The design stream produces the hardware item itself — from concept through to a verified implementation. DO-254 structures this as a staged process:

  • Requirements capture: Hardware requirements allocated from the system level, documented with attributes including source, rationale, and verification method.
  • Conceptual design: High-level architecture decisions, partitioning strategy, interface definitions.
  • Detailed design: RTL for FPGAs and ASICs, schematic capture for board-level hardware, implementation files that directly represent the physical hardware.
  • Implementation: Synthesis, place-and-route, final netlist for programmable devices; tape-out for ASICs.

Each transition between stages generates artifacts. The movement from requirements to conceptual design to detailed design must be traceable: you must be able to show which requirements drove which architectural decision, and which design element implements which requirement.

3. Validation

Validation answers the question: Did we build the right requirements? It’s the process of confirming that the hardware requirements correctly and completely capture what the system needs from this hardware item. This is often confused with verification, but the distinction matters:

  • Validation checks requirements against system-level intent.
  • Verification checks the implementation against requirements.

Validation activities include requirements reviews, analysis against system safety objectives, and traceability checks back to system-level allocations. A requirement that has no traceable origin in the system allocation is a red flag — it may be an orphan that was never properly derived, or it may be a hidden design decision masquerading as a requirement.

4. Verification

Verification is the largest and most visible activity stream for most hardware teams. DO-254 recognizes three primary verification methods:

  • Test: Physical hardware or simulation-based testing that exercises the implementation against requirements. The most direct form of evidence.
  • Analysis: Formal or semi-formal analytical methods — timing analysis, power analysis, fault tree analysis — where direct testing is impractical.
  • Review: Structured examination of design artifacts, code, schematics, and requirements by qualified reviewers.

Each requirement must have a designated verification method, and each verification activity must produce a result that is captured, reviewed, and linked back to the requirement it covers. Verification coverage — the percentage of requirements with verified status — is tracked throughout the program and must reach completeness before the Hardware Accomplishment Summary can be finalized.

The Hardware Accomplishment Summary

The Hardware Accomplishment Summary (HAS) is the top-level certification artifact for DO-254 compliance. It is a structured document that summarizes the entire design assurance process: what hardware was developed, what DAL was assigned and why, which plans were followed, which processes were executed, and what evidence was generated.

The HAS doesn’t contain all the evidence — it references it. It functions as the auditable index into your compliance package: reviewers use it to navigate to the underlying plans, requirements, design artifacts, test reports, and analysis results that demonstrate compliance.

A complete HAS cannot be written without complete traceability. If any requirement lacks a verified status, if any design element lacks a traceable origin requirement, or if any plan describes a process that was not demonstrably followed, the HAS cannot honestly claim compliance. The HAS is the document where gaps surface — which is why the underlying traceability infrastructure needs to be built and maintained throughout the program, not assembled at the end.

Requirements Traceability in DO-254

Traceability in DO-254 is not a documentation exercise. It is the structural spine of the entire compliance argument.

DO-254 requires bidirectional traceability across the hardware lifecycle:

  • Top-down (allocation traceability): Every hardware requirement must trace to a system-level requirement or safety objective that allocates it to the hardware item.
  • Bottom-up (coverage traceability): Every system-level requirement allocated to hardware must be addressed by at least one hardware requirement, and every hardware requirement must be addressed by at least one design element and at least one verification result.

The gaps that disqualify compliance are specific: an untraceable hardware requirement (one with no parent in the system allocation) suggests a feature that was never properly sanctioned by systems engineering. An unverified requirement (one with no associated test, analysis, or review result) is a straightforward compliance gap that a DER cannot accept.

For FPGA designs in particular, traceability extends into the implementation artifacts. RTL modules, synthesis constraints, and implementation reports all become part of the evidence chain. Teams that manage requirements in spreadsheets and manually cross-reference them to design documents learn quickly that the manual approach breaks down under the combinatorial load of a real hardware program — a mid-sized FPGA design might carry hundreds of derived requirements, each requiring multiple verification results across simulation, timing closure, and hardware-in-the-loop test.

Managing DO-254 Alongside DO-178C

Most airborne systems have both hardware and software certification obligations running in parallel. An avionic line-replaceable unit (LRU) typically contains a processor running DAL A or B software under DO-178C and one or more FPGAs or ASICs under DO-254. The system-level safety case ties them together.

The traceability problem compounds across disciplines. System requirements allocated to hardware and software must trace coherently: if a system requirement is partially implemented in firmware on an FPGA and partially in software on the application processor, both the DO-254 and DO-178C compliance packages need to account for their respective portions — and the DER reviewing the system-level HAS/SAS package needs to see how they connect.

Teams that maintain separate, disconnected requirement repositories for hardware and software — one team in DOORS, another in spreadsheets, a third in Jama — inevitably produce traceability gaps at the integration boundary. The hardware team has verified their FPGA requirements. The software team has verified their software requirements. Neither team has clean traceability showing that the system requirement that spans both was actually fully addressed.

This is where tool infrastructure matters. Flow Engineering (flowengineering.com) is built specifically for hardware and systems engineering teams managing this kind of multi-discipline requirements environment. Its graph-based model treats requirements as connected nodes rather than rows in a table, which maps naturally onto the bidirectional traceability structure that both DO-254 and DO-178C require. Hardware teams can maintain their DO-254 requirement hierarchy, verification links, and design element references alongside software teams managing their DO-178C requirements in the same connected model — with cross-discipline traces that surface integration gaps before the DER review does.

Flow Engineering’s AI-native architecture also reduces the manual overhead of maintaining traceability at scale. Derived requirements that need to link back to system allocations, verification results that need to close against open requirements, changes that propagate impact through the graph — these are the operational challenges that erode traceability discipline on long hardware programs. Tools designed around those workflows produce better compliance evidence than tools designed for general document management and adapted to certification use.

Practical Starting Points for DO-254 Programs

If you’re entering a DO-254 program or trying to recover discipline on one already underway, the highest-leverage activities are:

Establish your DAL basis first. If the DAL assignments for your hardware items aren’t grounded in a completed ARP4761 safety analysis with ARP4754A allocation, everything downstream is provisional. Fix the safety analysis before investing heavily in compliance activities that may need to be redone.

Build the requirement hierarchy from system down. Start with allocated system requirements and derive hardware requirements in a structure that preserves parent-child traceability. Orphan requirements — hardware requirements with no system-level parent — are a recurring DER objection and much harder to resolve late in a program.

Treat the HAS as a living document. Don’t save the Hardware Accomplishment Summary for the end of the program. Maintain it continuously as a summary of current compliance status. If it can’t be written today because the evidence doesn’t exist, that’s signal — not a problem to defer.

Close the loop between hardware and software teams. If your FPGA and software teams are working in disconnected tools, establish explicit cross-discipline traces for any system requirement that has both hardware and software children. Those integration boundaries are where certification surprises live.

DO-254 is demanding, but its demands are logical. The standard is asking for what good engineering practice would produce anyway: clear requirements, traceable design decisions, and evidence that the hardware does what it’s supposed to do. The compliance overhead is real, but it’s largely the overhead of documenting and organizing the work that rigorous hardware engineering requires in any case.