ARP4754B display systems
ARP4754B development assurance evidence review for display systems
This review reads a display-system package against ARP4754B and reports where its development-assurance evidence falls short. It is built for the supplier's certification team, run before submittal or when a finding is open. The focus is the interplay of software lifecycle data, the human-factors assumptions the display depends on, and the requirement trace that should tie them to the aircraft-level display objectives. You receive a standards map, a gap list, and an ordered plan to close each objective.
When this review is needed
- A display-system package is nearing submittal and the supplier wants its ARP4754B gaps identified while there is time to act.
- Human-factors assumptions behind a display format have shaped the design but were never written as requirements.
- A reviewer has asked how a display behavior traces to an aircraft-level objective and back to the software that renders it.
- A finding response depends on knowing which display objectives the software lifecycle data actually supports.
The problem
Display systems carry heavy DO-178C software content and a layer of human-factors reasoning that shaped every format and alert, yet the human-factors reasoning almost never survives into the requirement set. The software may be verified to its level while the assumptions about what the crew reads, in what order, and how alerts draw attention sit only in design memory. ARP4754B expects those to be captured requirements with validation, and their absence is what a reviewer finds.
What gets reviewed
- DO-178C lifecycle data referenced at the level the display software requires
- Human-factors assumptions captured as requirements with validation evidence
- The trace from aircraft-level display objectives to format, symbology, and alert behavior
- Display behavior verification mapped to ARP4754B objectives
- DO-160G qualification for the display environment the requirements assume
- Configuration control so the reviewed display baseline matches the submitted one
What gets validated
- Human-factors assumptions the display relies on are captured as requirements and validated, not held in design memory
- The software level referenced matches the assurance the display function needs
- Display formats, symbology, and alerts trace to aircraft-level display objectives
- Verification evidence exists for each display behavior an objective calls for
- DO-160G categories match the display's installed environment
Evidence normally required
- The display-system certification plan with its ARP4754B objectives
- DO-178C lifecycle data references for the display software
- Human-factors analysis and any derived design assumptions
- Display requirement and verification sets
- DO-160G qualification reports for the display equipment
Common discrepancies
- A human-factors assumption that drove a display format but was never captured as a requirement
- A display behavior verified in software but not traced to an aircraft-level objective
- An alert-prioritization decision recorded only in design notes, not in the requirement set
- Software lifecycle data complete for a level that the display function's assurance need does not match
What is at stake
When human-factors assumptions are undocumented, a reviewer cannot see that the display behavior was validated against a real crew need, and the objective goes unmet no matter how complete the software data is. Reconstructing that reasoning after a finding is slow, and a display format questioned late can pull software and integration evidence back into rework.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Recover the human-factors reasoning
Identify the display assumptions that shaped format, symbology, and alerts and check whether each is a captured requirement.
Match software to assurance need
Confirm the DO-178C level referenced fits the assurance the display function actually requires.
Trace the display behavior
Follow each behavior from the aircraft-level objective through to the software that renders it.
Order the closures
Sequence so human-factors requirement capture precedes the trace and verification above it.
What the buyer receives
- A standards map placing each ARP4754B objective against the display evidence that answers it
- A gap list that names the missing human-factors requirement or trace for each open objective
- A closure order that captures the human-factors requirements before the trace built on them
Who uses the output
- Certification engineers assembling the display-system submittal
- Engineering leads deciding how to formalize human-factors reasoning into requirements
- Compliance managers tracking objective closure before a finding response
How the work fits into the transaction or program
The review runs before submittal or after a first finding, giving the display team a clear view of where software rigor and human-factors reasoning diverge in the evidence. Its closure order feeds the certification plan so the effort goes to capturing the assumptions ARP4754B expects rather than re-proving software already done.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA apply distinct human-factors and flight-deck design expectations to display systems, and an evidence set framed for one may not fully answer the other's objectives. The review notes where the human-factors requirements will need extension for the second authority.
Regulatory limits
The review maps evidence to ARP4754B objectives and identifies gaps. It does not perform human-factors evaluation, agree a compliance finding, or make an airworthiness determination on the display system.
What this review does not cover
- Authoring the missing human-factors requirements or validation
- Running DO-178C lifecycle activities or DO-160G qualification
- Agreeing the display finding with the authority
Specific to this review
- Display systems fail ARP4754B most often on the human-factors side, because the reasoning that shaped a format lives in design memory and never becomes a validated requirement.
- Alert prioritization is a common blind spot: the decision was deliberate but recorded only in notes, so no objective can be shown met against it.
- Complete DO-178C data proves the software works as built, but it cannot answer whether the display behavior was validated against a crew need, which is a separate ARP4754B objective.
Sources
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).
Federal Aviation Administration. FAA type certification process, certification basis establishment, and compliance findings.
Frequently asked questions
Our DO-178C data is complete. Why are there still ARP4754B gaps?
DO-178C data shows the software was developed to its level. ARP4754B additionally asks that the display behavior trace to a validated requirement, including the human-factors assumptions behind it. Those assumptions are usually the gap, and complete software data does not fill 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.