What Is DO-254 and How Does It Relate to Hardware Airworthiness?
If you work in avionics development, you know DO-178C. Software engineers recite its objectives, process tables, and independence requirements almost reflexively. But the hardware running underneath that software — the FPGAs processing sensor data, the ASICs managing flight-critical bus interfaces, the PLDs inside flight control actuation systems — has its own equally demanding certification standard: DO-254.
Formally titled Design Assurance Guidance for Airborne Electronic Hardware, DO-254 was published by RTCA in 2000 and accepted by the FAA via Advisory Circular AC 20-152. EASA followed with its own acceptance guidance. For any complex electronic hardware (CEH) integrated into a type-certificated aircraft, DO-254 compliance is the path through certification — and it shapes your entire development process from the moment you capture the first hardware requirement.
This article defines what DO-254 requires, how it maps to hardware development reality, and what compliance actually demands from an engineering team managing real-world avionics programs.
What DO-254 Covers — and What It Does Not
DO-254 specifically targets complex electronic hardware. The standard defines “complex” as any hardware whose correct operation cannot be fully verified by test alone — because the number of possible states or input conditions is too large to enumerate exhaustively. FPGAs and ASICs almost always meet this definition. Simple hardware (resistors, standard logic gates, a relay) can be shown to meet its requirements by inspection or test; complex hardware cannot, and that is precisely why a design assurance process is required.
The standard does not certify hardware in isolation. It defines the process that must be followed, the evidence that process must generate, and the independence requirements that must be satisfied at each lifecycle phase. A certification authority does not approve a chip or an FPGA bitstream — it approves the process that produced it and the evidence that the process was followed correctly.
Design Assurance Levels: DAL A Through E
Every piece of complex airborne electronic hardware is assigned a Design Assurance Level based on the most severe failure condition its malfunction or loss could cause. These levels trace directly to the system-level safety analysis (typically an FMEA or FTA conducted per ARP 4761):
| DAL | Failure Condition Category | Effect on Aircraft or Occupants |
|---|---|---|
| A | Catastrophic | May cause hull loss or multiple fatalities |
| B | Hazardous/Severe Major | Large reduction in safety margins, serious injury |
| C | Major | Significant reduction in safety margins |
| D | Minor | Slight reduction in safety margins |
| E | No Safety Effect | No impact on operational capability |
DAL E hardware requires essentially no DO-254 process. DAL D requires limited process evidence. DALs A through C require the full lifecycle, with DAL A additionally mandating independent review at every major phase transition and additional verification rigor that substantially increases program cost and schedule.
The DAL is assigned at the system level and flows down to the hardware item. If an FPGA implements functions at multiple DALs, the highest DAL governs the entire device — a fact that catches teams off guard when a DAL B system-level function is added late to an FPGA already designed to DAL C objectives.
The DO-254 Hardware Lifecycle
DO-254 defines a hardware lifecycle that must be planned, executed, and documented. The standard requires a Hardware Development Plan (HDP) that describes how each phase will be conducted and what outputs it will produce. The five primary development processes are:
Requirements Capture
Hardware requirements derive from system-level requirements allocated to the hardware item. At this phase, the team must document functional requirements, performance requirements, interface requirements, and safety requirements specific to the hardware item. Requirements must be unambiguous, verifiable, and traceable to their source.
This phase establishes the foundation for everything that follows. A missing requirement at this stage cannot be recovered downstream — at best, it surfaces during verification as an untested function; at worst, it reaches flight test.
Conceptual Design
Conceptual design translates requirements into a hardware architecture. Block diagrams, interface definitions, and technology selection occur here. This is also where the Hardware Safety Assessment begins — identifying derived requirements (requirements generated by the design itself that must be fed back to the system safety process) and confirming the architecture can satisfy DAL objectives.
Detailed Design
Detailed design produces schematics, HDL code (for FPGAs), ASIC RTL, netlists, and all component-level specifications. This phase must demonstrate that the detailed design satisfies all requirements captured in phase one. For FPGAs, this phase often generates the most process evidence: HDL coding standards compliance, synthesis reports, timing analysis, and power analysis all become DO-254 artifacts.
Implementation
Implementation covers fabrication, assembly, and the physical realization of the hardware. For FPGAs, this means the bitstream generation process and its configuration management. For ASICs, it means tape-out, fabrication, and incoming inspection. Implementation must be controlled, repeatable, and documented.
Verification
Verification is where requirements traceability becomes visibly load-bearing. Every hardware requirement must be verified by test, analysis, inspection, or review — and the verification method, test procedure, and test result must be traceable back to the requirement it covers. DAL A and B hardware require independent verification: the person conducting verification must be organizationally independent from the person who wrote the requirement or produced the design.
The verification phase produces the Hardware Verification Plan, Hardware Verification Procedures, and Hardware Verification Results — three documents that the DER (Designated Engineering Representative) will scrutinize directly.
Supporting Processes: The Other Half of DO-254
The five development phases above do not stand alone. DO-254 also defines supporting processes that must run concurrently:
- Configuration Management: Every artifact — requirements, design files, test results — must be under configuration control, with baselines established at phase transitions.
- Process Assurance: Someone independent of the development team must verify that the plans are being followed. This is the Quality Assurance function in DO-254 terms.
- Certification Liaison: Communication with the certification authority must be planned and documented, including a Hardware Accomplishment Summary (HAS) submitted at the end of the program.
These processes generate their own artifacts that are reviewed alongside the development evidence.
DO-254 and DO-178C: Navigating Mixed Systems
Most avionics line replaceable units contain both software and hardware. A flight management computer, for example, runs DO-178C DAL B software on a processor that may include DO-254 DAL B FPGAs or ASICs. The relationship between the two standards in that system is not incidental — it is architecturally important.
Requirements are allocated at the system level. Some go to software, some to hardware, some to both. When a software function depends on a hardware function (a timer implemented in an FPGA that a software task reads, for example), the requirement allocated to the FPGA must be captured in the DO-254 hardware requirements, and the interface between the two must be defined in both the Software Requirements Specification and the Hardware Requirements.
The most common integration failure mode is an interface assumption that lives in neither standard’s requirements — it was “obvious” to the engineer who designed both items, but it is not documented, not verified, and becomes a certification finding. DO-254 explicitly requires that derived requirements — those generated by the hardware design that impose constraints on the software or the system — be fed back to the system safety process. In practice, this feedback loop must be actively managed, not assumed.
RTCA guidance also clarifies that DO-254 and DO-178C are not hierarchical — neither standard subordinates the other. They coordinate through the system-level safety and requirements allocation process.
Requirements Traceability in DO-254: What the Standard Actually Demands
DO-254 Section 10.1 lists traceability as a required element: hardware requirements must be traceable to system requirements, design must be traceable to hardware requirements, and verification coverage must be traceable to requirements. This is bidirectional traceability — you must be able to follow a requirement from its system-level source down to the test result that verified it, and you must be able to look at any test and identify which requirement it covers.
In practice, many teams manage this with spreadsheets — a Requirements Traceability Matrix (RTM) that maps requirement IDs to design items to test procedures to results. This works at low requirement counts. At DAL A complexity, with hundreds or thousands of derived requirements across FPGA partitions and interface specifications, it stops working. Changes to a requirement require manual updates across multiple linked documents. A missed link is invisible until the DER asks for coverage evidence during the audit.
The structural problem with document-based traceability is that the links are stored separately from the artifacts they connect. The requirement is in one document, the design is in another, the test is in a third, and the RTM is a fourth document that claims to connect them. Any of the four can change without updating the others, and the inconsistency is only discovered by human review.
How Modern Tools Implement DO-254 Traceability
The second half of any serious DO-254 program is a process question: how do you maintain traceability rigorously enough to survive a DER audit without spending more labor on documentation than on engineering?
This is the context in which graph-based requirements management tools have become relevant to avionics hardware programs. Rather than storing requirements in documents and linking them via a separate RTM spreadsheet, these tools model the entire DO-254 lifecycle as a connected graph — requirements, design items, verification procedures, and results are all nodes, and the relationships between them (derives from, is verified by, implements, satisfies) are first-class edges in the data model.
Flow Engineering was built specifically for this kind of hardware and systems engineering environment. Its graph-native architecture means that when a hardware requirement changes — a timing constraint tightened due to a late system safety finding, for example — the tool immediately surfaces every downstream design item, test procedure, and verification result connected to that requirement. The engineer sees the impact graph before the change propagates, not after.
For DO-254 programs, this matters in two concrete ways. First, coverage analysis is continuous rather than periodic: at any point in the program, you can query the model and identify requirements that have no linked verification evidence — the gaps the DER will find if you don’t find them first. Second, the Hardware Accomplishment Summary, which requires traceability evidence, can be generated from live program data rather than assembled by reconciling four sets of documents that have drifted out of sync.
Flow Engineering’s focus is on the systems and hardware requirements layer — it is not a simulation tool, an HDL verification environment, or a schematic capture tool. Its deliberate scope is the requirements, traceability, and process evidence layer that sits above those tools and connects them. Teams using it for DO-254 typically integrate it with their FPGA toolchains and test management systems, using Flow Engineering as the authoritative traceability spine while domain-specific tools handle HDL development and test execution.
Practical Starting Points for DO-254 Programs
If you are entering a DO-254 program, four process decisions made early determine most of your downstream compliance burden:
1. Assign DALs before architectural decisions. The DAL assignment drives independence requirements, verification depth, and tooling qualification needs. Making architectural choices before DAL is confirmed often requires expensive rework.
2. Define the requirements hierarchy explicitly. System requirements, hardware item requirements, and derived requirements must be structurally distinct — not lumped into a single document that conflates allocation levels.
3. Plan verification coverage during requirements capture. Every requirement should have a verification method assigned at the time it is written, not retroactively. “How will we verify this?” is a requirements quality question, not just a test planning question.
4. Choose a traceability tool that models the lifecycle rather than documents it. A tool that stores links in the same database as the artifacts it links will maintain consistency automatically. A tool that stores links in a separate spreadsheet will require continuous manual reconciliation.
DO-254 is demanding because the cost of getting it wrong is measured in lives, not project overruns. The standard’s rigor is proportionate to that cost. The teams that navigate it successfully treat the process evidence as genuine engineering information — not compliance paperwork, but the actual record of what was designed, why, and how it was shown to work.