What Is DO-278A? A Guide for Compliance Teams

A ground surveillance program can clear factory tests and still sit unapproved for months, stalled by a commercial operating system with no assurance evidence anyone can produce. Teams building software for air traffic control centers run into the same wall. An approval authority wants proof the software was assured to a level matching its safety impact. Navigation aids and surveillance stations feel the same pressure.

Approval authorities expect evidence beyond working code, and DO-278A defines that demonstration. DO-278A borrows DO-178C’s lifecycle structure and adapts it for non-airborne communications, navigation, surveillance, and air traffic management (CNS/ATM) software approval.

This guide covers what DO-278A requires, how it diverges from DO-178C, who has to comply, and how teams handle commercial off-the-shelf (COTS) software and legacy credit under it.

What Is DO-278A?

DO-278A provides guidelines for assuring software in non-airborne CNS/ATM systems, with recommendations commensurate with a level of confidence in safety. The Radio Technical Commission for Aeronautics (RTCA) publishes DO-278A, titled “Software Integrity Assurance Considerations for CNS/ATM Systems,” and EASA references it in its acceptable means of compliance library. RTCA developed it jointly with the European Organization for Civil Aviation Equipment (EUROCAE), which publishes the equivalent document as ED-109A.

This guidance is used by authorities such as the Federal Aviation Administration (FAA) and the European Union Aviation Safety Agency (EASA) when approving software for ground-based systems involved in aircraft operations. It spans the software lifecycle for ground- and space-based applications, including systems within the Next Generation Air Transportation System (NextGen). Unlike its predecessor, DO-278A can be used as a stand-alone reference because it consolidates ground-side software guidance that the original DO-278 handled as a supplement to DO-178B. Ground systems carry aerospace compliance stakes just as high as airborne software, even without a pilot on board.

DO-278A compliance matters because ground-based CNS/ATM software carries real safety consequences, even without passengers on board. A failure in a Mode S surveillance station or an instrument landing system can degrade separation assurance or navigation accuracy just as a failure in airborne avionics can. Approval authorities rely on DO-278A evidence to confirm that assurance work matches that risk before a system enters service. Gaps discovered late in a program tend to be the most expensive and time-consuming to close.

How Does DO-278A Compare to DO-178C?

DO-278A and DO-178C share a common lifecycle structure, while DO-278A adapts the approval model for ground systems. Teams moving from airborne systems development work into CNS/ATM programs tend to notice the differences fastest.

Shared History and Terminology Differences

Both standards trace back to DO-178B, “Software Considerations in Airborne Systems and Equipment Certification,” released in the early 1990s as the basis for airborne software certification. The original DO-278 arrived as a modification layer describing changes to DO-178B for ground-side software, until the joint RTCA Special Committee 205 and EUROCAE Working Group 71 moved away from that approach, as recorded in a joint committee meeting notice, by producing the software document suite together. That shared origin also shaped a set of adapted terms, since DO-278A reflects a different regulatory reality. The table below maps the substitutions teams from airborne work encounter most often.

DO-178C Term	DO-278A Term
Software level	Assurance level
Certification authority	Approval authority
Aircraft / airborne system	CNS/ATM system
Adaptation data	Parameter data
Plan for Software Aspects of Certification (PSAC)	Plan for Software Aspects of Approval (PSAA)

Certification and approval also differ in the underlying regulatory process. Airborne software is certified under aircraft type certification, while ground-based CNS/ATM software gets operational approval instead.

Where DO-278A Guidance Diverges From DO-178C

DO-178C applies airborne assurance expectations to COTS and custom-developed code. DO-278A treats COTS software differently because ground systems often rely on commercial operating systems and communications protocols. It addresses that through a COTS assurance case backed by gap analysis and testing. DO-278A also defines Assurance Level 4 (AL4), which has no DO-178C equivalent. ED-205 is the ground-side security counterpart, while DO-326A and DO-356A pair with DO-178C for airborne systems.

What Are DO-278A’s Key Processes?

DO-278A organizes its guidance around a defined set of assurance activities, starting with the level assigned to each system. That level then shapes how much verification, traceability, and configuration control the program has to demonstrate.

Software Levels and Assurance Requirements

