DO-278A Introduction

Download Full 10+ Page DO-278A Whitepaper

DO-178C is one of the main compliance standards for airborne software, and as such it steals a considerable share of avionics engineers’ attention. DO-278A is often called “DO-178C for the ground,” so it’s worthwhile to take a look at where this standard fits in the compliance ecosystem and how it compares to DO-178. This whitepaper explains DO-278A facts, DO-278A risk reduction, and DO-278A COTS software utilization.

DO-278A is also required for eVTOL and Urban Air Mobility (UAM), but many UAM/eVTOL operators don’t realize how DO-278A is used: this AFuzion technical whitepaper explains.

Contents: 

  1. The Basics of DO-278A
  2. DO-278A vs. DO-178C
  3. Ground-based Systems Covered by DO-278A
  4. DO-278A’s Key Processes
  5. Design Assurance (Criticality) Levels

The Basics of DO-278A

Increasingly, aerospace systems containing software on the ground (and satellites involved in aviation navigation and communication) are required to follow DO-278A, which is also 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? Is it the successor or foundation of software compliance for avionics systems? Let’s see.

DO-278A’s proper title is “GUIDELINES FOR COMMUNICATION, NAVIGATION, SURVEILLANCE, AND AIR TRAFFIC MANAGEMENT (CNS/ATM) SYSTEMS SOFTWARE INTEGRITY ASSURANCE.” The operative term here is “CNS/ATM, which 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. It stands on its own as a valuable compliance standard for a specific set of systems that are not covered by DO-178C. DO-278 was updated to DO-278A by the RTCA SC-205 committee and released in December of 2011. DO-178B was being updated simultaneously, which resulted in the release of DO-178C soon after. So the latest version of DO-178 actually came a bit after the latest version of DO-278. 

Airborne software covered by DO-178 is any software that either executes onboard an aircraft or directly influences the execution of such software. DO-278 is equally important because CNS/ATM software can obviously affect aviation safety just as much as airborne software. In fact, in many facets of Communication, Navigation, Surveillance, and Air Traffic Management, a single error could have dire repercussions and result in an accident or even death for pilots or passengers. As a result, it is imperative that CNS/ATM be subjected to a process that has the following provable attributes:

Figure of DO-278A Attributes per AFuzion

DO-278A vs. DO-178C

If you already understand DO-178C, then you have the benefit of implicitly knowing 70 percent to 80 percent of DO-278A, because they are similar. In fact, numerous aspects are identical, including software requriements, design, coding, verification, and tool qualification per DO-330, which 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 also wanting to understand DO-278A. It’s easy to get lost in the similarities and gloss over subtle differences between them. Lack of attention to detail in the differences will result in significant misunderstandings and mistakes when applying DO-278A. 

DO-278A offers both recommendations and assessable objectives. It is intended for use in developing ground and satellite-based systems (containing software) that are involved with aircraft operations. These systems almost always make heavy use of commercial off-the-shelf (COTS) technologies including hardware and software as opposed to software that has been custom-built for a particular avionics application or system. 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.

Ground & Satellite-based Systems Covered by DO-278A

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 that’s not all. Here are some additional application domains that might be subjected to DO-278A guidance.

  • UAS ground controllers/stations (e.g. pilot stations)
  • GPS equipment on the ground related to airplane control
  • Ground-based transceivers, including ADS-B functionality
  • Satellite-based systems to assist/augment aircraft navigation and communications

CNS/ATM Systems often have significant non-certified legacy software/hardware that was rolled out before DO-278A took effect. Instead of requiring you to start over and redevelop these systems from scratch, DO-278A allows for the concept of “Service History,” where “history” denotes evidence of strong record-keeping. This allows software engineers to see how the system has functioned in the past and in what capacity so they can ensure the systems are still safe to use and not prone to malfunctions or errors. The Certification Authorities Software Team (CAST) Memorandum #1 (CAST-1) covers the attributes applicable to applying service history; these are depicted below. Note that few systems ever rank perfectly within each attribute, so the Plan for Software Aspects of Approval (DO-278A’s certification plan) must provide additional guidance on each attribute. The relevant CAST-1 table is provided below:

DO-278A Table 3.3-1 Product Service History Attributes Acceptability

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. Software that doesn’t satisfy the objectives is not acceptable and cannot be certified under DO-278A. 

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 analysis 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. DO-278A is ideally also applied with ARP4754A, which offers guidelines for development of avionics systems, and ARP4761, which provides guidelines for performing safety assessments including the new ARP4754B and ARP4761A. For more information, see our free training video on ARP4754A/B and ARP4761/A below.

DO-278A’s Key Processes

The key DO-278A processes are depicted below:

image of Planning development and verification

As the figure above shows, the Planning process comes first, which 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 for 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 of each activity is in accordance with DO-278A’s specific plans. The five DO-278A plans are depicted below:

Chart prepared by engineers showing DO-278A's five key plans: PSAA, SQAP, SCMP, SWDP, and SWVP, with their full names and relating to different aspects of | Afuzion

Design Assurance (Criticality) Levels

To properly comply with DO-278A, you need to understand the Assurance Level (AL) of the software you are developing. The rigor applied to planning, development, and correctness of your software is directly dependent on its AL—often referred to as a “criticality level.”  There are six levels, with increasing rigor required in planning and development from Level 6, the least rigorous, to the most stringent, Level 1, as depicted below. Note that “Independence” refers to the need for an independent engineer to weigh in during the engineering verification process, not the Quality Assurance process, which is always independent.

Graphical representation of DO-278A verification independence requirements by assurance level (AL), ranging from AL1 (catastrophic) to AL6 (no effect), for engineers. | Afuzion

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. The verification process includes 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:

Assurance Level for DO-278A Introduction for Engineers and Managers

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. In the case of 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 especially 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 also 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 via DO-178C, which adherents use to assess compliance for all executing software including operating systems, graphics libraries, Board Support Packages (BSPs), 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 and 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 process to determine the gap between a given proposed compliance approach and that prescribed by DO-278A. Then AMCs are identified and analyzed for acceptability. Next, the AMCs are 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:

Download Full 10+ Page DO-278A Whitepaper

Other Free Resources

  • Free 30-minute tech telecon to answer any of your tech Q’s
  • Free Sample Certification Checklist
  • Free AFuzion Training Video Sample
  • Request invitations to future AFuzion tech webinars, fee waived (free)

Click Here For Other Free Resources