DO-178C Software Compliance for Aerospace and Defense

The Radio Technical Committee for Aeronautics (RTCA) DO-178C is a functional safety standard that provides guidance and considerations for the production of software for airborne systems and equipment. The aim is to ensure that the system performs its intended function with a level of confidence in safety that complies with airworthiness requirements. If an aircraft is to fly over commercial U.S. airspace, compliance with the standard is required.

DO-178C provides the following guidance:

• Objectives for software life cycle processes
• Activities that provide a means for satisfying those objectives
• Descriptions of the evidence in the form of software life cycle data that indicate that the objectives have been satisfied
• Variations in the objectives, independence, software life cycle data, and control categories by software level
• Additional considerations (for example, previously developed software) that are applicable to certain applications
• Definition of terms provided in the glossary

DO-178C covers the full engineering life cycle. From planning, development, verification, quality assurance, liaison, and certification. It is subdivided into 12 sections. Section 1, not shown expresses the purpose, scope, and how to use the document.

RTCA was founded back in 1935. They are an independent standards development organization and serve as the basis for government certification of equipment used by the tens of thousands of aircraft flying daily through the world’s airspace.

RTCA is a private, not-for-profit corporation, which works closely with the Federal Aviation Administration (FAA) and industry experts from the U.S. and around the world, such as the European Organization for Civil Aviation Equipment (EUROCAE) working group to help develop this comprehensive, contemporary aviation standard. The EUROCAE is a non-profit organization with the objective of developing standards for European civil aviation.

The original DO-178 standard was released back in 1982. However, it was not considered useful. As a result, the DO-178A revision followed, published in 1985. This revision focused more on modern software engineering principles and verification practices. It introduced a correlation between critical failure conditions with level numbers 1, 2, and 3. Level 1, which you may know better as Development Assurance Level (DAL) was the strictest.

In December 1992, revision DO-178B was released, which shifted from a “how to” type of document to a “what to do” type of document. A big focus was put on objectives that your software process needs to satisfy in order to reach compliance and ultimately certification.

Another noticeable change was to the number of possible critical failure conditions defined in DAL.They grew to five software levels and changed from numbers to letters A through E. Level A was the most stringent and Level E meant no safety requirement. Also, testing your requirements was strongly emphasized. It advised not to look at the code to create test cases, but to look at your requirements. It was backed by structural code coverage to ensure that you have covered everything.

DO-178B also incorporated bidirectional traceability between systems, high- and low-level requirements, including test cases, and down to the code to show that all the requirements have been implemented. The idea of having tools qualified for use was introduced.

Today, we’re at revision C. Released in January 2012, DO-178C removed imprecise wording found in DO-178B for clarification. It also became a joint effort between RTCA and EUROCAE. But the major difference between DO-178B and DO-178C is the adoption of a modular approach to supplemental guidance documents. You now have supplemental standards, including the following.

This guide provides a condensed overview of each of the DO-178C sections, highlighting the key takeaways.

System Aspects Relating to Software Development, Section 2

Section 2 discusses the system life cycle processes, the artifacts produced, how they flow down into the software life cycle and the information flow between these processes. A big part of this is requirements analysis, where the software system requirements are initially developed from the system operational requirements or customer requirements, and how these artifacts flow into the software life cycle.

In the software life cycle, requirements decomposition continues, software verification takes place, and ultimately certification.

Though DO-178C captures the flow between system and software life cycles in the diagram above, the topic is well defined in the SAE ARP4754A standard, Guidelines for Development of Civil Aircraft and Systems.

Section 2 discusses the following topics:

• System requirements allocation to software
• Information flow between the system and software life cycle processes and between the software and hardware life cycle processes
• System safety assessment process, failure conditions, software level definitions, and software level determination » Architectural considerations
• Architectural considerations
• Software considerations in system life cycle processes
• System considerations in software life cycle processes

One other important part of section 2 is determining the software level classification or DAL. Catastrophic results equate to failure of flight control software where an aircraft would go down and many lives would be lost. This would be classified as software level A.

Hazardous is a step down, so serious or fatal injury to a relatively small number of the occupants other than the flight crew would be software level B. The classification continues to go down to software level E where there’s no safety concern if failure were to occur.

