DO-178C display system
DO-178C software compliance support for a display system
DO-178C compliance support for a display system maps the software lifecycle data for a primary or multifunction display against its assurance objectives, while checking that the human-factors assumptions and environmental qualification the display depends on are represented in the evidence. Suppliers and modifiers use it during submittal preparation or a finding response. It reviews the plans, requirements trace, verification results, symbology and format behavior, and the display-under-fault assumptions the crew relies on. You receive a standards map, an evidence gap list, and a closure sequence.
When this review is needed
- A display system is nearing submittal and its software evidence has to line up with the objectives for its assurance level.
- A finding asks how the software behaves when a data source fails and the display has to degrade safely.
- The symbology or format set changed and the human-factors assumptions behind it need re-checking against the evidence.
- Misleading-information hazards drive the assurance level and the software evidence has to substantiate the mitigations.
The problem
A display is where the crew forms its picture of the aircraft, so the software's real hazard is not a crash but showing something wrong convincingly. That risk lives in requirements about failure annunciation, comparison monitoring, and graceful degradation, and those are the requirements that are hardest to write and easiest to leave partly verified. The human-factors work that justifies a symbol, a color, or a declutter rule sits in a separate assessment, and the software package assembled on its own seldom points back to it.
What gets reviewed
- Software plans and standards checked against the objectives for the assurance level
- Format, symbology, and declutter requirements traced through design to verification
- Failure annunciation and graceful-degradation behavior reconciled with the DO-178C verification
- Human-factors assumptions from the system assessment carried into the software evidence
- Environmental qualification for the display tied to the verified software configuration
- Open evidence items sequenced by their effect on the submittal
What gets validated
- Each DO-178C objective for the assurance level maps to an identifiable artifact
- Symbology and format requirements trace from the human-factors assessment to verification
- Failure annunciation and degradation behavior is specified and verified against its requirements
- The misleading-information mitigations named in the safety data appear in the software evidence
- Environmental qualification covers the software configuration under approval
Evidence normally required
- The Plan for Software Aspects of Certification and the lifecycle plans
- Software requirements, design data, and code references for the display function
- Verification cases, procedures, and results with structural coverage data
- The human-factors assessment and the system safety data driving the assurance level
- DO-160G environmental qualification results for the display unit
Common discrepancies
- A graceful-degradation behavior demonstrated in test but not tied to a written requirement
- A misleading-information mitigation in the safety data that the software evidence never addresses
- Symbology requirements that do not trace back to the human-factors assessment behind them
- A DO-178C objective left without an identified artifact in the display package
What is at stake
A display that presents misleading information without flagging it defeats the crew's ability to catch the error, which is why the misleading-information hazard drives the assurance level up. An objective left unevidenced on that path holds a finding open, and a human-factors assumption the software never traced to can force symbology rework and re-verification after the design was thought frozen.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Fix the assurance level
Confirm the DAL driven by the misleading-information hazard and the objectives it demands.
Trace format and failure behavior
Follow symbology, annunciation, and degradation requirements to verification.
Reconcile human-factors basis
Confirm the human-factors assumptions and mitigations appear in the software evidence.
Sequence the gaps
List the unsupported objectives and degradation traces and order them by submittal impact.
What the buyer receives
- A standards map placing each DO-178C objective against its supporting evidence
- An evidence gap list covering the objectives, human-factors traces, and degradation behavior not yet supported
- A closure sequence ordering the gaps by their effect on the submittal
Who uses the output
- Certification leads confirming the display software package will withstand review
- Software engineers closing a degradation or annunciation trace gap
- Compliance managers answering a finding on failure behavior or symbology basis
How the work fits into the transaction or program
The support connects the display software evidence to the human-factors assessment that justifies what the crew sees, so the two read as one package at submittal. Its gap list drives the verification and traceability work on the failure and degradation paths, and its map ties each mitigation to the software that carries it.
Start with a single asset
Confirm requirements trace through verification.
Regulatory limits
The support maps DO-178C evidence and its links to the human-factors and safety data, and flags gaps. It does not perform the human-factors assessment, make a compliance finding, or approve the software or the display installation.
What this review does not cover
- Conducting the human-factors assessment or the software verification
- Setting the assurance level or acting as a DER
- Any airworthiness determination on the display system
Specific to this review
- A display's dominant hazard is misleading information shown convincingly, so failure annunciation and comparison monitoring drive the assurance level more than raw functionality does.
- Symbology and color choices are justified in a human-factors assessment, so a software package built in isolation rarely traces its display requirements back to that basis.
- Graceful-degradation behavior is demonstrated more often than it is specified, so the requirement behind a degraded mode is a frequent missing link.
Sources
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
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
Why does a display carry such a high assurance level?
Because the crew builds its understanding of the aircraft from what the display shows. The worst case is not a blank screen but a plausible wrong picture the crew trusts. Mitigating that, through annunciation, comparison monitoring, and safe degradation, is what pushes the assurance level up, and those mitigations are what the software evidence has to substantiate.
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.