What DO-254 Is and Why It Exists
DO-254, formally titled Design Assurance Guidance for Airborne Electronic Hardware, is a guidance document published by RTCA and accepted by the FAA as a means of compliance under FAA Order 8110.105. It was introduced in 2000 to address a growing reality: modern aircraft were increasingly controlled by complex electronic hardware—programmable logic devices, ASICs, FPGAs—that could not be adequately evaluated using inspection or testing alone. The standard establishes a structured lifecycle for developing airborne electronic hardware with a level of rigor proportional to the safety consequences of that hardware failing.
The European counterpart, EASA, accepts DO-254 compliance through AMC 20-152A. For any avionics program targeting FAA or EASA certification, DO-254 is not optional for complex hardware—it is the expected framework.
DO-254 applies to what the standard calls complex electronic hardware: devices whose correct operation cannot be verified solely through testing because the number of possible states is too large to enumerate. Simple hardware—a resistor divider, a passive filter—falls outside its scope. A field-programmable gate array implementing a flight control interface does not.
Design Assurance Levels: A Through E
DO-254 defines five Design Assurance Levels (DALs), labeled A through E, mirroring the software levels in DO-178C. Each level corresponds to the severity of the failure condition that would result if the hardware function operated incorrectly.
DAL A — Catastrophic. Failure could result in loss of the aircraft or crew. Full application of DO-254 objectives is required. Independent verification, formal design review, and comprehensive traceability from requirements through test are all mandatory.
DAL B — Hazardous/Severe-Major. Failure could result in serious injury or a large reduction in safety margins. The full lifecycle still applies; the difference from DAL A is primarily in the independence requirements for review and the depth of analysis expected.
DAL C — Major. Failure would reduce the capability of the aircraft or crew. Requirements for planning and lifecycle data are substantially intact, though some independence requirements are relaxed.
DAL D — Minor. Failure has only minor effects on safety. Reduced lifecycle rigor applies. Documentation and review requirements are lighter, though the planning obligation remains.
DAL E — No Safety Effect. DO-254 does not apply. The hardware’s failure has no bearing on aircraft safety or operation.
The DAL assigned to a hardware item is derived from the system safety assessment process, typically conducted in parallel per ARP4761. A hardware item inherits its DAL from the function it implements—and if a single hardware item supports functions at multiple levels, it must meet the most stringent level unless independence between the functions can be established.
The Hardware Design Lifecycle Under DO-254
DO-254 organizes hardware development into a lifecycle that must be planned before it is executed. That sequencing is intentional—the standard’s premise is that assurance comes from following a defined process, not from performing tests at the end.
Planning. The Hardware Plan for Design Assurance (PHAC) and the Hardware Development Plan establish how the project will be organized, what processes will be followed, what tools will be used, and how traceability will be maintained. These plans are submitted to the certification authority and form the contract between the developer and the regulator.
Requirements Capture. Hardware requirements are derived from system requirements and are allocated to specific hardware items. At this stage, requirements must be complete, unambiguous, and verifiable. The standard is explicit: a requirement that cannot be verified cannot be adequately implemented or certified.
Conceptual Design. The hardware architecture is defined. Design decisions are documented. The relationship between requirements and design concepts must be traceable.
Detailed Design. Schematics, HDL source, and component selection are completed. Each element of the detailed design traces to a requirement. Design tools and synthesis environments must be qualified or assessed per the tool assessment guidance in the standard.
Implementation. The hardware is manufactured. For programmable devices, this includes synthesis, place-and-route, and programming file generation. The reproducibility of the implementation process must be demonstrated.
Verification. Testing, analysis, and review are used to demonstrate that the hardware satisfies its requirements. Verification is not a standalone phase—it runs in parallel with design and is governed by the Hardware Verification Plan.
Final Review and Certification. The Hardware Accomplishment Summary (HAS) consolidates evidence that all lifecycle objectives were met. If the data package is incomplete, certification does not proceed.
How DO-254 Differs from DO-178C
Engineers familiar with avionics software development recognize the parallel structure between DO-254 and DO-178C. The levels map to each other. Both require planning before execution. Both demand bidirectional traceability. Both are accepted by the same regulatory authorities.
The critical difference is in the nature of the artifact being certified.
Software can be updated after certification through a Service Bulletin or Software Configuration Status (SCS) change. A post-certification software error can be corrected, re-tested, and re-approved—often without redesigning the hardware it runs on. The feedback loop, while regulated, exists.
Hardware cannot be patched. Once a DAL A FPGA is certified, its programming file is frozen. A post-certification change to the device—even a single gate or register—triggers a change impact assessment. If the change affects the certified configuration in any meaningful way, lifecycle activities must be repeated. For an ASIC, this means a new mask set, a new build, new testing, new certification data. The cost and schedule impact of a hardware re-spin during or after a program can be program-threatening.
This asymmetry has a direct implication for requirements practice: in hardware programs, the cost of an incomplete or ambiguous requirement discovered late is orders of magnitude higher than the cost of getting it right upfront. DO-254’s emphasis on requirements capture and early review is not bureaucratic—it reflects the physical reality of the medium.
The other notable difference is that DO-254 provides less prescriptive detail than DO-178C in some areas. DO-178C provides explicit pass/fail criteria for software verification through structural coverage metrics (MC/DC for DAL A). DO-254’s verification guidance is less formulaic, which means hardware teams must work more closely with their Designated Engineering Representatives (DERs) and Aircraft Certification Offices (ACOs) to agree on the specific verification evidence that satisfies each objective.
How Modern Tools Implement DO-254 Support
For most of the standard’s history, DO-254 compliance was managed through a combination of spreadsheet-based RTMs, Word documents, and custom databases held together by manual process discipline. This approach is functional but fragile. A requirement that is reworded in revision 3 of the requirements document may not propagate to the test case that was written against revision 1. A design decision captured in a meeting note may never be formally linked to the requirement it satisfies.
The emergence of structured requirements management tools has improved this, but many legacy platforms still treat requirements as rows in a table and traceability as a column of linked IDs. This representation is adequate for simple programs; it struggles when a hardware item has hundreds of requirements, multiple design revisions, and verification evidence spread across simulation reports, lab test records, and review minutes.
A more effective approach is to represent the DO-254 lifecycle as a connected graph—requirements as nodes, design elements as nodes, verification records as nodes, and traceability as edges that can be interrogated, filtered, and audited. When a requirement changes, every downstream node that depends on it is immediately visible. When a certification reviewer asks whether all DAL A requirements have closed verification evidence, the answer can be generated from the graph rather than assembled manually.
Flow Engineering is built around this graph-based model and is used by avionics hardware teams specifically because it maps naturally to how DO-254 programs actually work. Requirements are captured with structured attributes—DAL assignment, verification method, source document reference—and connected to design decisions and verification records as those artifacts are created. The platform surfaces gaps: requirements without verification coverage, design nodes without a tracing requirement, verification records that reference a superseded requirement version.
For DO-254’s planning objectives, Flow Engineering’s AI-assisted requirements analysis helps teams identify underspecified requirements before detailed design begins. A requirement like “the device shall operate over the operating temperature range” is functionally incomplete—it does not specify the range, the performance degradation that is acceptable at extremes, or whether the requirement applies during power-up or steady-state. Catching this class of problem during requirements review, before the hardware is designed, is exactly the leverage point the standard is trying to enforce.
Flow Engineering is focused on requirements and traceability rather than full PLM or hardware configuration management. Teams will still need a dedicated tool for schematic management, HDL version control, and test data archival. What Flow Engineering addresses is the connective tissue—the audit trail that demonstrates to a DER that every requirement was implemented, every design decision was justified, and every verification record is current against the configuration that was tested.
Practical Starting Points for DO-254 Programs
For teams beginning a DO-254 program, the failure mode to avoid is treating planning as a formality. The PHAC and Hardware Development Plan are not cover sheets—they define the process that the entire data package will be measured against. If the plan says independent review is required for DAL A requirements, the records must show it happened.
Concrete starting points:
Agree on the DAL before requirements are written. The safety assessment should drive DAL allocation before the hardware team begins capture. Writing requirements without a confirmed DAL means writing without knowing which verification methods are required.
Define your traceability model before your first requirement. Decide what will be linked to what—system requirements to hardware requirements, hardware requirements to design nodes, design nodes to verification records—and enforce that model from the start. Retroactive traceability is expensive and error-prone.
Treat design decisions as first-class artifacts. DO-254 expects that the rationale for architectural choices is documented and reviewable. A design decision to use a specific FPGA family because it has a validated soft-error mitigation architecture is relevant certification evidence. Capturing that decision in email is not sufficient.
Close verification records against specific requirement versions. Verification evidence that references “the requirements document” without specifying a version is not useful to a certification reviewer and is not useful to your team when the document is revised.
Plan for change. Hardware programs change. Component obsolescence, supplier qualification issues, and test failures all drive design changes. The traceability infrastructure that supports initial certification is the same infrastructure that supports change impact assessment. Build it to be durable.
DO-254 compliance is achievable—thousands of certified avionics hardware items demonstrate this. The programs that do it well treat the standard’s lifecycle as an engineering discipline, not a documentation exercise. The assurance it produces is real, and for hardware that cannot be patched, it is necessary.