Another perspective or side of this classification is quality assurance. With each increased level from level E to level A, there’s an increased number of objectives that need to be met. For example, there’s an increase in traceability between artifacts produced during product development. Also, there’s an increase in software testing. The software may need to satisfy assembly or object code coverage instead of just statement, branch, and MC/DC coverage.

To share a best practice, if your software is classified at level B or lower, you may want to try to achieve some or all of the next higher software level objectives. The additional effort between some of the development assurance levels may not be too substantial and the benefits could very well pay off if customer requirements become more stringent.

Below is the well-known V-model. The right side captures the system and software design phases while the left side captures the verification phases. Standard ARP4754 is your go-to document on the development of aircraft systems considering the overall aircraft operating environment and functions. This includes validation of requirements and verification of the design implementation for certification and product assurance.

Software Life Cycle, Section 3

Section 3 discusses the aspects of the software life cycle process. The well-known sequence through the SDLC is requirements management, design, coding, and integration. DO-178C does not recommend a development process to use. It’s left up to organizations to make that decision based on their own experience and factors like current technology, such as Agile, DevSecOps, CI/CD, or customer requirements. Whatever process you choose, the standard’s objectives that must be met are not obstructed by the process.

DO-178C software life cycle processes include the following:

• Software planning process. Defines and coordinates the activities of the software development and integral processes for a project.
• Software development processes. Produce the software product. This process is comprised of processes for requirements, design, coding, and integration.
• Integral software processes. Ensure the correctness, control, and confidence in the software life cycle processes and their outputs. These include verification, configuration management, quality assurance, and certification liaison.

Software Planning Process, Section 4

Section 4 discusses the objectives and activities of the software planning process. The objectives are clearly defined and captured in Table A-1 of the standard. There are seven objectives that must be satisfied based on the software level (A-D). These objectives include defining the following:

• Software life cycle process
• Inter-relationships between processes
• Methods and tools to use
• Development standards to use for ensuring safety
• Verification that the software satisfies development requirements
• Verification that the organizations that will perform those activities

There are also many considerations to the software planning process, like the intent to use previously developed software or commercial off the shelf software (COTS), tool qualification, and many more described in section 12.

Table A-1 of the standard captures the objectives, the software levels that apply, and the expected output from these activities, which are a set of documents with reporting information about the organization, industry standard, software development, tools, verification results and certification.

Software Development Process, Section 5

The software development process is applied as defined by the software planning process and the software development plan. Whether teams or organizations choose a software development methodology like DevOps, Spiral, Waterfall, or another, the following four listed processes must be performed.

1. Software requirements process
2. Software design process
3. Software coding process
4. Integration process

The software requirements process begins by gathering all requirements from the stakeholder, regulatory bodies, standards, and more. These requirements are organized into domains such as hardware, software, mechanical, chemical, electrical, and so on, and then become your system-level requirements.

High-level requirements are derived from top-level system requirements. They decompose a system requirement into various high-level functional and nonfunctional requirements. This phase of the requirements decomposition helps in the architectural design of the system under development.

High-level requirements clarify and help define expected behavior as well as safety tolerances, security expectations, reliability, performance, portability, availability, scalability, and more. Each high-level requirement links up to the system requirement that it satisfies. In addition, high-level test cases are created and linked to each high- level requirement for the purpose of its verification and validation. This is part of the software design process, as each high-level requirement is further decomposed into low-level requirements.

Low-level requirements are software requirements derived from high-level requirements. They further decompose and refine the specifications of the software’s behavior and quality of service. They drill down to another level of abstraction and map it to individual software units. The coding process begins as code units are written to facilitate the software’s detailed design and implementation. The inputs to the coding process are the low-level requirements and software architecture from the software design process, the software development plan, and the software code standards.

After the coding process is complete, the integration process consists of the following:

Coding defects need to be identified and fixed. Inadequate or incorrect inputs detected during the integration process should be provided to the following software processes as feedback for clarification or correction:

• Requirements
• Design
• Coding
• Planning

Bidirectional traceability that is established from each low-level requirement up to its high-level requirement and down to the low-level tests or unit test cases that verify and validate it helps in this endeavor.

Level D

Traceability is crucial to DO-178C. The depth of traceability varies based on the software level. Looking at the traceability that’s required for DO-178C level D, organizations need not care about how the software has been developed, and as such, there’s no need to have any traceability down to low-level requirements, the source code, or software architecture. Teams just need to trace from the system software requirements to the high-level requirements and then to the test cases, test procedures, and test results.

