The DO-254 Hardware Development Lifecycle

DO-254 structures hardware development into sequential phases. Each phase produces specific lifecycle data that certification authorities review at defined milestones.

Planning the PHAC

The PHAC is the primary planning document you submit to the certification authority. It defines the processes, methods, standards, and lifecycle data that will satisfy DO-254 objectives. Alongside it, the planning phase produces the Hardware Development Plan, Verification and Validation Plan, Configuration Management Plan, and Process Assurance Plan. All of these are evaluated for completeness and consistency at the first Stage of Involvement (SOI #1).

Managing Configuration

Configuration management in DO-254 means maintaining controlled, auditable records of every piece of lifecycle data from the moment it is created: requirements, design files, HDL source, synthesis configurations, test procedures, results, and planning documents. It comes down to three things: version control so every change is recorded, baseline management so you can identify the exact state of all data at any milestone, and change tracking so every modification has a documented reason and approval.

Auditors focus heavily on CM because it ties the entire evidence base together. If a certification authority cannot trace a requirement change through design updates, re-verification, and updated results, the assurance argument breaks down. Teams that enforce CM from day one avoid the expensive rework that comes from treating it as a late-stage cleanup.

Defining Requirements, Design, and Implementation

The requirements phase produces documented, testable hardware requirements with unique identifiers. Each requirement is captured and traced before any Register Transfer Level (RTL) code is written, preventing verification gaps later in the lifecycle.

Conceptual design translates requirements into a high-level hardware architecture with partitioning strategies and interface definitions. Detailed design then produces implementation-ready data, including schematics, HDL code, netlists, and specifications. For FPGAs and ASICs, implementation means synthesis, place-and-route, and bitstream generation. For board-level hardware, it means PCB layout and fabrication.

Completing Stages of Involvement (SOI Reviews)

DO-254 programs follow four SOI milestones as formal review points with the certification authority:

• SOI #1 (Planning Review): Plans and standards are complete.
• SOI #2 (Design Review): Requirements and design data are assessed.
• SOI #3 (Verification Review): Verification evidence is reviewed.
• SOI #4 (Final Review): The completed Hardware Accomplishment Summary and full lifecycle data package are ready following the final hardware build.

Unresolved action items from earlier SOI reviews create gaps in the verification evidence base that are expensive to close later.

Key DO-254 Deliverables

DO-254 programs produce a specific set of lifecycle documents reviewed at SOI milestones. The exact content scales with DAL, but the core deliverables include the following:

• PHAC (Plan for Hardware Aspects of Certification): Defines the overall certification strategy, including processes, standards, and lifecycle data to be produced.
• HDP (Hardware Development Plan): Describes the development process, team roles, design methods, and tools used throughout the lifecycle.
• HVVP (Hardware Verification and Validation Plan): Specifies verification methods, test strategies, coverage targets, and pass/fail criteria for each lifecycle phase.
• HPAP (Hardware Process Assurance Plan): Establishes how process compliance will be monitored and how deviations will be handled.
• HCMP (Hardware Configuration Management Plan): Defines version control, baseline management, and change tracking procedures for all lifecycle data.
• HRD (Hardware Requirements Data): The documented set of hardware requirements, each with a unique identifier and traceability to system-level requirements.
• HDS (Hardware Design Data): Captures the conceptual and detailed design, including architecture descriptions, schematics, HDL code, and interface definitions.
• HAS (Hardware Accomplishment Summary): A final summary document that records what was planned, what was actually done, any deviations, and open problem reports. This is the last document reviewed at SOI #4.

Together, these deliverables form the evidence base that certification authorities evaluate across all four SOI milestones.

Verification and Validation Under DO-254

DO-254 treats verification and validation as a supporting process that runs throughout the development lifecycle, not as a single post-design phase. Validation determines that requirements are correct and complete, while verification evaluates whether an implementation meets those stated requirements. Confusing them can lead to evidence gaps that auditors will flag during SOI reviews.

Verification Methods and Requirements-Based Testing

Three verification methods must be combined to satisfy DO-254 objectives:

• Reviews: Applied throughout the lifecycle to assess requirements, design data, test plans, and test results.
• Analysis: Includes simulation, static timing analysis, formal analysis, and structural coverage measurement.
• Testing: Performed at both simulation and on-target hardware levels. DAL A and B programs commonly require pin-level verification through both.

Teams combine these methods to build complete requirements-based verification evidence. Traceability between requirements and verification artifacts is required, and independent reviews are mandatory for DAL A and B hardware.

For DAL A and B, the standard also requires elemental analysis: systematically examining each design element (HDL modules, logic blocks, functional partitions) to confirm verification has exercised it. Teams map every element to the test cases and analysis results that cover it, then review for gaps. DAL A requires a justified coverage target; DAL B has slightly less prescriptive expectations. This is one of the most labor-intensive activities in a DO-254 program, and where incomplete traceability becomes most visible.

Tool qualification under DO-330 is also part of the verification picture. Qualification rigor depends on the tool type, its intended use, and the potential impact of tool errors on the hardware.

Building a Requirements Traceability Matrix

Traceability is a core structural requirement in DO-254. Downstream traceability reveals requirements that lack verification coverage, while upstream traceability surfaces derived requirements and unused HDL functions. For DAL A and B, full bidirectional traceability through requirements, design, implementation, and verification results is required. For DAL C and D, traceability from requirements to test is sufficient.

Compliance Challenges and How to Reduce Certification Risk

The most expensive DO-254 problems start with inadequate planning. Teams that build traceability retroactively before an audit face high rework costs, and treating configuration management as an end-of-process activity makes it harder for auditors to reconstruct development history. DAL A and B devices require independent verification, so the designer cannot perform verification for certification credit, which directly affects team structure and scheduling.

The programs that control costs invest in early PHAC development, maintain continuous traceability and configuration management from day one, and engage certification authorities early to close interpretive gaps before building an evidence base on uncertain assumptions.

How Jama Connect Supports DO-254 Compliance

When traceability, test evidence, and change records live in disconnected spreadsheets, preparing for SOI reviews gets slower and more error-prone. Jama Connect® keeps hardware requirements, verification artifacts, and review evidence linked across the DO-254 lifecycle, so you’re not rebuilding trace data before each review. Live Traceability™ lets you compare required data traces against actual development activity and surface coverage gaps before an SOI milestone.

Getting Started With DO-254 Compliance

The programs that get through certification smoothly share a common thread: they invest in planning, traceability, and configuration management from day one rather than scrambling to assemble evidence before an audit. If you are ready to put that structure in place, start a free 30-day trial of Jama Connect and see how live traceability works across the DO-254 lifecycle.

Frequently Asked Questions About DO-254

Who is required to comply with DO-254?

If your program develops FPGAs, ASICs, PLDs, or other complex custom devices for civil airborne systems at DAL A, B, or C, DO-254 is the accepted means of compliance. This applies to manufacturers and installers pursuing type certification, TSO authorization, supplemental type certificates, and related approvals under FAA jurisdiction. EASA-jurisdiction programs follow equivalent requirements through AMC 20-152A.

What is the difference between DO-254 and DO-178C?

DO-254 covers hardware, DO-178C covers software, and both use the same DAL framework. The main difference for teams is that DO-178C is more prescriptive and includes technology supplements that DO-254 doesn’t have. On most avionics programs, hardware and software teams work to both standards in parallel under ARP 4754A system-level guidance.

What role does requirements traceability play in DO-254 compliance?

Traceability is one of the first things certification authorities check. For DAL A and B, you need full bidirectional traceability across requirements, design, implementation, and test results. Teams that build it into their workflow from day one spend far less time preparing for SOI reviews than teams that try to assemble it retroactively.

Does DO-254 apply to commercial off-the-shelf (COTS) components?

COTS components are addressed within current DO-254 compliance guidance. Specific objectives for COTS devices are separate from the objectives for custom programmable devices. COTS IP cores used within FPGAs or ASICs are also addressed through separate IP objectives.