DO-278A: Introduction

DO-278A is often called “DO-178 for the ground” though it’s much more. Increasingly aerospace systems containing software on the ground are required to follow DO-278A.  Learn DO-278A facts, DO-278A risk reduction, and DO-278A COTS software utilization.

DO-278A is often referred to as “DO-178’s little brother, for ground systems.” However, is DO-278A a little brother or more of a big sister? Let’s see …

DO-278A is properly titled “GUIDELINES FOR COMMUNICATION, NAVIGATION, SURVEILLANCE, AND AIR TRAFFIC MANAGEMENT (CNS/ATM) SYSTEMS SOFTWARE INTEGRITY ASSURANCE.” The operative term here is “CNS/ATM, which again means ground-based aviation software involved with “Communications, Navigation, Surveillance and Air Traffic Management.” With such a long title, it’s a sure bet that DO-278A is NOT merely a little brother to DO-178C. In fact, DO-278 was updated to DO-278A via the RTCA SC-205 committee and released in December of 2011. As any true student of history knows, it is not the absolute date of events which is important, but rather the context of what was occurring simultaneously elsewhere in the world which matters. In the case of RTCA SC-205, it is imperative to understand that DO-178B was being updated simultaneously which yielded DO-178C released late, but soon thereafter.

As with airborne software (software which either executes onboard an aircraft, or directly influences the execution of such software), CNS/ATM can obviously affect aviation safety.  In fact, many facets of Communication, Navigation, Surveillance, and Air Traffic Management impact safety because a single error could have dire repercussions.  As a result, it is imperative that CNS/ATM be subjected to a process which has the following provable attributes:

Voilà: DO-278A is here.

What exactly is DO-278A then?  DO-278A is the second version of the baseline DO-278 document.  It’s a corollary to DO-178C, which is a similar standard for airborne software safety, e.g. software that typically executes onboard aircraft which contributes to flight safety.  If you already understand DO-178C, then you have the benefit of implicitly knowing 70% – 80% of DO-278A because they are similar; numerous aspects are identical including tool qualification for which the corresponding tool qualification guidance, DO-330, applies to both the latest versions: DO-178C and DO-278A.  Also, understanding that DO-278A and DO-178C are similar means you can readily tap into the much larger literature base of DO-178C, as there is relatively little published literature on DO-278A.  However, there is a disadvantage in being familiar with DO-178C and wanting to understand DO-278A: human nature “glosses over” subtle differences between them which results in significant misunderstandings and mistakes when applying DO-278A.  The information herein will both describe DO-278A for beginners and also illuminate differences with DO-178C.

DO-278A is a strong guideline comprising both recommendations and assessable objectives. It is intended for use in developing ground-based systems (containing software) which are involved with aircraft operations. These ground-based systems almost always make heavy use of Commercial Off The Shelf (COTS) technologies including hardware and software. The ground-based systems governed by DO-278A often have much larger, and more diverse, software components than their airborne avionic counterparts. Thus the size, diversity, and increased reliance upon COTS technology all play a key role in the need for DO-278A and the difference between DO-278A and DO-178C.

From DO-278A’s title, it’s easy to discern its primary focus as systems involved with communications, navigation, surveillance, and air traffic management.  But is that all?  No, and that’s why DO-278A is informally referred to as the aviation standard for ground-based systems.  What additional application domains might be subjected to DO-278A guidance?

  • UAS ground controllers/stations (e.g. pilot stations)
  • GPS equipment on the ground when in the airplane control realm
  • Ground-based transceivers, including ADS-B functionality

CNS/ATM Systems often have significant non-certified legacy software/hardware. Instead of starting over and redeveloping these systems from scratch, the concept of “Service History” (where “history” denotes evidence of strong record-keeping) is applied.  The Certification Authorities Software Team (CAST) Memorandum #1 covers the attributes applicable to applying service history; these are depicted below.  Note that few systems ever rank completely high within each attribute, so the Plan for Software Aspects of Approval (DO-278A’s certification plan) must provide details on each attribute.  The relevant CAST-1 table is provided below:

