DO-178C sensor system
DO-178C software compliance support for a sensor system
DO-178C compliance support for a sensor system maps the software lifecycle evidence for an air-data, inertial, or environmental sensor against its assurance objectives, while checking that calibration evidence, installation effects, and environmental qualification are represented in the package. Suppliers and modifiers use it during submittal preparation or a finding response. It reviews the plans, requirements trace, verification results, and the signal-conditioning and fault-detection behavior the sensor output depends on. You receive a standards map, an evidence gap list, and a closure sequence.
When this review is needed
- A sensor unit is nearing submittal and its software evidence has to meet the objectives for its assurance level.
- A finding asks how the software detects a drifting or failed sensor input and flags it downstream.
- The installation location changed and the position-error or thermal assumptions in the software need review.
- The unit applies calibration in software and the evidence has to show that path is verified.
The problem
A sensor feeds data other systems compute on, so a small software error in conditioning or fault detection propagates far beyond the unit itself. The requirements that matter most, range checking, drift detection, cross-comparison, out-of-range flagging, are the ones a supplier tends to under-specify because the nominal signal path is easy and the failure path is not. Calibration coefficients applied in software, and the installation effects that shift a reading, are documented in test and installation reports that the software evidence rarely references.
What gets reviewed
- Software plans and standards checked against the objectives for the assurance level
- Signal-conditioning and calibration requirements traced through design to verification
- Fault-detection, range-checking, and drift behavior reconciled with the DO-178C verification
- Installation effects and position error carried from the installation data into the software assumptions
- Environmental qualification for the sensor 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
- Signal-conditioning and calibration requirements trace to verification results
- Fault detection, range checking, and drift flagging are specified and verified against their requirements
- Installation-effect assumptions in the software match the installation and position-error data
- 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 sensor function
- Verification cases, procedures, and results with structural coverage data
- The calibration data and the installation and position-error reports for the sensor
- DO-160G environmental qualification results for the sensor unit
Common discrepancies
- Drift-detection or range-checking behavior demonstrated in test but not tied to a requirement
- Calibration coefficients applied in software with no verified path from the calibration data
- Installation and position-error effects the software accuracy assumptions never accounted for
- A DO-178C objective left without an identified artifact in the sensor package
What is at stake
A sensor that outputs a plausible wrong value without flagging it corrupts every function downstream, which is why fault-detection objectives get close scrutiny. An unverified drift-detection requirement or an uncredited calibration path holds a finding open, and an installation effect the software never accounted for can invalidate the accuracy claim once the sensor is fitted where it actually flies.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Fix the objectives
Confirm the assurance level and the DO-178C objectives the sensor software must satisfy.
Trace conditioning and fault paths
Follow calibration, range-checking, and drift-detection requirements to verification.
Reconcile installation effects
Match the software's accuracy assumptions to the calibration and position-error data.
Sequence the gaps
List the unsupported objectives and fault-detection 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, fault-detection traces, and calibration links not yet supported
- A closure sequence ordering the gaps by their effect on the submittal
Who uses the output
- Certification leads confirming the sensor software package is ready for review
- Software engineers closing a fault-detection or calibration trace gap
- Compliance managers answering a finding on drift detection or installation effects
How the work fits into the transaction or program
The support ties the sensor software evidence to the calibration and installation data that set its accuracy, so the software and physical sides of the package agree at submittal. Its gap list drives the fault-detection verification and reconciliation work before the unit is submitted, and its map exposes any conditioning or flagging path left unevidenced.
Start with a single asset
Confirm requirements trace through verification.
Regulatory limits
The support maps DO-178C evidence and its links to calibration and installation data, and flags gaps. It does not qualify the sensor accuracy, make a compliance finding, or approve the software or the installation.
What this review does not cover
- Performing the calibration, installation testing, or software verification
- Qualifying the sensor accuracy or acting as a DER
- Any airworthiness determination on the sensor system
Specific to this review
- A sensor error propagates into every function that computes on its output, so fault-detection and flagging requirements carry more weight than the nominal signal path.
- Calibration applied in software needs a verified path from the calibration data, and that path is a frequent gap because the coefficients are treated as data rather than as a verified requirement.
- Installation position error shifts a reading in ways bench testing never sees, so an accuracy claim that ignores installation effects tends to fail once the sensor is fitted where it flies.
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
If calibration is just data, why does it need DO-178C evidence?
When calibration coefficients are applied by software, the path that reads, applies, and bounds them is software behavior, and it has to be specified and verified like any other function. Treating calibration purely as data leaves the code that uses it uncredited, which is a gap an authority will raise on a sensor that feeds other systems.
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.