RTCA DO 178C – The Myth! As early as 1980 there were first considerations in aerospace how to develop software safely and as accurately as possible. These considerations have led to the development of a standard that is widely respected far beyond software. Currently in the version RTCA DO 178C. The standard is used in all flying systems. With EASA (Europe) and FAA (USA) there are also authorities where you have to prove compliance with the standard before you can even install the software. The following article answers the following 2 questions:

• What are the main contents of the RTCA DO 178C?
• What needs to be done in concrete terms in the planning process?

Contents of the RTCA DO 178C?

The standard defines the software planning -,  development-, verification-, quality assurance- and configuration management process.

Depending on the safety level in which the software has been classified (DAL A: catastrophic to DAL E: no effects), various development methods are allowed or mandated and different documentation and review duties arise.

Special attention is paid to the planning process. The following quote from the standard clarifies this:”Effective planning is a determining factor in producing software that satisfies the guidance of this document.”

The content and the result of this process will therefore be examined in more detail below.

What needs to be done in concrete terms in the planning process?

In short, the planning process defines the central idea through the project to the final approval of the product. Precisely because software projects are very dynamic and things change constantly, it is essential to know where you want to go and how you want to get there. This is the only way to carry out projects in such a way that safe products can be created in the end. This insight has led to the fact that the planning process has been assigned a very important role in the RTCA DO 178C.

PSAC: Plan of Software Aspect for Certification

The Plan for Software Aspects of Certification (PSAC) is an absolutely central component of every RTCA DO 178C project. It provides an overview of the entire project. With his help it must be possible to navigate through the entire project and it describes the essential, certification-relevant strategies.

SDP: Software Development Plan

In addition to the PSAC, there is the Software Development Plan (SDP), at least in the larger projects. It describes the software lifecycle and defines its results. It describes the organizational structure, development methods and development tools used.

SVP: Software Verification Plan

From the point of view of the RTCA DO 178C, the Software Verification Plan (SVP) is more important than the SDP. The importance of this plan can also be seen in the following quote on the RTCA DO 178C: “Develop the software as you like it – prove to me that what you have done is right and correct!”.

The main points of the SVP are as follows:

• Verification strategy (system, integration, software, unit level)
• Organizational responsibilities
• Methods for achieving the necessary independence
• Verification methods (review, test, etc.)
• Verification environment (test environment)
• Transition criteria to start the software verification process
• Assumptions/reasons for the correctness of the used compiler
• Re-verification strategy and procedures

SCMP: Software Configuration Management Plan

Configuration management is a very important building block for the efficient and successful implementation of the software development and verification described in the SDP and SVP. As many lifecycle data are generated in the course of a RTCA DO 178C project, a configuration management strategy is necessary. That configuration management does not mean version control that you can see in the contents of the Configuration Management Plan (SCMP):

• Description of the configuration environment (tools, etc.)
• Description of the configuration process activities (baselining, traceability, problem reporting, change control, etc.)
• Transition criteria to start the configuration management process
• Definition of software life cycle data resulting from the configuration management process
• Subcontractor management regarding configuration management

SQAP: Software Quality Assurance Plan

The last plan needed is the Software Quality Assurance Plan. It has the following content:

• Definition of the transition criteria to start with quality assurance
• Definition of strategy, responsibilities, activities (reviews, audits, reports, etc.) as well as tools in quality assurance.

Quality assurance in an aerospace project primarily means checking the content and ensuring that the defined processes in development and verification are adhered to. At the same time, quality assurance also forms the bridge to approval. Audits by regulatory authorities require that an active quality assurance system has been used internally. When regulatory authorities discover major problems, quality assurance also comes under great pressure to justify itself.

Conclusion

The RTCA DO 178C probably comes very close to the ideal of a safe software development. If you use the processes defined there consistently and efficiently, it is highly likely that you will develop a software which contains a minimum of errors. However, as the described planning process already suggests, the development effort for a development according to RTCA DO 178C is already considerable. Such projects need an pro-active management and proper strategies from the beginning.

Related HEICON Blog posts

• The Supplements of DO 178C – Where do they come from and what is their content?
• RTCA DO 331 Model-Based Development and Verification in aerospace

The HEICON team will be pleased to support you with our services if you have individual questions regarding your project. Please send a mail to: info[at]heicon-ulm.de.