Author: Dr. Alp Kaçar

Introduction

The history of software in the aviation industry began in the 1960s with the introduction of digital computers in aircraft. Initially, software was used for basic calculations and essential tasks like autopilot functions. However, during the 1970s and 1980s, its role rapidly expanded to include flight control systems, navigation, and communication systems. During this period, increasing awareness of software reliability and safety led to the development of standards like DO-178. By the 1990s, software had become an integral part of aviation systems, with modern aircraft featuring millions of lines of complex code. Today, software is a critical component in both commercial and military aviation, playing a fundamental role in enhancing flight safety and efficiency.

DO-178, initially developed in the early 1980s to establish safety standards for aviation software, was revised in 1992 and renamed DO-178B. This version remained the industry standard until 2011 when the more advanced DO-178C was introduced. DO-178C serves as a comprehensive guide for ensuring software safety in aviation. This article outlines the primary steps in developing DO-178C compliant software.

What is DO-178C?

DO-178C, known as “Software Considerations in Airborne Systems and Equipment Certification,” is the latest version of guidelines specifying the processes and methods to be applied during the development of aviation software. Its objective is to minimize software errors and ensure software safety, as demonstrated in Table 1, which highlights the relationship between software-related failures and Development Assurance Levels (DAL).

1. Planning

The DO-178C compliance process begins with comprehensive planning and adherence to standards. Key documents prepared during this phase include:

• Plan for Software Aspects of Certification (PSAC)
• Software Development Plan (SDP)
• Software Verification Plan
• Software Configuration Management Plan (SCMP)
• Software Quality Assurance Plan (SQAP)

These documents detail how the software will be developed and validated to meet safety requirements. Standards such as the Software Requirements Standard (SRStd), Software Design Standard (SDStd), and Software Coding Standard (SCStd) should also be established during this phase. At the end of this stage, during the SOI1 review conducted by the certification authority, the compliance of these plans and standards with DO-178C is evaluated.

2. Development

2.1. Requirements Development

High-level software requirements are developed using outputs from the system lifecycle processes. These requirements address functional, performance, interface, and safety needs, as defined by the Software Requirements Standard (SRStd).

2.2. Software Design

Using the Software Design Standard (SDStd), high-level requirements are refined through iterative design processes to create a software architecture. This architecture forms the basis for generating low-level requirements for implementing source code.

2.3. Coding

After the design phase, software coding begins. Source code is developed using the Software Coding Standard (SCStd) and derived from the architecture and low-level requirements.

2.4. Integration

During integration, source code is compiled, loaded onto the target system, and converted into executable object code. This phase concludes with the SOI2 review, where the certification authority evaluates the compliance of software lifecycle records with the planning documents.

3. Verification

The goal of software verification is to identify and report errors introduced during development. Verification involves review, testing, and analysis activities to ensure:

• System requirements are correctly and completely transformed into high-level software requirements.
• High-level requirements are accurately and completely transformed into low-level requirements and architecture, with proper traceability between them.
• Low-level requirements and architecture are correctly and completely implemented in the source code.
• Executable object code meets all software requirements and lacks unintended functionality.
• The software functions appropriately under abnormal inputs and conditions.

During the SOI3 review, verification evidence (e.g., reviews, test results, and analyses) is evaluated for compliance with the planning documents.

4. Configuration Management

The Configuration Management process ensures that all software lifecycle activities align with the Software Configuration Management Plan (SCMP). This process maintains and records all software lifecycle data.

5. Quality Assurance

The Quality Assurance process, defined in the Software Quality Assurance Plan (SQAP), ensures compliance with certification requirements. It verifies that objectives are met, deficiencies are identified and resolved, and lifecycle outputs meet certification standards.

6. Certification

The certification process establishes communication between the applicant and the certification authority throughout the lifecycle. Key goals include approval of the PSAC and submission of compliance evidence. The Software Accomplishment Summary (SAS) is issued following the SOI4 review, which evaluates the overall compliance of lifecycle records with planning documents.

7. Software Lifecycle Data

The following data must be maintained throughout the process to meet the required standards:

• Plan for Software Aspects of Certification
• Software Development Plan
• Software Verification Plan
• Software Configuration Management Plan
• Software Quality Assurance Plan
• Software Requirements Standards
• Software Design Standards
• Software Code Standards
• Software Requirements Data
• Design Description
• Source Code
• Executable Object Code
• Software Verification Cases and Procedures
• Software Verification Results
• Software Life Cycle Environment Configuration Index
• Software Configuration Index
• Problem Reports
• Software Configuration Management Records
• Software Quality Assurance Records
• Software Accomplishment Summary
• Trace Data
• Parameter Data Item File