DO-278A has specific objectives based upon the assurance level (AL) of the software.  Higher AL’s must satisfy more DO-278A objectives than lower levels.  After the software criticality level has been determined, you examine DO-278A to determine exactly which objectives must be satisfied for the software.  Now you are ready for planning. This is where DO-278A is similar to building a house: you’ve performed geographic analysis to determine what type of foundation is required—that is your “safety assessment”.  Then you need a Planning Process, followed by a Development Process.  A concurrent Correctness Process is ongoing throughout both Planning and Development. Avionics software engineering under DO-278A is thus the same as building a house and follows the same three-phased process approach. Remember:  DO-278A is ideally applied with ARP4754A and ARP4761:  for a free training video on ARP4754A and ARP4761, view here:

DO-278A’s Key Processes.

The key DO-278A processes are depicted below, roughly to scale:

As can be seen in the above figure: the Planning process comes first, and when complete is followed by a larger Development process. In the background the largest set of processes are performed continuously: Verification, Configuration Management, Quality Assurance, and Approval Liaison. Like DO-178C, a key aspect of Quality Assurance is to ensure the plans are complete and comply with DO-278A, then assessing Engineering’s conformance to those plans. Also, Quality Assurance assesses the transition criteria between the requisite activities to ensure the timeliness and inputs/outputs of each activity are in accordance with plans.  The five DO-278A plans are depicted below:

Design Assurance (Criticality) Levels:

First, you need to understand the Assurance Level (AL) of the software you are developing for DO-278A. The rigor applied to planning, development, and correctness of your software is directly associated with its AL—often referred to as “criticality level.”  There are six levels, with increasing rigor from Level 6 to the most stringent Level 1, as depicted below; note that “Independence” refers to the Engineering verification process, not the Quality Assurance process which is always independent:

What is meant by “Independence” above? This is “engineering” independence, not Quality Assurance independence (which is always required). Engineering independence simply means an artifact verification activity is performed by persons and processes different from those of the artifact’s author. Simple. Just remember that “Verification” equals “Reviews”, “Tests”, and “Analysis”.

Now, contrast the above with DO-178C, which is generally more well-known than DO-278A.  Five of the six DO-278A assurance levels bear a close resemblance to the five assurance levels within DO-278A.  The difference is AL4, as shown below:

As can be seen in the figure above, DO-278A has a special level, AL-4, which is between Level C and D.  So, is it viewed as a level C- or a D+?  The answer is both.  Remember the difference between DO-178B’s Level C and D?  Level D had 28 objectives whereas Level C was much more rigorous with 57 objectives.  That meant Level D was not concerned with how the software was designed or implemented but rather that it fulfilled an intended function while following system-level engineering processes.  So DO-278A’s AL-4 fits squarely in the middle:  AL-4 retains a modest verification of how the software was developed. AL-4 requires data/control coupling analysis (which is design-based) but does NOT require any software structural coverage analysis or robustness testing to code as is required for AL-3.

CNS/ATM systems place greater reliance upon COTS and legacy software than do their airborne counterparts.  Airborne software is normally certified to DO-178C which adherents use to assess compliance for all executing software including operating systems, graphics libraries, Board Support Packages (BSP’s), etc.  However, CNS/ATM system developers and certification bodies have a somewhat different philosophy: it is better to reuse proven technology, even if not developed per DO-278A, than to reinvent all new software which can then be certified to DO-278A.  The rationale for this is simple:  ground based systems make vastly greater use of COTS software/hardware products; they also have vast operational code-bases which precede DO-278.  As a result, DO-278A provides explicit provisions for potentially utilizing “alternate methods”; these methods then become Alternate Means of Compliance (AMC) to achieve certifiability. DO-278A’s glossary identifies a gap analysis processes to determine the gap between a proposed compliance approach and that prescribed by DO-278A. Then AMC’s are identified and analyzed for acceptability; these are then detailed within the CNS/ATM system DO-278A Plan For Software Aspects of Approval (PSAA) for subsequent certification authority review and approval.

For the remaining 10 pages of this AFuzion DO-278A whitepaper, just freely download below:

Free: Download Remaining 10+ Page Paper Here