DO-278A defines six Assurance Levels, Assurance Levels 1 through 6 (AL1 through AL6), and the lower the number, the more rigorous the required integrity assurance process. Higher levels must satisfy more of the standard’s objectives, as shown in the table below.

Assurance Level	Failure Condition Severity	DO-178C Equivalent
AL1	Catastrophic	Level A
AL2	Hazardous / Severe	Level B
AL3	Major	Level C
AL4	Between major and minor	No equivalent
AL5	Minor	Level D
AL6	No system effect	Level E

AL4 fills the space between AL3 and AL5. It retains design-level verification and data and control coupling analysis but skips code-level structural coverage, placing it in a gray-box position between AL3’s white-box rigor and AL5’s black-box treatment. Teams may apply it to COTS software where source code is unavailable, but interfaces are documented.

Who Needs to Comply With DO-278A?

Air navigation service providers and acquiring agencies must manage DO-278A obligations across contractor teams. The assigned assurance level, set through a system safety assessment for failure conditions, determines each team’s evidence depth.

CNS/ATM and Ground-Based System Applications

FAA acquisition guidance commonly points to DO-278A as an accepted means of software assurance across acquisition and in-service phases. The acquiring program office coordinates the compliance gap analysis, while the prime contractor integrates systems and subcontractors develop the software. In Europe, EASA acceptable means of compliance address software safety assurance for air traffic management and air navigation service providers under Regulation (EU) 2017/373, and EUROCONTROL specifications name ED-109A directly as an accepted means.

These systems span the full ground and space segment of aviation infrastructure. Each receives its assurance requirements through a system safety assessment that assigns a level based on the software’s contribution to failure conditions:

• Air traffic control automation: ATC software, including field-loadable software, option-selectable software, user-modifiable software, and adaptation data in National Airspace System (NAS) systems.
• Surveillance processing: Surveillance data processing systems, including Mode S ground stations.
• Navigation and landing aids: Ground-based aids such as instrument landing systems.
• Communications infrastructure: Air Traffic Services Message Handling Systems (AMHS) and data communications ground infrastructure supporting NAS operations.
• Remote towers and satellites: Remote tower systems and satellites used in aviation navigation and communication.

Each of these systems carries its own assigned assurance level, set according to how directly its failure could affect flight safety.

What Do DO-278A’s Core Objectives Cover?

DO-278A sorts its objectives into two distinct process families, each with its own rhythm. Development processes run from planning through requirements, design, coding, and integration. Integral processes run alongside them, covering verification, configuration management, quality assurance (QA), and approval liaison.

Software Planning and Development Processes

Planning under DO-278A documents what will be done before doing it, so activities can be shown to meet required objectives. The main planning set includes these core plans across the software lifecycle:

• Plan for Software Aspects of Approval (PSAA): The primary planning document submitted to and accepted by the approval authority, equivalent to DO-178C’s PSAC.
• Software Development Plan (SDP): Covers development activities from requirements through design, coding, and integration.
• Software Verification Plan (SVP): Describes how the team will demonstrate that the software functions as intended, through testing and reviews.
• Software Configuration Management Plan (SCMP): Establishes version control for software and documents across the project.
• Software Quality Assurance Plan (SQAP): Defines how conformance to the agreed plans and standards will be demonstrated.

The approval authority may review lifecycle processes and data at its discretion to confirm compliance with the approval basis and DO-278A’s objectives.

Verification and Testing Requirements

Verification demands early planning in a DO-278A program, since proving verification and validation in critical software systems requires substantial evidence work. Some verification objectives must be satisfied by requirements-based testing, and others by reviews; structural coverage analysis measures which code structures execute during testing. The required coverage level corresponds to the assigned assurance level, engineering independence separates verification from the artifact’s author, and any tool whose processes are relied upon typically needs qualification under DO-330.

Bidirectional requirements traceability is mandatory throughout the DO-278A lifecycle. It runs from system requirements through software requirements, verifications, and the safety analyses that generate derived requirements and tests. COTS-heavy systems make low-level traceability difficult when source or design evidence is missing.

Configuration Management and QA

