DO-178C (henceforth DO-178C) is the primary document referenced by certification authorities including the FAA, EASA and Transport Canada to approve all commercial software-based civil aviation systems. The document is jointly published by RTCA (formerly the Radio Technical Committee for Aeronautics) and EUROCAE.
The rapid increase in the use of software in airborne systems and equipment used on aircraft and engines in the early 1980s resulted in a need for industry-accepted guidance for satisfying airworthiness requirements. DO-178, “Software Considerations in Airborne Systems and Equipment Certification”, was written to satisfy this need. DO-178C is a formal process standard that covers the complete software lifecycle — planning, development, and integral processes — to ensure correctness and robustness in software systems for civil airborne applications.
The integral processes include software verification, software quality assurance, configuration management assurance and certification liaison with the regulatory authorities. Increasingly, standards developed for the commercial aviation including DO-178C have also become recognised as best practice in the defence sector.
The purpose of DO-178C document is to provide guidance for the production of software for airborne systems and equipment that performs its intended function with a level of confidence in safety that complies with airworthiness requirements.
Software Life Cycle process of DO-178C
The software Life Cycle processes are applied as defined by the software planning process and the Software Development Plan. The software Life Cycle processes are
• Software requirements process.
• Software design process.
• Software coding process.
• Integration process
• Software verification process
• Software Testing Process
• Software Configuration Management Process
• Software Quality Assurance Process
• Certification Liaison Process
Software requirement process
Software development processes produce one or more levels of software requirements. High-level requirements are produced directly through analysis of system requirements and system architecture. Usually, these high-level requirements are further developed during the software design process, thus producing one or more successive, lower levels of requirements. However, if Source Code is generated directly from high-level requirements, then the high-level requirements are also considered low-level requirements and the guidance for low-level requirements also apply. High-level requirements and low-level requirements may include derived requirements. In order to determine the effects of derived requirements on the system safety assessment and system requirements, all derived requirements should be made available to the system processes including the system safety assessment process.
Software design process
The software design process inputs are the Software Requirements Data, the Software Development Plan, and the Software Design Standards. When the planned transition criteria have been satisfied, the high-level requirements are used in the design process to develop software architecture and low-level requirements. This may involve one or more lower levels of requirements. The primary output of the process is the Design Description which includes the software architecture and the low-level requirements. The software design process is complete when its objectives and the objectives of the integral processes associated with it are satisfied.
Software Coding Process
The coding process inputs are the low-level requirements and software architecture from the software design process, the Software Development Plan, and the Software Code Standards. The software coding process may be entered or re-entered when the planned transition criteria are satisfied. This process based upon the software architecture and the low-level requirements produces the Source Code. The software coding process is complete when its objectives and the objectives of the integral processes associated with it are satisfied.
Software integration process
The integration process consists of software integration and hardware/software integration. The integration process may be entered or re-entered when the planned transition criteria have been satisfied. The integration process inputs are the software architecture from the software design process, and the Source Code from the software coding process. The outputs of the integration process are the object code, Executable Object Code, Parameter Data Item File and the compiling, linking, and loading data. The integration process is complete when its objectives and the objectives of the integral processes associated with it are satisfied.
Software verification process
Verification is a technical assessment of the outputs of the software planning process, software development processes, and the software verification process. The software verification process is applied as defined by the software planning process and the Software Verification Plan .Verification is not simply testing. Testing, in general, cannot show the absence of errors. As a result, the following sections use the term “verify” instead of “test” to discuss the software verification process activities, which are typically a combination of reviews, analyses, and tests.
Software testing
Software testing is used to demonstrate that the software satisfies its requirements and to demonstrate with a high degree of confidence that errors that could lead to unacceptable failure conditions, as determined by the system safety assessment process, have been removed. There are 3 types testing.
• Hardware/software integration testing: To verify correct operation of the software in the target computer environment.
• Software integration testing: To verify the interrelationships between software requirements and components and to verify the implementation of the software requirements and software components within the software architecture.
• Low-level testing: To verify the implementation of low-level requirements.
Software Configuration Management Process
The SCM process is applied as defined by the software planning process and the Software Configuration Management Plan. Outputs of the SCM process are recorded in Software Configuration Management Records or in other software life cycle data. The SCM process includes the activities of configuration identification, change control, baseline establishment, and archiving of the software product, including the related software life cycle data. The SCM process does not stop when the software product is approved by the certification authority, but continues throughout the service life of the system or equipment. If software life cycle activities will be performed by a supplier, then configuration management activities should be applied to the supplier.
Software Quality Assurance Process
The SQA process is applied as defined by the software planning process and the Software Quality Assurance Plan. Outputs of the SQA process activities are recorded in Software Quality Assurance Records or other software life cycle data. The SQA process assesses the software life cycle processes and their outputs to obtain assurance that objectives are satisfied, deficiencies are detected, evaluated, tracked, and resolved, and software product and software life cycle data conform to certification requirements
Certification Liaison Process
The objectives of the certification liaison process is to 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. The certification liaison process is applied as defined by the software planning process and the Plan for Software Aspects of Certification.
Software Certification Process
The certification authority assesses the Plan for Software Aspects of Certification for completeness and consistency with the means of compliance that was agreed upon to satisfy the certification basis. The certification authority satisfies itself that the software level(s) proposed by the applicant is consistent with the outputs of the system safety assessment process and other system life cycle data. The certification authority informs the applicant of issues with the proposed software plans that need to be satisfied prior to the certification authority agreement.
Reference:
DO-178C Document By RTCA