What DO-254 Actually Is

DO-254, formally titled Design Assurance Guidance for Airborne Electronic Hardware, is a guidance document published by RTCA and adopted by the FAA through AC 20-152 and equivalent EASA guidance. It defines the processes, objectives, and evidence an aviation program must satisfy to certify complex electronic hardware (CEH) installed in airborne systems.

The document was first released in 2000. That timing matters: programmable logic devices, particularly FPGAs and CPLDs, had become too complex for the informal “similarity to proven design” arguments that had historically satisfied certification authorities. DO-254 gave the industry a structured framework for demonstrating that hardware development had been conducted with appropriate rigor—and that the rigor was traceable and reviewable.

“Complex electronic hardware” is the operative phrase. Simple hardware—resistors, capacitors, discrete logic with deterministic behavior—can often be approved through analysis alone. CEH is hardware whose function cannot be fully verified by exhaustive testing or whose internal logic cannot be practically reviewed at the gate level. Modern FPGAs with millions of logic elements, multi-core processors embedded in custom ASICs, and hybrid analog-digital signal processing chains all qualify. If your hardware implements a function that would, in a worst-case failure, affect aircraft safety, DO-254 almost certainly applies.

Design Assurance Levels: DAL A Through DAL E

The cornerstone of DO-254 is the concept of the Design Assurance Level, which maps directly to the severity of the failure condition the hardware’s function could cause. The levels are defined in ARP4754A at the system level and flow down into hardware through DO-254.

DAL A — Catastrophic. A failure of this hardware function could cause loss of the aircraft or multiple fatalities. Full design assurance objectives apply: complete requirements, complete traceability, independent review of every major artifact, and exhaustive coverage analysis of verification activities. Flight control processing hardware commonly sits here.

DAL B — Hazardous/Severe-Major. A failure produces serious or fatal injuries to a small number of occupants, or significant reduction in aircraft capability. Nearly all DAL A process requirements apply; the primary distinction is in the independence and depth of certain review activities. Navigation processing, high-lift control electronics, and many flight management components fall at DAL B.

DAL C — Major. Failures cause discomfort or a significant increase in crew workload, but injuries are not expected. Cabin pressurization control hardware, secondary display processors, and many avionics network switches are designed to DAL C. Traceability and verification requirements remain substantial, but independent review can be less intensive.

DAL D — Minor. Failures cause slight crew workload increase or minor operational inconvenience. In-flight entertainment controllers, auxiliary lighting drivers, and certain ground-only maintenance interfaces often operate at DAL D. Basic process controls apply, but the documentation overhead is meaningfully lighter.

DAL E — No Safety Effect. Hardware whose failure has no effect on aircraft safety. DO-254 process objectives do not apply, though the hardware must still be identified and bounded so the claim holds up under review.

The DAL is assigned at the system level through the safety assessment process described in ARP4754A, then flowed down to each hardware item. A single board may contain components at multiple DALs if it implements multiple functions with different safety relevance. Partitioning those functions convincingly—so that a DAL D failure mode cannot propagate into a DAL A function—is one of the harder practical challenges teams face.

Key Process Objectives

DO-254 organizes its requirements around a set of process objectives grouped into five major areas. Meeting these objectives is what generates the evidence a Designated Engineering Representative (DER) or Certification Authority review will examine.

Hardware Planning

Before design work begins, the program must produce a Hardware Development Plan, Hardware Verification Plan, Hardware Configuration Management Plan, and Hardware Process Assurance Plan. These documents define methodology, tool qualification strategy, review criteria, and how deviations will be handled. Certification authorities review these plans early. Surprises late in a program are expensive; surprises in planning documents are recoverable.

Requirements Capture

The hardware requirements process must produce a Hardware Requirements Document (HRD) that captures all allocated system requirements, derived requirements generated during hardware design, and environmental and design constraints. Requirements must be complete, unambiguous, verifiable, and traceable to their source. Each derived requirement—one the hardware team creates to meet an allocated requirement that doesn’t have a one-to-one system-level counterpart—must be explicitly identified and fed back into the safety assessment process for evaluation.

