Safety-critical avionics software has been evolving for decades, providing increased functionality while becoming more complex. In response, regulatory authorities and commercial avionics manufacturers co-authored the RTCA/DO-178 guidelines for developing avionics software. Developers of commercial avionics software must demonstrate compliance with DO-178's guidelines to assure that their software can safely perform its intended function. More recently, the FAA has issued further guidance for so-called reusable software components (RSCs as defined in AC20-148). This guidance requires activities beyond those of DO-178, but the advantage is that certification evidence created under an RSC during one certification can be re-used on subsequent certifications, resulting in considerable cost and schedule savings.

Complexity Drives the Need

The current version of these guidelines is known as DO-178B and is generally considered one of the strictest software standards in existence today. All commercial avionics software in the U.S. is required to comply with the DO-178B standard. The guidelines defined in DO-178B are intended to ascertain that avionics developers employ a degree of process rigor during software development and verification to ensure that the software will perform its intended function with an appropriate level of confidence in safety.

Note that while DO-178B was created to guide commercial avionics software development, developers of military avionics software have adopted it in recent years (Figure 1). However, nowadays military developers rarely adopt DO-178B in its entirety, often due to cost, effort and schedule, nor do they undergo the rigorous compliance audits conducted by the FAA or other certification authorities.

It's All About Process

While DO-178B does not define a process per se, it does define guidelines that a compliant process must meet. DO-178B defines five major software life cycle processes:

Planning: During this process, the software plans for the following four life cycle processes are created. This planning must occur in the context of system/software considerations, especially those related to safety. More on this issue later.

Development: At this stage, software requirements, design and code are created and the resulting software is integrated with target hardware in preparation for testing.

Verification: Artifacts created in the development process are assessed to detect and report any errors (error removal is a development activity).

Software Configuration Management (SCM): This process spans both development and verification and ensures that adequate problem reporting, change control and configuration control are in force.

Software Quality Assurance (SQA): This last process spans development, verification and configuration management to ensure adequate quality controls are enforced.

The Software Planning Process

The primary objective of the planning process is the creation of plans for the other four life cycle processes. These plans define the processes to be used, procedures and standards to be followed, and tools/environments to be used (e.g., compilers/debuggers, testing tools, configuration management tools).

These plans must be created in the context of system/software considerations, especially those related to safety. DO-178B defines five levels of avionics "failure conditions" to which software might contribute (catastrophic, hazardous, major, minor and no effect) and five corresponding levels of software "design assurance" (levels A, B, C, D and E). For example, modern flight control software typically requires Level A design assurance, which imposes the most stringent process rigor, since a fault therein could be catastrophic (i.e., loss of aircraft and loss of life). Conversely, a maintenance function might require only Level D design assurance and very low process rigor, since a fault would have minimal effect on the safe operation of the aircraft. The five levels of software design assurance are directly mapped to the five "criticality" levels of avionics failure conditions. The key difference between Levels A and B is that Level A requires a more thorough degree of testing.