DO-178C communication
DO-178C software compliance support for communication equipment
DO-178C compliance support for communication equipment maps the software lifecycle evidence for a radio or datalink unit against its assurance objectives, while accounting for the radio-performance, antenna, electrical-load, and environmental substantiation the communication function depends on. Suppliers and modifiers use it during submittal preparation or a finding response. It reviews the plans, requirements trace, verification results, and the tuning, channel, and mode-control behavior the communication role relies on. You receive a standards map, an evidence gap list, and a closure sequence.
When this review is needed
- A radio or datalink unit is nearing submittal and its software evidence has to meet the assurance objectives.
- A finding asks how the software controls channel selection, tuning, or mode under fault conditions.
- The antenna or electrical-load substantiation changed and the software assumptions built on it need review.
- The unit interfaces with a datalink protocol whose behavior the software evidence has to substantiate.
The problem
Communication software controls what the crew and the ground can and cannot hear, so a wrong channel, a stuck transmit, or a silent tuning fault has operational weight the code review alone does not capture. Suppliers reach submittal with clean lifecycle artifacts and a passing bench test, but the fault behavior, what the radio does when tuning fails or a mode command is rejected, is where requirements are thin and verification is thinner. The electrical-load and antenna substantiation that the transmit path assumes rarely appears anywhere near the software evidence.
What gets reviewed
- Software plans and standards checked against the objectives for the assurance level
- Channel, tuning, and mode-control requirements traced through design to verification
- Fault-handling behavior for the communication function reconciled with the DO-178C verification
- Antenna, transmit-power, and electrical-load assumptions carried from substantiation into the software evidence
- Environmental qualification for the communication 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
- Channel, tuning, and mode-control requirements trace to verification results
- Fault-handling behavior is specified in requirements and verified against them
- Antenna and electrical-load substantiation aligns with the software's transmit-path assumptions
- 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 communication function
- Verification cases, procedures, and results with structural coverage data
- Antenna, transmit-power, and electrical-load substantiation for the installation
- DO-160G environmental qualification results for the communication unit
Common discrepancies
- Fault-handling behavior for tuning or mode control that has no written software requirement
- Electrical-load and antenna substantiation the software transmit-path assumptions were never checked against
- A DO-178C objective with no evidence artifact identified in the communication package
- Bench-test evidence for radio behavior run on a software version earlier than the one submitted
What is at stake
A tuning or mode-control fault that the software handles incorrectly can leave the crew without a working radio at the moment they need it, so an authority scrutinizes that path hard. A missing objective or an unverified fault requirement holds the finding open, and if the software's load and antenna assumptions were never tied to the installation substantiation, the approval does not transfer cleanly to the next airframe.
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 communication software must satisfy.
Trace control and fault behavior
Follow channel, tuning, and mode-control requirements, including fault paths, to verification.
Reconcile installation assumptions
Match the software's antenna and electrical-load assumptions to the installation substantiation.
Sequence the gaps
List the unsupported objectives and fault-handling 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-handling traces, and installation links not yet supported
- A closure sequence ordering the gaps by their effect on the submittal
Who uses the output
- Certification leads confirming the communication software package is ready for review
- Software engineers closing a fault-handling or transmit-path trace gap
- Compliance managers answering a finding on channel, tuning, or mode-control behavior
How the work fits into the transaction or program
The support ties the radio software evidence to the antenna and load substantiation the transmit path draws on, so the software and installation sides of the package agree at submittal. Its gap list drives the fault-handling verification and reconciliation work before the unit is submitted, and its map surfaces any communication 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 installation substantiation, and flags gaps. It does not qualify the radio performance, make a compliance finding, or approve the software or the installation.
What this review does not cover
- Running the software verification or radio bench testing
- Qualifying the radio performance or acting as a DER
- Any airworthiness determination on the communication unit
Specific to this review
- Fault behavior is the weak spot in communication software evidence: a stuck transmit or a rejected tuning command has operational weight the nominal-path testing never exercises.
- The transmit path's electrical-load and antenna assumptions live in installation substantiation, so the software evidence assembled alone rarely reconciles to them.
- A silent tuning or mode fault can leave the crew without a usable radio, so an authority weighs the fault-handling objectives more heavily than the nominal ones.
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 bench testing shows the radio works. Where does software evidence still fall short?
Bench testing usually exercises the nominal path: correct channel, correct mode, successful transmit. The fault paths, a failed tune, a rejected mode command, a stuck transmit, are where software requirements and verification most often thin out, and they are exactly what an authority examines because that is where the crew loses a working radio.
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.