Level C & B

For levels B and C, how the source code has been developed becomes important. Teams need to expand traceability by adding bidirectional links from the high-level requirements to the low-level requirements and to the source code.

Level A

For level A projects, the requirements are to expand the traceability not just down to the source code, but to the assembly/object code. This is because compilers are known to expand and translate higher level languages to assembly code that does not map back to the originating code.

Parasoft has an assembly code coverage solution called ASMTools that automates code coverage at the assembly language level. Automating this effort alleviates much labor if code coverage at the assembly level is required.

For requirements traceability, Parasoft automates linking between requirements, test cases, and down to the source file, if required. Integrations with ALM tools like Jama, Codebeamer, and Polarion exist to help achieve this bidirectional traceability and building a traceability matrix for verification requirements.

Software Verification Process, Section 6

The purpose of the software verification process is to detect, report, and remove the errors that may have been introduced during the software development process. The standard uses the term “verification” instead of “test” because testing alone cannot show the absence of errors. Verification is a combination of reviews, analysis, tests cases, and test procedures.

Tests provide internal consistency and completeness of the requirements, while test executions provide a demonstration of compliance with requirements.

DO-178C software verification process enables the following:

• The system requirements allocated to software shall be decomposed into high-level requirements that satisfy system requirements.
• High-level requirements shall be developed into software architecture and low-level requirements that satisfy high-level requirements.
• If one or more levels of software requirements are decomposed into high-level and low-level requirements, each successively lower level satisfies its higher-level requirements. If code is generated directly from high-level requirements, this does not apply.
• The software architecture and low-level requirements shall be developed into source code that satisfies low-level requirements and software architecture.
• The executable object code must satisfy software requirements and provide confidence in fulfilling its intended functionality.
• The executable object code shall be robust and respond correctly to abnormal inputs and conditions.
  The means used to perform the verification to be technically correct and complete for every determined software level.
• The means used to perform the verification to be technically correct and complete for every determined software level.

Software testing demonstrates or “validates” that the software satisfies its requirements and reveals with a high degree of confidence that errors that could lead to unacceptable failure conditions, as determined by the system safety and security assessment process, have been removed. The following diagram shows software testing activities with subsections.

To further detail each testing activity, the standard provides a set of tables with well- defined objectives and outputs or artifacts needed to demonstrate compliance. These objectives are achieved by way of software testing and may include the following:

• Performing static analysis
• Unit testing
• Integration testing
• System testing
• On-target hardware
• Data and control coupling
• Structural code coverage (statement, branch, MC/DC, assembly)

Integrating hardware and software is crucial to ensuring safety, security, and reliability.

Be aware that all of these testing methods are automated by Parasoft’s tool suite. You can get a glimpse of our C/C++ solution by taking a tour of Parasoft C/C++test.

The following tables list the set of objectives and expected outputs based on each software design assurance level in order to ensure airworthiness.

Software Configuration Management Process, Section 7

Section 7 discusses the objectives and activities of the software configuration management process. You need to be able to define and control configurations of the software throughout the software life cycle. Organizations or teams need to have source baselines, versioning, change control, change review, protection against unauthorized changes, problem reporting, and much more.

These are the software configuration management process activities:

1. Configuration identification
2. Baselines and traceability
3. Problem reporting, tracking, and corrective action
4. Change control
5. Change review
6. Configuration status accounting
7. Archive, retrieval, and release

These activities are further detailed as objectives and their output. The objectives include being able to control item characteristic changes, record and report change control processing, and implementation status.

In Table A-8, notice the “Control Category by Software Level” column. DO-178C specifies which items must be treated as Control Category 1 or 2 based on the project’s DAL. Items treated as Control Category 1 (CC1) must undergo full problem reporting processes, formal change review, and release processes. CC2 items do not need to undergo these more formal processes, but they must still comply with configuration identification and traceability needs, be protected against unauthorized changes, and satisfy applicable data retention requirements. The map between CC1 and CC2 data is found in the following table.

Software Quality Assurance Process, Section 8