This is where first-time programs most often create problems for themselves. Requirements written at design time tend to describe the implementation rather than the function. DO-254 reviewers will call this out. “The FPGA shall implement a Type II PLL with a reference frequency of 25 MHz” is a design decision, not a requirement. “The clock recovery function shall maintain phase lock within ±50 ppm across the specified operating temperature range” is a requirement.

Conceptual and Detailed Design

DO-254 separates design into conceptual (architecture, partitioning, interface definition) and detailed (logic design, schematic capture, HDL development) phases. Each phase must produce reviewable artifacts, and the transition between phases is a formal review gate. For FPGA designs, the HDL source, synthesis constraints, and implementation reports are all considered part of the design data and must be placed under configuration management.

Verification

Verification at DAL A and B requires not just testing but coverage analysis. The program must demonstrate that verification activities exercise all requirements and all design features. For FPGA designs, this commonly means structural coverage analysis of HDL—statement, branch, and condition/decision coverage—supplemented by functional testing against requirements. Hardware-software integration testing, environmental qualification per DO-160, and production testing constraints all feed into the verification evidence package.

Configuration Management and Process Assurance

Every artifact—requirements, design files, test procedures, test results, analysis reports, tool qualification records—must be placed under configuration management from the point of first use. Hardware Process Assurance (HPA) is the ongoing audit function that confirms the development process is being followed as planned and that deviations are captured and dispositioned. HPA is not the same as quality assurance; it’s specifically concerned with process compliance against the Hardware Development Plan.

DO-254 and DO-178C: The Boundary Question

Aviation programs almost always develop hardware and software together. The boundary between DO-254 and DO-178C—the software equivalent—is a routine source of confusion and, when handled poorly, a gap that certification authorities find immediately.

The governing principle is that the standard applies to the artifact, not to where it runs. HDL compiled into an FPGA is hardware under DO-254, not software. Firmware running on a processor embedded in a custom ASIC is software under DO-178C. A soft-core processor instantiated in FPGA fabric and running application code creates obligations under both standards simultaneously.

The practical consequence: if your FPGA includes a MicroBlaze or NIOS II soft-core processor executing flight-relevant code, the hardware implementation of that processor is governed by DO-254, and the software running on it is governed by DO-178C at the same DAL. Your Hardware Requirements Document must allocate requirements to both. Your verification must cover both. Your configuration management must control both. The interface between them—memory maps, interrupt behavior, DMA channel arbitration—must be explicitly documented and verified.

Programs that treat this boundary informally produce compliance gaps that surface during Stage of Involvement (SOI) audits, typically at SOI 3 or SOI 4, when remediation is most costly.

Common First-Time Challenges

Teams encountering DO-254 for the first time consistently report the same set of problems. None of them are primarily engineering problems.

Requirements quality. Engineers who are excellent hardware designers often produce requirements documents that read like design specifications. DO-254 reviewers expect requirements that describe observable, measurable, testable behavior. Refactoring a 200-requirement HRD eight weeks before SOI 2 is a real and avoidable situation.

Traceability completeness. DO-254 requires bidirectional traceability: from system requirements down to hardware requirements, then to design elements, then to verification procedures, then to verification results—and back up. Maintaining this in spreadsheets across a team of ten engineers over an 18-month development cycle produces gaps. Gaps found by a DER during review require formal corrective actions and re-review.

Derived requirements identification. Hardware teams make dozens of architectural decisions that generate derived requirements—timing margins, power sequencing constraints, interface voltage levels chosen for noise immunity. Each one must be explicitly flagged, documented, and fed back into the safety assessment. Teams that don’t build this practice into their design process find themselves reconstructing it retroactively.

Tool qualification. Any software tool whose output is used as design or verification evidence without independent check may require qualification under DO-330. Synthesis tools, simulation tools, and coverage analysis tools all fall in scope. Tool qualification is not a last-minute activity; it requires usage records from the beginning of the program.

