Display hardware
DO-254 hardware assurance evidence support for display systems
This support looks at the DO-254 evidence for a display system's airborne electronic hardware and checks that it demonstrates the assurance the plan claims where hardware and software share the same box. It suits primary flight displays, multifunction displays, and their graphics and driver hardware. A specialist reads the requirements, design, and verification data, watches the boundary where DO-254 hardware meets DO-178C software, and confirms the DAL holds on both sides. You receive a standards map by objective, a gap list ordered for closure, and a sequence to clear findings before the package is submitted.
When this review is needed
- A flight display is heading for authorization and the hardware assurance data needs a read against the plan.
- A finding lands on the graphics hardware and it is unclear whether it is a DO-254 or DO-178C question.
- Requirements were allocated between hardware and software and the split needs checking for coverage gaps.
- A display driver device changed and the hardware verification has to be current for the fielded build.
The problem
On a display unit the hard part of DO-254 is the boundary. Function is split between programmable hardware and the software running on it, and requirements allocated to one side can fall through if the interface between the two assurance processes is loose. A display can carry full DO-254 hardware records and full DO-178C software records and still leave a requirement covered by neither, because each process assumed the other owned it.
What gets reviewed
- Requirements allocated to the display hardware, including the split from the software side
- Design and verification data for the graphics and driver hardware against the assigned DAL
- The interface between the DO-254 hardware process and the DO-178C software process
- Coverage of allocated requirements so none fall between the two assurance sets
- Configuration records fixing the hardware verification to a known device build
- Derived hardware requirements passed into the safety assessment
What gets validated
- Every requirement allocated to hardware is verified on the hardware side and not assumed into software
- The hardware and software interface requirements are consistent between the two evidence sets
- Design and verification data support the DAL the display function is assigned
- Programmable graphics or driver devices follow the assurance path the plan states
- Hardware verification results match the device configuration named in the records
Evidence normally required
- The hardware plans and verification plan for the display unit
- Requirements allocation between the display hardware and software
- Design and verification data for the airborne electronic hardware
- The DO-178C software lifecycle data for the interface it shares
- The safety assessment setting the DAL for the display function
Common discrepancies
- An allocated requirement each process assumed the other verified, so neither did
- An interface requirement stated differently on the hardware and software sides
- A graphics device with an assurance path that does not match the plan
- Hardware verification tied to a device build the submitted configuration has superseded
What is at stake
A gap at the hardware and software boundary is the kind a reviewer finds by asking who verified a specific allocated requirement, and the answer being nobody. On a primary display that failure reaches deep into the flight deck, so the finding is serious and the rework crosses two teams. Catching the allocation gap before submittal keeps it a paperwork fix instead of a cross-domain reverification.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Read the allocation
Establish how requirements were split between the display hardware and software and what each side owns.
Walk the hardware trace
Follow each hardware requirement to verification and design against the assigned DAL.
Close the boundary
Confirm interface requirements agree across the two evidence sets and no allocated item is orphaned.
Sequence the fixes
Order the gaps so boundary items, which touch two teams, are resolved with clear ownership.
What the buyer receives
- A standards map covering each DO-254 objective for the display hardware
- A gap list ordered by closure effort, with boundary items called out
- A closure sequence linking each open item to the evidence that resolves it
Who uses the output
- Certification leads confirming both sides of the display package align before submittal
- Hardware and software engineers reconciling allocated requirements across the boundary
- Compliance managers tracking open objectives across two coupled evidence sets
How the work fits into the transaction or program
The mapping runs once both the hardware and software evidence are nominally complete, sitting at the seam between them. It reads the allocation the way a reviewer will, checking that no requirement fell between the two processes, and its output feeds the combined compliance narrative the display authorization depends on.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both accept DO-254 and DO-178C for airborne hardware and software, and both examine how allocated requirements are covered across the boundary. The mapping notes where the allocation would satisfy one authority but leave an open question for the other under the applicable basis.
Regulatory limits
This work maps hardware evidence to the DO-254 objectives and checks the boundary with the software evidence. It does not approve the display design, issue a TSO or STC, determine airworthiness, or replace the authority's acceptance of either evidence set.
What this review does not cover
- Authoring the hardware or software lifecycle data
- Performing the display verification or human-factors evaluation
- Issuing any approval or compliance finding for the authority
Specific to this review
- The most costly DO-254 gap on a display is a requirement that fell between the hardware and software processes, since each side assumed the other owned it.
- Interface requirements written independently on the two sides drift apart quietly, and a reviewer tests them by reading both statements together.
- A display can hold complete DO-254 and DO-178C records and still have a coverage hole, because completeness on each side does not prove the allocation closed.
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
Our hardware and software packages are each complete. Why review the boundary?
Completeness on each side does not prove the allocation between them closed. The gap that surfaces at review is usually a requirement both processes assumed the other verified, and only reading the two together finds it.
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.