The SQA process is captured in the Software Quality Assurance Plan, which is built during the software planning process. Outputs of the SQA process activities need to be recorded, evaluated, and tracked. Audits need to be performed and any deviations from the standards be resolved. The process entails providing assurance that:

• Software plans and standards are developed, reviewed, and will meet compliance.
• Artifacts, reports, and evidence are in place with approvals.
• Software product and software life cycle data conform to certification requirements.

Certification Liaison Process, Section 9

Section 9 discusses the certification liaison process and its objectives, which include the following:

• Establish communication and understanding between the applicant and the certification authority throughout the software life cycle to assist the certification process.
• Gain agreement on the means of compliance through approval of the Plan for Software Aspects of Certification.
• Provide compliance substantiation.

Your organization will need to produce the Plan for Software Aspects of Certification (PSAC), which will contain the certification liaison process. The PSAC will include plans on resolving issues identified by the certification liaison and obtaining agreement on the plan. The table below lists the set of objectives and expected output artifacts.

Best practices for obtaining certification boil down to closely working with your certification liaison, who may be better known as your Designated Engineering Representative (DER), to evaluate for compliance, act on your behalf toward approval, and recommend that the FAA approve your certification.

Overview of Certification Process, Section 10

Section 10 is for informational purposes only regarding the certification process.

It mentions the types of systems and equipment to which certification applies. It specifies that certification authorities do not certify software as a unique stand-alone product. It must be part of the airborne system or equipment.

“Certification’ applies to aircraft, engines, or propellers; and, in respect of some certification authorities, auxiliary power units. The certification authorities consider the software as part of the airborne system or equipment installed on the certified product; that is, the certification authorities do not certify the software as a unique, stand-alone product.”

Approval also depends upon a successful demonstration or review of the products produced.

Software Life Cycle Data, Section 11

Section 11 discusses artifacts like the data and documentation produced during the software life cycle. The data needs to be unambiguous, complete, verifiable, consistent, modifiable, and traceable. It also must be in various forms like electronic and printed.Parasoft’s automated report generation and analytics web dashboard provide much of the information needed within various artifacts and documents.

The artifacts to be produced during the software life cycle include the source code, object code, test cases, results, problem reports, and, of course, the plans. Here’s the full list.

• Plan for software aspects of certification
• Executable object code
• Software development plan
• Software verification cases and procedures
• Software verification plan
• Software verification results
• Software configuration management plan
• Software life cycle environment configuration index
• Software quality assurance plan
• Software requirements standards
• Software configuration index
• Software design standards
• Problem reports
• Software code standards
• Software configuration management records
• Software requirements data
• Software quality assurance records
• Design description
• Software accomplishment summary
• Source code
• Trace data
• Parameter data item file

Additional Considerations, Section 12

Section 12 provides additional guidance and consideration on topics that can have an impact on objectives and activities in the software life cycle. For example, the use of or modifications to previously developed software. Section 12 provides additional clarification and activities to perform that help ensure safety and recertification. Here are just some other considerations include:

Based on the consideration, section 12 provides additional objectives in software configuration management, software quality assurance, development tool qualification, and more.

Section 12 covers the importance of “Tool Qualification” and determining if its needed. This is because if a tool is used that eliminates, reduces, or automates processes, teams need to take into consideration whether the tool might introduce errors into the life cycle.

The following criteria should be used to determine the impact of the tool:

There are five levels of tool qualification, TQL-1 through TQL-5, that are determined by the tool use and its potential impact on the software life cycle. TQL-1 is the most rigorous level. The tool qualification level needs to be coordinated with the certification authority.

The objectives, activities, guidance, and life cycle data required for each tool qualification level are described in DO-330, “Software Tool Qualification Considerations.”

Parasoft supports DO-178C and DO-330 conformant tool qualification processes with an automated tool qualification kit. The Tool Qualification Kit automates the process of creating the supporting documentation required in using C/ C++test for static analysis, unit testing, and coverage requirements.

Parasoft’s Tool Qualification Kit reduces the time taken to perform the tool qualification and the potential for human error by leveraging automation to guide users through the following workflow:

1. Specify the use cases and capabilities to be used on the project.
2. Quickly map known issues in the tool you’re qualifying to the features of the tool you’re using in development.
3. Plan and capture the results of manual testing efforts.
4. Execute automated tests.
5. Bring all the data together and generate the critical documents.