Topics / Standards and assurance
DO-278A: keep the CNS/ATM assurance basis explicit.
Ground-based aviation software has its own assurance context. Organize evidence around the applicable requirements and operating conditions, rather than relabeling an airborne checklist.
Use the right document for the project.
RTCA lists DO-278A for software integrity assurance in communication, navigation, surveillance and air traffic management systems. Its software supplements can be used with DO-278A as applicable.
Source: RTCA: DO-278A and supporting documents. Scope and edition reviewed 3 October 2026.
Establish the required edition, assurance scope and acceptance process with the responsible program. This guide proposes a bounded way to organize software-change evidence; it is not a replacement for the standard.
Include the conditions around the software.
Illustrative example
A delayed update looks current.
A service consumes timestamped information from an external feed. A refactor preserves parsing but changes when freshness is evaluated. The review needs the requirement for stale information, assumptions about clocks and delivery, and executions that exercise delayed and reordered updates.
- Record the intended response to missing or stale input.
- Identify the external-interface assumptions.
- Bind results to the tested software and environment.
- Retain remaining integration gaps and their dispositions.
Use the same record for engineering and assurance.
Proof can connect the requirement, software change, hazards and supporting checks. That helps an assurance reviewer inspect the contribution of one change without rebuilding its history.
The whole-system assessment and any required independent activities remain separate obligations. A clean software report does not establish every operational assumption.
Try it on your software
Start with one consequential interface change.
Bring the program’s assurance basis and the evidence needed by its reviewer.