DO-278A Overview for Avionics Engineers

DO-278A Introduction

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:

The Basics of DO-278A
DO-278A vs. DO-178C
Ground-based Systems Covered by DO-278A
DO-278A’s Key Processes
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:

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 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:

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:

Suffice it to say that DO-278A has more in common with DO-178C than it has differences. So it’s best if a reader familiarizes themselves with the relevant base standard and then delves into the DO-278A differences.

Differences between DO-278A and DO-178C

The first major difference with DO-278A is its emphasis upon, and allowance for, COTS systems. Whereas DO-178C places the same burden upon COTS software as for custom-development software, DO-278A recognizes that ground-based systems make extensive use of COTS technology and therefore must make accommodations for such. What would happen if DO-278A did not readily accommodate COTS software? Operating systems, graphics, database, and communications protocols are heavily used in DO-278A, extensively more than in onboard avionics via DO-178C. Furthermore, ground-based systems are much more feature-rich than airborne applications, so the software content is much greater, often 10X times larger. Since COTS technologies are generally industry neutral, they are developed without any consideration for DO-278A; thus to reverse-engineer them for DO-278A compliance would result in little value but huge cost. Instead, DO-278A is pragmatic: given the preceding, COTS technologies are allowed. However, COTS technologies within DO-278A require:
➢ Acquisition strategies, defined apriori
➢ Identification and analysis of verifiability
➢ Verification of integration and functionality
➢ Tight configuration management and control
➢ Compliance with associated DO-278A (according to Assurance Level for which COTS is
used within) or justification of Alternate Means of Compliance
For more details on why DO-278A devotes so much attention to COTS-related processes, download our DO-278A whitepaper, linked at the end of this page.

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.

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:

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.

There are no formal or agreed upon AMCs to be applied to DO-278A. However, it is this author’s experience and opinion that DO-278A’s acceptable AMCs are comprised from the following “tool box” which includes the following six categories of AMC’s:

Service experience is almost universally believed to be the first, and most essential, means for alternate means of DO-278A compliance. However, service experience has a high burden of proof, and should be based upon numerous relevant criteria including service length, change control, defect density, history of usage and changes, and degree of hardware/software modifications made during that history or proposed for the new platform. These service experience criteria often exclude the viability of service experience application.

Here are a couple links that provide further information regarding DO-278A:
⦁ For DO-278A Training information, see: https://afuzion.com/training/
⦁ For DO-278A Gap Analysis information, see: https://afuzion.com/gap-analysis/

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

Information Request Form

Please provide the following information to receive your full Whitepaper

Other Free Resources

← Back To All Whitepapers

DO-278A Introduction for Engineers and Managers