DO-278A Introduction for Engineers and Managers

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:

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. 

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

Download Full 10+ Page DO-278A Whitepaper

← Back To All Whitepapers