The certification of airborne electronics has traditionally emphasized that safety emerges from disciplined processes. In civil aviation, the RTCA DO-178 series governs the software lifecycle, but the increasing complexity of silicon devices created a regulatory gap: programmable logic, mixed-signal circuit boards, and custom chips fell outside the software standard's scope. To bridge this divide, RTCA and EUROCAE jointly published DO-254/ED-80 – Design Assurance Guidance for Airborne Electronic Hardware.
The Federal Aviation Administration accepted the document as a means of compliance in 2005. DO-254 complements DO-178C by addressing hardware and firmware contained in avionics equipment, including line-replaceable units, circuit card assemblies (CCAs), FPGAs, PLDs, and ASICs. For engineers building embedded systems on PCBs with a mixture of microprocessors and programmable logic, DO-254 establishes a thorough development and verification methodology designed to prevent design errors from reaching the flight deck.
Why DO-254 Exists
DO-254 responds to two significant trends. First, avionics designers increasingly implement functionality in silicon; the widespread adoption of field-programmable gate arrays (FPGAs) and ASICs means that functions once realized in software now reside inside hardware. Second, firmware development was historically informal, often verified after completion. Early firmware suffered from limited tool support and was difficult to modify once programmed.
Usage of FPGAs eliminated these barriers, offering flexible development tools and high performance. Consequently, logic migrated from software to programmable hardware, yet there was no regulatory equivalent to DO-178. DO-254 was therefore established to provide a disciplined, requirements-driven process for complex electronic hardware (CEH).
Hardware Classification Under DO-254
The guidance applies to various hardware types and classifies them based on verification complexity:
| Hardware Type | Classification Method | Verification Approach |
|---|---|---|
| Circuit boards | Simple vs Complex | Deterministic testing for simple items |
| Sensors | Based on testability | Additional design assurance for complex items |
| Multiplexers | Operational conditions | Independent verification required |
| Switches | Test coverage capability | Requirements-driven validation |
| FPGAs | Typically complex | Full DO-254 process |
| ASICs | Typically complex | Comprehensive verification activities |
Design Assurance Levels and Classification
DO-254 adopts the safety philosophy used by DO-178C. Hardware items are assigned a Design Assurance Level (DAL) from A through E based on the severity of their failure: Level A hardware could cause a catastrophic event, whereas Level E hardware has no effect on safety. Higher DALs demand more thorough planning, traceability, and verification. The guidance specifies particular deliverables: the Plan for Hardware Aspects of Certification (PHAC), a Hardware Development Plan, a Hardware Verification Plan, top-level drawings, and a Hardware Accomplishment Summary. These documents define the development process, describe design and verification activities, and capture evidence for auditors. The Federal Aviation Administration (FAA) and European Union Aviation Safety Agency (EASA) review them at several Stages of Involvement (SOIs) during certification.
Hardware is also classified as simple or complex. A simple item is one that can be completely verified using deterministic analysis and tests across all operating conditions. Most PCBs use complex programmable logic or digital processors running embedded applications and therefore fall under the complex category, requiring the full DO-254 process.
Overview of the DO-254 Lifecycle
The standard defines a structured lifecycle: planning, requirements capture, conceptual design, detailed design, implementation, verification, and transition to production. Design and verification activities must be independent. Verification uses a combination of peer reviews, simulation, analyses, and tests to demonstrate that implementation meets all requirements. DO-254 also emphasizes configuration management, process assurance, and certification liaison, ensuring that hardware items are controlled, documented, and auditable throughout development. Process assurance is broader than software quality assurance because it includes audits of hardware suppliers and manufacturing transition processes.
DO-254 and PCB Design
Planning and Requirements
For a PCB project the starting point is the PHAC. This document summarizes the system context, the hardware's safety role, and the planned DO-254 activities. It references supporting plans: the Hardware Development Plan (HDP) describing the methodology for capturing and decomposing requirements; the Hardware Verification Plan (HVP) detailing verification strategies; the Hardware Configuration Management Plan (HCMP) specifying version control and change management procedures; and the Hardware Process Assurance Plan (HPAP) establishing audits and reviews. These plans form the blueprint for all subsequent work.
PCB development begins with requirements capture. System-level requirements, hazard analyses, and ARP4754A system processes allocate functions to hardware. DO-254 requires that every requirement is traceable to its source and decomposed to a level appropriate for design and verification. Derived hardware requirements must be fed back to the system team for validation. For example, a flight-control board might include requirements for sensor interfacing, environmental tolerance, timing constraints, and redundancy. Each requirement must be uniquely identified, justified, and included in the traceability database.
Conceptual and Detailed Design
During conceptual design the engineering team selects the architecture and components. DO-254 encourages early trade-off analysis to meet safety and performance goals. CCAs are explicitly listed in DO-254's scope, so board-level design decisions become part of the certification record. Engineers must justify part selections (e.g., rad-hard or commercial grade), evaluate COTS devices, and define interfaces. The conceptual design stage also includes preliminary schematics, functional block diagrams, redundancy strategies, and partitioning between hardware and software.
The detailed design phase translates the concept into schematics, netlists, HDL code, and PCB layouts. For FPGAs this includes writing synthesizable VHDL or Verilog, instantiating intellectual-property cores, and developing constraint files. For CBAs the layout must meet signal-integrity, thermal, and EMC requirements. Requirements-based design with traceability is fundamental to DO-254; every schematic component and VHDL entity must be linked back to a requirement. Design reviews, sometimes called peer reviews, are held at each stage to ensure correctness and adherence to the plans. Organizations emphasize having separate design and verification teams to meet DO-254 guidelines. This independence prevents the same engineers who created a design from verifying it, reducing the risk of oversight.
Implementation and Prototyping
Implementation for DO-254 extends beyond simply sending files to fabrication. The standard describes the process of converting high-level representations to technology-specific gates and producing the physical artifacts. For FPGAs this includes synthesis and place-and-route, generating programming files (bitstreams), and creating in-target test benches. For ASICs, it covers back-end layout and manufacture, including the device packaging. Board implementation involves generating fabrication files, assembly drawings, and bills of material. Evidence of tool versions and configuration settings must be maintained for reproducibility. Projects can incur significantly higher costs than non-compliant projects if adequate planning and evidence are lacking. Without structured flow, projects may experience re-work and audit failures due to missing justification.
Verification and Testing
Verification under DO-254 is thorough and systematic. The HVP defines which methods—analysis, simulation, hardware test—will be used to show that implementation satisfies all requirements. Hardware design and verification are conducted independently to avoid confirmation bias. For each requirement, verification procedures specify input stimuli, expected results, test environment, and acceptance criteria.
DO-254 emphasizes both simulation and real-hardware testing. As FPGA complexity increases, verifying pin-level requirements becomes challenging. For DAL A and B FPGAs, every pin-level requirement must be verified through simulation and hardware tests, and the results documented. Traditional board-level testing provides limited visibility of internal FPGA pins; multiple FPGAs on a board can increase delays and complicate verification. Engineers therefore propose augmented verification methodologies such as targeted in-target probes and simulation replay to overcome these challenges.
FPGA Verification Methods and Tools
- VHDL Simulators: Verify algorithmic correctness and timing behavior at the register-transfer level
- Static-Timing Analysis Tools: Ensure timing constraints are met across all operating conditions
- FPGA In-Circuit Testers: Validate hardware implementation on actual silicon
- Functional Test Rigs: Demonstrate system-level behavior under operational scenarios
- Formal Verification: Mathematically prove properties of hardware designs
- Environmental Testing: Validate performance across temperature, vibration, and electromagnetic conditions
DO-254 encourages traceability between tests and requirements: each test case is traced to the requirement(s) it verifies and to the design artifacts used. Problems discovered during verification trigger a controlled problem-report process, with evidence of correction and regression testing. Once verification is complete, a Hardware Accomplishment Summary documents compliance evidence for each objective.
Transfer to Production and Process Assurance
After design and verification, the hardware is transferred to manufacturing. DO-254 requires that production data—Gerber files, assembly instructions, and test procedures—are baselined under configuration management. Process assurance personnel audit supplier processes and ensure that manufacturing follows the approved plans. This includes verifying that part substitutions do not violate design assumptions and that traceability is preserved through the supply chain. For CBAs, the FAA has suggested that level D objectives should be applied regardless of system DAL. Maintaining evidence of production conformance is essential because field units must be proven equivalent to the verified design.
Firmware Versus Software Under DO-254 and DO-178C
In embedded systems it is common for PCBs to host both software-programmable processors and programmable logic. The DO-178C software standard governs code running on general-purpose processors and digital signal processors, while DO-254 governs hardware logic implemented in FPGAs, PLDs, and ASICs. Although both standards promote requirements-driven development and traceability, there are important differences.
Hardware is more deterministic: DO-254 assumes that once manufactured or programmed, hardware behavior is fixed under all conditions. Consequently, validation focuses on ensuring the correctness and completeness of the requirements, and verification ensures that implementation meets them. Software, by contrast, can have dynamic flow control, memory management, and concurrency issues, requiring a broader range of verification activities such as structural coverage analysis.
Process assurance vs. quality assurance: DO-254 introduces process assurance to audit hardware suppliers and manufacturing processes. DO-178C uses quality assurance but does not generally audit hardware supply chains.
Tool qualification: Both standards require that development and verification tools whose output cannot be completely verified must be qualified. For FPGAs this includes synthesis tools, place-and-route, and timing analysis; for software this includes compilers and code generators. Qualification evidence demonstrates that tools operate consistently and correctly within the intended use.
The interplay of DO-254 and DO-178C is particularly evident in firmware. HDL code implementing algorithmic functions in an FPGA is often referred to as firmware. Even though it is "code," it runs as hardware logic once synthesized; DO-254 therefore applies. Firmware development must follow the DO-254 lifecycle: requirements are decomposed to VHDL modules, design is verified through simulation and hardware tests, and configuration management controls versions. Meanwhile, embedded C or Ada code running on a microcontroller on the same board falls under DO-178C. Projects must ensure that interactions between hardware and software (e.g., handshake protocols, timing) are captured at the system level and validated across both standards. This dual compliance can add complexity but ultimately produces a more robust embedded system.
Example: FPGA-Centric Embedded System Under DO-254
To illustrate DO-254 compliance, consider an airborne sensor processing board containing a microprocessor and a DAL B FPGA that performs real-time signal filtering. System requirements allocate the filtering function to hardware to meet latency and determinism constraints. Engineers produce a PHAC that outlines the board's role and states that the FPGA will be developed to DO-254 DAL B while the C code on the microprocessor will follow DO-178C. Requirements are decomposed into FPGA pin-level specifications (e.g., timing of data ready signals, numerical precision, and diagnostic responses) and software-task requirements.
During conceptual design, the team evaluates different FPGA families and chooses a radiation-tolerant part. Schematics and a preliminary PCB layout show data interfaces between the FPGA, analog converters, and the processor. They decide to include test headers on important FPGA pins to facilitate verification, a lesson learned from DO-254 verification challenges. Separate design and verification teams are assigned; the design team writes VHDL modules, while the verification team develops a test bench and simulation environment. Throughout detailed design, each HDL module is traced to requirements and peer-reviewed.
Implementation includes synthesizing the VHDL, performing static timing analysis, generating the bitstream, and building a prototype board. Verification follows the HVP: simulation verifies algorithm correctness, gate-level simulations verify timing, and in-circuit tests confirm pin-level behavior. For DAL B the team uses formal methods to exhaustively verify certain important modules. The verification team documents results and traces them to requirements. Process assurance auditors review that configuration management is being followed and that issue reports are resolved. Once verification objectives are satisfied, the team writes the Hardware Accomplishment Summary and transitions the design to manufacturing.
Throughout this process, the DO-178C team developing the C code for the microprocessor coordinates with the hardware team to ensure that interface timing and error-handling requirements align. System-level integration tests validate the interactions between hardware and software. The result is an embedded system with robust design assurance across both standards.
Conclusion
DO-254 brings discipline to the development of airborne electronic hardware. By requiring requirements traceability, comprehensive planning, independent verification, and robust configuration management, it reduces the risk that design errors escape into production. For PCB design engineers, DO-254 means documenting every assumption, verifying every net and pin, and demonstrating that the board meets its safety obligations. For firmware developers working with FPGAs, DO-254 provides a framework for capturing requirements, writing synthesizable code, verifying it through simulation and hardware tests, and maintaining auditable records. When combined with DO-178C for software, DO-254 ensures that embedded systems used in aviation meet the highest standards of safety and reliability.
Whether you're designing high-speed PCBs for mil-aero embedded systems or a complex RF product, you should work with a design and development firm that can ensure your product will be reliable and manufacturable at scale. NWES helps aerospace OEMs, defense primes, and private companies in multiple industries design modern PCBs and create cutting-edge embedded technology, including power systems for high reliability applications and precision control systems. We've also partnered directly with EDA companies and advanced ITAR-compliant PCB manufacturers, and we'll make sure your design is fully manufacturable at scale. Contact NWES for a consultation.
Ready to start your next design project?
Our Clients and Partners
