DO-178C flight-deck
DO-178C software compliance support for flight-deck equipment
DO-178C compliance support for flight-deck equipment maps the software lifecycle evidence for a crew-facing unit against the objectives its assurance level demands, then checks that the objective evidence and the installation assumptions actually appear in the package. Suppliers and modifiers use it while assembling a submittal or answering a finding. It reviews the plans, the requirements and design data, verification results, and the human-interface and environmental assumptions the flight-deck installation rests on. You receive a standards map, an evidence gap list, and a closure sequence.
When this review is needed
- A flight-deck unit is nearing submittal and its software evidence has to line up with the objectives for its assurance level.
- A finding asks where a specific DO-178C objective is satisfied in the package.
- The crew interface changed and the human-factors assumptions in the evidence need to be re-checked.
- Software developed to an earlier baseline has to be shown current against the installed configuration.
The problem
Flight-deck software carries a high assurance level because the crew acts on what it presents, so the objective evidence is voluminous and easy to leave with silent holes. Suppliers reach submittal with plans, requirements, and test results that each look complete on their own, but the trace from a high-level requirement through design and code to a verification result breaks somewhere in the middle. The installation assumptions the flight deck depends on, display behavior under fault, timing, crew workload, sit in a system document nobody mapped back to the software.
What gets reviewed
- Software plans and standards checked for the objectives the assurance level requires
- High-level and low-level requirements followed through design and code to verification
- Test and analysis results mapped to the DO-178C objectives they are meant to satisfy
- Human-interface and display-behavior assumptions carried from the system level into the software evidence
- Environmental qualification for the flight-deck unit reconciled with the 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 identifiable evidence in the package
- Requirements trace is unbroken from system allocation through design, code, and test
- Verification results reference the software version actually under approval
- The human-factors and display assumptions in the system safety data appear in the software evidence
- Environmental qualification covers the configuration the software runs on, not an earlier build
Evidence normally required
- The Plan for Software Aspects of Certification and the associated lifecycle plans
- The software requirements, design data, and source or object code references
- Verification cases, procedures, and results with coverage data
- The system-level safety assessment and the assurance level allocated to the software
- DO-160G environmental qualification results for the flight-deck unit
Common discrepancies
- A DO-178C objective with no evidence artifact identified against it in the package
- A requirements trace that breaks between low-level requirements and verification
- Verification results run against a software version earlier than the one submitted
- A crew-interface assumption in the safety data that the software evidence never addresses
What is at stake
A missing objective on a crew-facing unit is not a paperwork detail; it is the kind of gap an authority holds a finding open on until it is closed. Late discovery forces re-verification against a frozen schedule, and an installation assumption that the software evidence never addressed can require rework of both the unit and the flight-deck integration behind it.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Fix the assurance level
Confirm the DAL allocated to the software and the DO-178C objectives that follow from it.
Map objectives to evidence
Place each required objective against the artifact in the package meant to satisfy it.
Trace and check installation
Verify the requirements trace holds and the flight-deck installation assumptions appear in the evidence.
Sequence the gaps
List the unsupported objectives and order them by submittal impact.
What the buyer receives
- A standards map placing each DO-178C objective against the evidence that satisfies it
- An evidence gap list naming the objectives and traces not yet supported
- A closure sequence ordering the gaps by their effect on the submittal
Who uses the output
- Certification leads confirming the software package is ready for the authority
- Software engineers closing a broken trace or a missing verification result
- Compliance managers answering a finding on a specific DO-178C objective
How the work fits into the transaction or program
The support sits between software development and the compliance submittal, where lifecycle data becomes certification evidence. The standards map becomes the index a reviewer follows from objective to artifact, and the gap list drives the verification work that has to close before the flight-deck unit is submitted.
Start with a single asset
Confirm requirements trace through verification.
Regulatory limits
The support maps DO-178C evidence to objectives and flags what is missing. It does not act as a designated engineering representative, make a compliance finding, or approve the software or the flight-deck installation.
What this review does not cover
- Writing or executing the software verification cases
- Acting as a DER or issuing any compliance finding
- Any airworthiness determination on the flight-deck unit
Specific to this review
- Flight-deck software usually sits at DAL A or B because the crew acts directly on its output, so every objective for that level has to be evidenced rather than tailored away.
- The trace most often breaks between low-level requirements and verification, where the volume of artifacts is highest and coverage data is easiest to leave incomplete.
- Human-factors and display-behavior assumptions live in the system safety assessment, so a software package assembled in isolation frequently never maps them back.
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
Do you determine our software's assurance level?
No. The assurance level comes from the system-level safety assessment, and the support works from the level already allocated. It confirms the DO-178C objectives for that level are evidenced in the package. Setting or changing the level is a system-safety activity outside this review.
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.