Configuration management controls versioning of the software and its documents, including reviews, and every version must stay accessible throughout the project. That obligation can sound mundane until an approval authority asks which requirements baseline a two-year-old test campaign ran against.

QA demonstrates conformance to the agreed plans and standards. It covers change control, problem reporting, and transition criteria between lifecycle activities, closing with a conformance review confirming the software and its documents are ready for the approval authority. Every assurance level requires QA independence, unlike engineering verification independence, which varies by level.

Challenges of DO-278A Compliance

DO-278A compliance gets harder in places textbook process descriptions do not cover, and most of that difficulty traces back to software the program did not build itself. Three problems come up again and again on real programs: COTS assurance gaps, traceability breakdowns, and multi-contractor coordination.

Ground systems rely heavily on commercial operating systems, network stacks, and other COTS components where the assigned assurance level applies without much insight into the underlying design or code. Vendors do not typically supply DO-278A-shaped assurance data, so teams have to build a COTS assurance case through gap analysis and testing rather than accepting vendor documentation at face value.

Traceability adds a second layer of difficulty on programs that combine COTS components with custom code. Low-level links from requirements to design and code break down when source or design data for a purchased component is missing, and reviewers still expect the assurance argument to explain how that gap was closed.

Multi-contractor programs compound both problems. When an acquiring agency coordinates gap analysis, a prime contractor integrates systems, and multiple subcontractors each develop pieces of the software, keeping evidence consistent across teams and hand-offs becomes its own ongoing management task.

How Jama Connect® Supports DO-278A Evidence Management

DO-278A’s traceability mandates create a practical evidence-management problem. Teams must keep system requirements, software requirements, verifications, safety analyses, derived requirements, and tests connected as they change. Those links are both approval evidence and engineering references. DO-278A does not mandate a particular development method, and teams increasingly apply it within agile or iterative delivery instead of a single upfront waterfall plan, as long as traceability and planning objectives are still met each increment.

When an upstream requirement changes, downstream artifacts can become outdated before anyone notices. Jama Connect’s suspect link mechanism flags affected artifacts for reassessment, so the evidence chain stays current between approval milestones instead of being rebuilt before each one. This matters most on programs mixing custom code with COTS, where gaps are hardest to spot manually.

Prepare Your DO-278A Compliance Evidence

Structured, queryable evidence holds up better than document snapshots when guidance evolves, or an approval authority asks a new question.

If your team is preparing DO-278A evidence, start a free 30-day trial of Jama Connect to see how that workflow could work for your program.

Frequently Asked Questions About DO-278A Compliance

Is DO-278A the same as DO-178C?

DO-278A and DO-178C are not the same standard, though they share a lifecycle structure. Use DO-278A for ground- or space-based CNS/ATM software, and DO-178C for airborne equipment, based on whether the system needs operational approval or aircraft certification. DO-278A also changes the approval vocabulary, adds AL4, and handles COTS software and service experience differently from DO-178C.

What software assurance levels exist under DO-278A?

DO-278A defines six assurance levels, AL1 through AL6, ranging from catastrophic failure conditions down to no system effect. A system safety assessment assigns the level based on the software’s contribution to that outcome, and the assignment then drives the objectives, verification independence, and structural coverage the program must satisfy.

Does DO-278A apply to my ground system?

DO-278A applies whenever your software runs in a non-airborne CNS/ATM system involved in aircraft operations, and an approval authority invokes the standard. FAA acquisition guidance can invoke it as an accepted means and require a compliance gap analysis on acquired NAS systems, similar to how government programs manage contractor risk elsewhere. European providers meet the same requirement through EASA’s acceptable means of compliance under Regulation (EU) 2017/373 and EUROCONTROL specifications citing ED-109A, and the approval basis determines which evidence set applies.

Can legacy software meet DO-278A requirements?

Yes, but the approval argument has to explain which objectives the legacy software already satisfies and how the program addresses the gaps. Teams can use gap analysis, service-experience credit measured in in-service hours, or reverse engineering of assurance evidence, alone or combined. When defect records, change control history, design data, or source code can’t support the claimed assurance level, a traceability platform such as Jama Connect can help organize bidirectional traceability for the evidence that does exist.

This article was authored by Mario Maldari and published on August 7, 2026.