DER engagement timing. Designated Engineering Representatives are not inspectors who show up at the end. Early alignment on what evidence is needed, how it will be structured, and what the review sequence looks like prevents the most expensive surprises. Programs that engage their DER only at formal SOI audits routinely discover expectation mismatches that require months of rework.

How Modern Requirements Tools Support DO-254 Compliance

The documentation and traceability burden of DO-254 is not incidental to the standard—it is the standard. The process objectives exist precisely because airborne hardware certification depends on reviewable evidence that development was conducted rigorously. This is where the choice of tooling has direct program consequences.

Traditional approaches use word processors for requirements documents, spreadsheets for requirement-to-verification traceability matrices (RTMs), and file systems or PLM vaults for design artifacts. These approaches work at small scale with disciplined teams. They break down when requirements change, when design evolves faster than the RTM is updated, or when the team needs to answer the question “what verification evidence covers this specific system requirement?” under time pressure during a DER review.

Graph-based requirements management tools address this structurally. Instead of maintaining a static matrix that someone must remember to update, these tools model requirements, design elements, and verification artifacts as nodes in a connected graph, with traceability links as edges. Coverage becomes a query, not a manual count. Gaps appear as disconnected nodes, not as rows missing from a spreadsheet someone forgot to update.

Flow Engineering (flowengineering.com) is purpose-built for hardware and systems engineering programs with exactly these constraints. Its graph model maps directly onto the DO-254 data architecture: system requirements allocated to hardware requirements, hardware requirements traced to design artifacts, design artifacts linked to verification procedures, verification procedures linked to results. The traceability relationships are first-class objects in the model, not annotations in a document.

For DO-254 programs specifically, Flow Engineering supports the derived requirement identification workflow—flagging requirements that were generated during design rather than allocated from the system level, and surfacing them for safety assessment disposition. This is one of the more error-prone manual processes in first-time DO-254 programs, and making it systematic reduces both the error rate and the time spent reconstructing the record during reviews.

Flow Engineering also maintains the configuration state of the requirement-design-verification graph, which means that when a requirement changes—as requirements always do—the downstream impact is immediately visible: which design elements reference it, which verification procedures test it, which test results would be invalidated. This is not a peripheral feature for DO-254; it is the core of what configuration management of requirements data means in practice.

The tool’s deliberate focus is requirements and traceability within the systems engineering workflow. It is not a full PLM system, a schematic capture environment, or a test execution platform. Teams using Flow Engineering integrate it with their existing ECAD, HDL management, and test infrastructure rather than replacing those tools. For programs where the primary compliance risk is traceability integrity and requirements quality—which is most first-time DO-254 programs—this is the right trade-off.

Practical Starting Points for DO-254 Programs

If you are beginning a DO-254 program or have one in progress that is accumulating traceability debt, the leverage points are consistent across program types.

Start with DAL allocation before writing a single requirement. Know what level applies to each hardware function before you begin, because the level determines which process objectives apply and which don’t. Designing a DAL C board to DAL A standards wastes resources; designing a DAL A board to DAL C standards creates a compliance crisis.

Write requirements before design decisions, and review them for testability before they become the baseline. A requirement that cannot be independently verified by test, analysis, or inspection is not a DO-254-compliant requirement, regardless of how accurate it is as a design description.

Establish traceability tooling at program start, not at SOI 1 preparation. Retroactive traceability reconstruction is the most time-consuming rework activity in DO-254 programs. The cost of establishing a connected requirements model at program initiation is a fraction of the cost of building one from design artifacts six months later.

Engage your DER in planning document review, not just formal audits. The planning documents define the evidence the program will generate. Alignment at that stage prevents structural compliance gaps that no amount of late-program effort can fully remediate.

DO-254 is not a bureaucratic obstacle added to hardware development. It is the evidence structure that makes airborne hardware certification possible. Programs that internalize that framing—and tool and staff accordingly—produce better hardware and faster certifications than programs that treat it as overhead.