Human beings have been flying in airplanes since the Wright Brothers took to the skies more than a century ago. Although the basics have remained the same, many details have changed with the times; commercial airlines (which truly took off in the 1950s) now demand stringent safety precautions to ensure that accidents and mishaps are protected against. When it comes to software aboard passenger and other commercial flights, DO-178c plays a major role.

What is DO-178c?

This document, also known as ‘Software Considerations in Airborne Systems and Equipment Certification,’ is the primary source by which a number of certification authorities — such as the Federal Aviation Administration (FAA), European Aviation Safety Agency (EASA), and Transport Canada — approve commercial software-based aerospace systems. DO-178c was published by the Radio Technical Commission for Aeronautics (RTCA) in 2012 as a replacement to the former document, DO-178b.

DO-178c classifies safety in five levels (known as the Design Assurance Level, DAL, or Item Development Assurance Level, IDAL), each of which relate to the consequences if the software should fail. They are as follows:

• Level A: Catastrophic. If software fails at this level, a plane crash — and resulting passenger fatalities — is entirely possible.
• Level B: Hazardous. Level B failures may result in passenger injuries.
• Level C: Major. This level of software failure can cause passenger discomfort or minor injuries.
• Level D: Minor. Software failure at Level D can cause passenger inconvenience, such as flight delays.
• Level E: No Safety Effect.

Since aviation software is so interconnected with passenger safety, its certification through DO-178c is essential.

What are the major differences between the two?

DO-178b was considered to be out of date compared to software development and verification technologies. Since its release, many FAA Designated Engineering Representatives (DERs) had requested clarification and refinement of the definitions and boundaries it set for the following key concepts:

• High-level requirements
• Low-level requirements
• Derived requirements
• A clearer definition of the exit/entry criteria between systems requirements
• System design
• That of software requirements and software design

The new document kept the same structure of DO-178b, but a number of changes were made. It provided more precise and accurate language and terminology to ensure consistency, created more objectives for the most at-risk levels, and expanded upon multiple other details (i.e., the “hidden objective” applicable to Level A, Parameter Data Item Files, and Software Tool Qualification Considerations).

Here’s an example. Chapter 6.1 (which defines the purpose of the software verification process) in DO-178b states the following in relation to the Executable Object Code: “The Executable Object Code satisfies the software requirements.”

In DO-178c, it reads: “The Executable Object Code satisfies the software requirements (that is, intended function), and provides confidence in the absence of unintended functionality. The Executable Object Code is robust with respect to the software requirements that it can respond correctly to abnormal inputs and conditions.”

Why does it matter?

No matter how huge and powerful airplanes become, they’ll always rely on accuracy to safely travel from Point A to Point B. The software built into these giants is vital to that goal, but software is only as good as the people who interpret it. The clarifications and specifications established by DO-178c are designed to answer any lingering questions and concerns that software developers may have when doing just that. If the difference between a Level A problem and a Level C problem comes down to phrasing, it’s essential that the differences be as clear and concise as possible.

Differentiating between DO-178b and DO-178c is all about detail. Statistically speaking, the more information you have, the more you understand a situation; with DO-178c, aviation software developers are able to know — with significantly less confusion — whether or not the software is safe and functional.