What DO-254 Actually Governs
When engineers talk about avionics certification, DO-178C dominates the conversation. That is appropriate — software is the dominant complexity driver in modern avionics. But every piece of airborne electronic hardware implementing safety-critical functions faces its own governing document: RTCA DO-254, formally titled Design Assurance Guidance for Airborne Electronic Hardware.
DO-254 was published by RTCA in 2000 and has been accepted by the FAA (Advisory Circular 20-152), EASA, and Transport Canada as the means of compliance for complex electronic hardware in airborne systems. The standard covers any electronic hardware component where internal complexity makes comprehensive testing of all possible states impractical — a definition that captures virtually every FPGA, ASIC, and PLD used in modern avionics.
Simple hardware — resistors, capacitors, discrete logic gates — falls outside the standard’s scope. The threshold is complexity: if you cannot enumerate every functional state through physical testing alone, DO-254 applies. In practice, any FPGA or custom ASIC in a flight-critical or flight-essential function will require DO-254 compliance.
This article explains what the standard requires, how its processes work together, how it interacts with DO-178C on programs that combine hardware and software, and what the traceability obligations mean operationally.
Design Assurance Levels: DAL A Through E
DO-254 uses the same five-level Design Assurance Level (DAL) hierarchy as DO-178C, derived from the system-level safety assessment performed under ARP4754A. The DAL assigned to a hardware item reflects the severity of the failure condition that would result if that item malfunctioned or failed.
DAL A — Catastrophic. A failure condition that would result in loss of the aircraft or multiple fatalities. Full DO-254 compliance is required, including all planning, design, verification, and hardware accomplishment summary documentation. The FAA applies additional scrutiny for DAL A hardware items, typically requiring a Designated Engineering Representative (DER) to directly audit design data.
DAL B — Hazardous/Severe-Major. A failure condition that could result in serious injury or death to a small number of occupants, or that significantly reduces the capability of the aircraft or crew. Most DO-254 processes apply in full; some mitigation credit for dissimilarity may be taken.
DAL C — Major. A failure condition that reduces crew capability or causes passenger discomfort. DO-254 applies with somewhat reduced verification depth — notably, independence requirements on reviews are relaxed compared to DAL A/B.
DAL D — Minor. A failure condition that does not significantly reduce safety margins. Planning and design capture are still required, but verification rigor is substantially reduced.
DAL E — No Safety Effect. No DO-254 obligations. Hardware at this level requires no design assurance process.
The DAL assignment flows down from the system safety assessment — hardware engineers do not self-assign their DAL. This is significant: a design team working on an FPGA implementing both a DAL A function and a DAL C function must either partition the hardware to separate DAL assignments or apply DAL A rigor to the entire device.
The Six Core Processes
DO-254 organizes hardware development into a lifecycle of six interlocking processes. These are not sequential phases in the traditional sense — they overlap and feed each other — but each carries specific output requirements.
1. Requirements Capture
DO-254 opens with requirements capture for a reason: every downstream verification activity traces back to a requirement. The standard expects hardware requirements to be derived from system requirements (themselves established under ARP4754A) and to be:
- Complete — no unstated assumptions about behavior
- Unambiguous — one interpretation per requirement
- Verifiable — each requirement must be testable by analysis, inspection, or test
- Traceable — each hardware requirement must link to a parent system requirement
Requirements fall into two categories: functional requirements (what the hardware does) and derived requirements (constraints that arise from the hardware design itself, not directly from system requirements). Derived requirements are a DO-254-specific risk: because they emerge during design, they can go undocumented. The standard requires that derived requirements be flagged and fed back to the system safety assessment.
Poorly written requirements are the most common root cause of late-stage compliance findings. A requirement that reads “the FPGA shall process sensor inputs” is not verifiable. A requirement that reads “the FPGA shall sample analog input channels 1–4 at a minimum rate of 1 kHz with a maximum latency of 2 ms from sample acquisition to output register update” is.
2. Conceptual Design
Conceptual design establishes the hardware architecture — partitioning, interface definitions, technology choices — before detailed design begins. For DAL A and B hardware, a conceptual design review (CDR analog) is typically required. The conceptual design must demonstrate that the proposed architecture can satisfy all hardware requirements and that the chosen implementation technology (FPGA family, ASIC process node) is appropriate for the operating environment.
3. Detailed Design
Detailed design translates the conceptual architecture into implementable specifications: RTL descriptions for FPGAs, schematic capture and layout for custom hardware, timing constraints, power budgets. At this stage, traceability obligations become operationally demanding. Every design decision that satisfies a requirement must be documented. Every design element must be traceable to at least one requirement — orphaned design elements are a compliance finding.
4. Implementation
Implementation covers the physical realization of the design: FPGA synthesis and place-and-route, PCB fabrication, device programming. DO-254 requires that implementation tools be assessed for their potential to introduce errors not present in the design data. This is the hardware equivalent of DO-178C’s tool qualification — a synthesis tool that could silently misconfigure timing constraints requires either qualification data or mitigation through verification.
5. Production Transition
Production transition addresses the handoff from design to manufacturing. The standard requires that manufacturing processes be documented sufficiently to ensure that production units are equivalent to the verified design. For FPGAs, this includes bitstream configuration control. For ASICs, it covers mask set custody and wafer acceptance testing.
6. Acceptance Test
The acceptance test process verifies that each delivered hardware item conforms to its design. Acceptance tests are distinct from design verification tests — they confirm conformance of the physical article, not correctness of the design. For complex hardware, acceptance tests typically include functional tests against a defined subset of requirements, environmental stress screening, and configuration verification.
Supporting Processes: Configuration Management and Quality Assurance
Two cross-cutting processes run through all six lifecycle stages.
Configuration Management (CM) in DO-254 is not simply version control. The standard requires that all hardware design data — requirements, design files, test procedures, test results, tool configurations — be placed under configuration control with sufficient rigor to reconstruct any prior state of the design. For FPGA hardware, this extends to synthesis scripts, constraint files, and tool versions. A build that cannot be reproduced from configuration-controlled data is a compliance gap.
Quality Assurance (QA) requires that process compliance be independently audited throughout the lifecycle — not just at final review. QA must verify that plans are followed, that reviews are conducted with required independence, and that deviations are documented and resolved. For DAL A/B hardware, QA independence must be organizational, not just procedural.
DO-254 and DO-178C: Working Together on Mixed Programs
Nearly every modern avionics Line Replaceable Unit (LRU) contains both software (running on an embedded processor) and complex electronic hardware (an FPGA implementing bus interfaces, signal conditioning, or safety monitoring functions). Programs that include both face a compliance challenge that neither standard addresses in isolation: the interface between hardware and software is where requirements ownership is most ambiguous.
The practical interaction works as follows:
The system requirement flows down through ARP4754A to both software and hardware. The software component captures its derived requirements per DO-178C. The hardware component captures its derived requirements per DO-254. But the interface between them — register maps, interrupt behavior, timing relationships — must be owned somewhere. In practice, this interface specification often lives in neither the software requirements baseline nor the hardware requirements baseline, creating a traceability gap that certification auditors find quickly.
Best practice is to define a Hardware/Software Interface (HSI) document, referenced by both the DO-178C software requirements data and the DO-254 hardware requirements data. The HSI is placed under configuration management and its requirements are traced bidirectionally — each HSI entry traces to the hardware requirement it drives and the software requirement it constrains. Any change to the HSI triggers an impact assessment on both baselines.
A second interaction point concerns failure modes. The hardware failure modes identified in the DO-254 safety analysis must be inputs to the software’s robustness and fault tolerance design. If the FPGA can output an incorrect value due to a single-event upset, the software must either detect and handle that fault or the safety case must demonstrate that the hardware’s upset rate is below the threshold that makes software mitigation unnecessary.
What Traceability Actually Looks Like in Practice
The word “traceability” appears more than 80 times in DO-254. Its operational meaning is specific: for each hardware requirement, there must be a documented chain connecting that requirement to the design element that implements it, and from that design element to the verification evidence that confirms correct implementation.
A complete trace chain for a single requirement looks like:
System requirement → Hardware requirement → RTL module or schematic block → Verification test case → Test result record → Pass/no-pass determination
For a non-trivial FPGA with hundreds of requirements, maintaining these chains manually in a spreadsheet-based Requirements Traceability Matrix (RTM) is technically possible but operationally fragile. Changes to requirements must propagate through the matrix; impact analysis on any design change requires traversing the chains in both directions; gaps surface only when the matrix is explicitly audited.
The certification audit will walk these chains. Any broken link — a requirement with no design element, a design element with no test, a test with no result record — is a finding that must be resolved before approval.
How Modern Tools Support DO-254 Compliance
The traceability obligation is where tooling choices have the most leverage. Legacy requirements management tools — IBM DOORS and DOORS Next, Polarion, Codebeamer — can store requirements and create trace links between them. They have mature feature sets and deep integration with PLM environments. For organizations already standardized on these platforms, they remain defensible choices for DO-254 programs.
The architectural limitation of document-oriented tools becomes visible when requirements change frequently or when trace chains span organizational boundaries (system engineering, FPGA design, verification, and QA may each own a segment of the chain). In document-centric systems, each change requires manual updates to multiple linked documents, and impact analysis requires human traversal rather than automated propagation.
Flow Engineering takes a different architectural approach: requirements, design decisions, and verification relationships are stored as nodes and edges in a graph model rather than as rows in documents. For DO-254 programs, this matters in two specific ways.
First, derived requirements — the DO-254-specific obligation to capture and trace requirements that emerge from the hardware design itself — are naturally represented as graph nodes with edges pointing both to the parent hardware requirement and to the system safety assessment item they affect. In a document model, derived requirements tend to get appended to requirement lists without their derivation relationships being formally captured. In a graph model, the derivation relationship is structural.
Second, impact analysis on requirement changes becomes a traversal operation rather than a manual audit. When a system requirement changes, Flow Engineering can identify every hardware requirement derived from it, every design element tracing to those requirements, and every verification case covering those design elements — and surface that set for review before any design work begins. This is the operational difference between catching an impact at the start of a change cycle and discovering it during a certification audit.
Flow Engineering is purpose-built for hardware and systems engineering programs, which means its data model reflects the artifact types that DO-254 programs actually produce: hardware requirements, design constraints, verification procedures, and configuration items. The tool does not require teams to adapt a generic requirements tool to an avionics workflow; the workflow is the starting point.
Where Flow Engineering’s scope is intentionally focused: it does not replace dedicated simulation environments, synthesis tools, or test management platforms that log raw test execution results. It is the requirements and traceability layer — the connective tissue between system engineering and design implementation — not the full certification toolchain.
Where to Start
DO-254 compliance is not primarily a documentation exercise. It is a design discipline that begins with requirements. The teams that struggle most with certification audits are not those who wrote bad tests — they are those who wrote incomplete requirements or failed to maintain traceability as the design evolved.
If your program is at the beginning of the hardware lifecycle:
- Establish your DAL assignments from the system safety assessment before hardware requirements are written. DAL drives every subsequent verification obligation.
- Define the Hardware/Software Interface specification as a first-class artifact, under configuration management, with bidirectional traceability into both the DO-254 and DO-178C baselines.
- Instrument your requirements process to capture derived requirements at the point they emerge — during conceptual and detailed design — not during compliance review.
- Choose a traceability tool architecture that supports impact analysis on requirement changes, not just storage of trace links.
The standard is 84 pages. The compliance burden on a DAL A FPGA program can run to thousands of requirements and tens of thousands of trace links. The engineering is manageable. The administration is where programs lose control.
Honest Assessment
DO-254 is a mature, well-constructed standard. Its process requirements are proportionate to the risk levels it addresses, and its alignment with DO-178C makes integrated hardware/software programs tractable. The standard does not mandate specific tools or methodologies — it mandates outcomes: requirements that are verifiable, designs that trace to requirements, and evidence that verification was performed.
The operational challenge is scale and change management. Modern FPGAs used in avionics are not simple — a Xilinx Versal or Intel Agilex device implementing signal processing, bus interfaces, and safety monitoring simultaneously can have requirement counts and trace chains that overwhelm spreadsheet-based processes.
Organizations that invest in graph-based requirements infrastructure early in the program lifecycle have a structural advantage: their trace chains are maintained as a live artifact of the design, not reconstructed for certification review. That difference shows up not just in audit outcomes, but in the engineering team’s ability to make design changes confidently throughout development.