DO-178C navigation
DO-178C software compliance support for navigation equipment
DO-178C compliance support for navigation equipment lines up the software lifecycle evidence for a position or guidance unit against its assurance objectives, while accounting for the sensor inputs, navigation database, and operational performance standard the unit is built to meet. Suppliers and modifiers use it during submittal preparation or a finding response. It reviews the plans, requirements trace, verification results, database currency handling, and the MOPS alignment the navigation function depends on. You receive a standards map, an evidence gap list, and a closure sequence.
When this review is needed
- A navigation unit is heading to submittal and its software evidence has to meet both DO-178C and the applicable MOPS.
- A finding asks how the software handles a stale or corrupt navigation database.
- Sensor input assumptions changed and the requirements that flow from them need re-tracing.
- The unit claims a navigation performance level that the software evidence has to substantiate.
The problem
Navigation software has to satisfy DO-178C and a separate operational performance standard at once, and the two are documented in different worlds. A supplier can hold a complete-looking software package and a complete-looking MOPS test report, yet never show that the requirements driving the MOPS behavior are the same requirements the DO-178C verification exercised. Database currency is a recurring blind spot: the code path that handles an out-of-date database is real, but the evidence that it was specified and verified is thin.
What gets reviewed
- Software plans and standards checked against the objectives for the assurance level
- Requirements derived from sensor inputs and MOPS traced through design to verification
- Navigation database currency and integrity handling verified against its governing requirements
- MOPS-driven behavior reconciled with the DO-178C verification that exercised it
- Environmental qualification for the navigation unit 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
- Requirements flowing from sensor inputs and the MOPS trace to verification results
- Database currency and integrity behavior is specified in requirements and verified against them
- MOPS test evidence references the same software version as the DO-178C verification
- Environmental qualification matches 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 navigation function
- Verification cases, procedures, and results with structural coverage data
- The applicable navigation MOPS and its test report
- DO-160G environmental qualification results and the sensor interface definition
Common discrepancies
- Database-handling logic exercised in test but not tied to a written software requirement
- MOPS behavior verified separately from the DO-178C evidence, with no shared trace
- A sensor-input assumption that changed without the derived requirements being re-verified
- A DO-178C objective left without an identified artifact in the navigation package
What is at stake
A navigation function that meets its MOPS in test but cannot trace that behavior to verified software requirements leaves a hole an authority will find. If the database-handling logic was never verified against the requirement that governs it, the unit can present stale guidance without flagging it, and closing that after submittal means new requirements, new tests, and a slipped date.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Set the objectives and MOPS
Confirm the assurance level and the navigation performance standard the software must meet.
Trace inputs and behavior
Follow sensor and database requirements through design to verification and to the MOPS.
Reconcile the two records
Confirm the MOPS behavior and the DO-178C verification reference the same software.
Sequence the gaps
List the unsupported objectives and MOPS links 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, traces, and MOPS 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 software package will withstand review
- Software engineers closing a database-handling or MOPS trace gap
- Compliance managers reconciling the MOPS report with the DO-178C evidence
How the work fits into the transaction or program
The support connects the software lifecycle data to the performance standard the navigation unit is sold against, so the two bodies of evidence read as one story at submittal. Its gap list drives the verification and requirements work needed before the unit goes forward, and its map ties MOPS behavior to the software that produces it.
Start with a single asset
Confirm requirements trace through verification.
Regulatory limits
The support maps DO-178C evidence and its links to the MOPS, and flags gaps. It does not qualify the navigation performance, make a compliance finding, or approve the software or the installation.
What this review does not cover
- Running the MOPS or software verification testing
- Qualifying the navigation performance level or acting as a DER
- Any airworthiness determination on the navigation unit
Specific to this review
- Navigation units answer to DO-178C and a separate MOPS, and the frequent gap is that MOPS behavior is never traced to the verified software requirements that produce it.
- Database currency and integrity handling is a recurring blind spot, because the failure path is rarely specified as explicitly as the nominal path.
- A sensor-input change ripples through derived requirements, so an input assumption that moved without re-verification tends to leave a quiet trace break.
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
Our MOPS testing already passed. Why check it against the software evidence?
A passing MOPS report shows the unit behaves correctly in test. It does not by itself show that behavior traces to verified software requirements under DO-178C. An authority looks for that shared trace, and units built by different teams for the two standards are exactly where it goes missing.
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.