Fayhoo, CC BY-SA 3.0, https://creativecommons.org/licenses/by-sa/3.0 , via Wikimedia Commons

Most people in our industry are familiar with DO-178A  “Software Considerations in Airborne Systems and Equipment Certification.” As the name implies, it is the principle document referenced by certification authorities including the FAA, EASA and Transport Canada to approve airborne civil avionics systems.  

Many will also have heard of DO-278A “Software Integrity Assurance Considerations for Communication, Navigation, Surveillance and Air Traffic Management (CNS/ATM) Systems.” but will likely have less clear perceptions of the characteristics that make it unique.  

 The original version of DO-278 was published as a supplement to DO-178C, designed to modify the guidance of DO-178B for CNS/ATM software. Hence, both DO-178B and DO-278 together were to be referenced for the ground side. As might therefore be expected there is indeed a lot of similarity between their successors, with around 75% of the content being essentially the same. 

Of the differences that remain, many reflect the differing terminology reflecting the differing circumstances. For example:

• The authority responsible for “certification” in DO-178C is substituted by the “approval” authority in DO-278A.
• The scope of “aircraft” or “airborne system” in DO-178C is replaced with “CNS/ATM system” in DO-278A.
• The equivalent to “adaptation” data in DO-178C is known as “parameter” data in DO-278A.
• The document known as the “Plan for Software Aspects of Certification (PSAC)” in DO-178C is denoted as the “Plan for Software Aspects of Approval (PSAA)” in DO-278A.

COTS and legacy code

The less trivial differences between the documents primarily address the fact that CNS/ATM system developers and certification authorities are generally more accepting of reused proven technology than their counterparts in airborne systems – even if that technology was not developed in accordance with DO-278A.

This distinction has resulted in the provision of different criticality categorization “Assurance Level” schemes between the two documents:

DO-178C DALs map directly to DO-278A ALs with one exception. There is no equivalent to DO‐278A’s AL4 which is included to account for CNS/ATM systems where A3 is too stringent, and AL5 is too lenient.

DAL C and AL3 are each concerned with how software is designed and implemented. On the other hand, DAL D and AL5 are concerned only that software fulfils its intended function within a system-level engineering process. AL4 represents a “halfway house” in that it retains some design-level verification (unlike AL5) but it does not require any code-level analysis (unlike AL3).

To cope with the inclusion of COTS and legacy software, DO-278A provides explicit provisions for potentially utilizing “alternate methods” which become Alternate Means of Compliance (AMC). Software that has been verified as compliant using an alternate means is assured to AL4.

In summary

DO-278 was originally written as a supplement to DO-178. DO-278A is a stand-alone document, but is largely similar to DO-178C with the primary differences concerning the use of COTS and legacy software. The distinction between DO-178C DALs and DO-278 ALs is made to help address that point.