DO-254 navigation
DO-254 hardware compliance support for navigation equipment
DO-254 compliance support for navigation equipment maps the airborne electronic hardware assurance data for a position or guidance unit against its design assurance objectives, while accounting for the sensor interfaces, database-handling hardware, and performance standard the unit is built to. Suppliers and modifiers use it during submittal preparation or a finding response. It reviews the hardware plans, requirements validation, device design, verification results, and the MOPS-driven behavior implemented in hardware. You receive a standards map, an evidence gap list, and a closure sequence.
When this review is needed
- A navigation unit with programmable hardware is nearing submittal and its DO-254 evidence has to meet the design assurance level and the MOPS.
- A finding asks how the hardware handling of sensor interfaces or the navigation database was validated and verified.
- The device design changed to support a new sensor interface and the assurance data has to catch up.
- MOPS behavior is partly realized in hardware and the evidence has to substantiate that path.
The problem
A navigation unit splits its function across software and programmable hardware, and the interface logic, sensor front ends, timing, and database access paths, frequently lands in an FPGA whose DO-254 evidence lags the software. Suppliers can show a clean MOPS report and a solid software package, then struggle to prove that the hardware implementing a timing-critical or interface-critical requirement was validated and verified to its design assurance level. The boundary between what the software claims and what the hardware actually does is where the assurance argument most often has a hole.
What gets reviewed
- Hardware plans and standards checked against the objectives for the design assurance level
- Requirements for the sensor-interface and database-handling hardware validated and traced to the design
- Device design for the programmable parts reconciled with the requirements it implements
- MOPS-driven behavior realized in hardware mapped to its verification results
- Environmental qualification for the navigation unit tied to the verified device configuration
- Open evidence items sequenced by their effect on the submittal
What gets validated
- Each DO-254 objective for the design assurance level maps to an identifiable artifact
- Requirements for interface and database-handling hardware are validated and trace to the design
- Verification results reference the device configuration under approval
- Behavior from the MOPS implemented in hardware is verified against its governing requirements
- Environmental qualification matches the device configuration under approval
Evidence normally required
- The hardware plans, including the plan for hardware aspects of certification
- Requirements, validation records, and design data for the programmable devices
- Verification and validation cases, procedures, and results with coverage or analysis data
- The applicable navigation MOPS and the allocation of its behavior across hardware and software
- DO-160G environmental qualification results and the sensor interface definition
Common discrepancies
- Interface or timing logic implemented in an FPGA with requirements that were never validated
- MOPS behavior allocated to hardware but verified only at the software or bench level
- A DO-254 objective with no identified artifact for the navigation device
- A device design change for a new sensor interface that the assurance data never caught up to
What is at stake
A navigation function whose hardware path was not verified to its design assurance level leaves an integrity gap the authority will hold against approval, especially where the hardware handles timing or interface logic the position solution depends on. Reconstructing requirements and verification for a complex device late in the program is expensive, and a MOPS behavior realized in unverified hardware can require re-verification once the gap is found.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Fix the design assurance level
Confirm the DAL allocated to the hardware and the DO-254 objectives and MOPS it must meet.
Validate interface requirements
Confirm sensor-interface and database-handling requirements are validated and trace to the design.
Map MOPS behavior in hardware
Place MOPS behavior realized in hardware against the verification that credits it.
Sequence the gaps
List the unsupported objectives and hardware allocations and order them by submittal impact.
What the buyer receives
- A standards map placing each DO-254 objective against its supporting hardware evidence
- An evidence gap list covering the objectives, requirement validations, and MOPS-in-hardware links not yet supported
- A closure sequence ordering the gaps by their effect on the submittal
Who uses the output
- Certification leads confirming the navigation hardware package will withstand review
- Hardware engineers closing an interface-logic or MOPS-in-hardware verification gap
- Compliance managers reconciling the hardware and software allocation of MOPS behavior
How the work fits into the transaction or program
The support closes the seam between the navigation software package and the programmable hardware that implements part of the function, so the two allocations agree at submittal. Its gap list drives the requirement-validation and verification work on the hardware path, and its map shows where MOPS behavior realized in hardware is credited to verified evidence.
Start with a single asset
Confirm requirements trace through verification.
Regulatory limits
The support maps DO-254 evidence and its links to the MOPS allocation, and flags gaps. It does not qualify the navigation performance, make a compliance finding, or approve the hardware or the installation.
What this review does not cover
- Performing the hardware verification, requirement validation, or MOPS testing
- Qualifying the navigation performance or acting as a DER
- Any airworthiness determination on the navigation unit
Specific to this review
- Navigation function splits across software and an FPGA, and the hardware side, timing and interface logic, is where DO-254 evidence most often lags the software.
- MOPS behavior is allocated across hardware and software, so behavior realized in hardware but verified only at the bench leaves an uncredited assurance path.
- The software-to-hardware boundary is where the assurance argument breaks, because each side assumes the other proved the interface.
Sources
RTCA. Design assurance objectives and lifecycle data for airborne electronic hardware (FPGA/ASIC/PLD).
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Frequently asked questions
How do we know which MOPS behavior needs DO-254 evidence versus DO-178C?
It follows the allocation. Where a navigation requirement is implemented in programmable hardware, its assurance is a DO-254 matter; where it is implemented in software, it is DO-178C. The frequent gap is behavior allocated to hardware but verified only at the software or bench level, which leaves the hardware path uncredited. Mapping the allocation is the first step this support takes.
Relevant glossary terms
Related pages
Where this fits
Talk to an engineer who has done this work
We will walk through your current state, the records or evidence involved, and a scoped first engagement.
Talk through the aircraft, records, evidence, deadline, and next useful step.