do178-b regulatory requirements and approvals

Embedded software and hardware developed for the avionics (aeronautical and aerospace) industries is among the most strictly regulated and tested of all industries.

The project management, risk mitigation, design and testing activities are based on the Federal Aviation Administration standard "RTCA DO178B".

The following will provide a summary of DO178B.

We have extensive experience in working with DO178B in the aerospace industry (embedded software/hardware in the airline industry).

Email us at mailto:do178b@cdaservices.com if you need assistance with your DO178B design project.

RTCA, Inc. is a private, not-for-profit corporation that develops consensus-based recommendations regarding communications, navigation, surveillance, and air traffic management system issues.

Organized in 1935 as the Radio Technical Commission for Aeronautics, RTCA today includes over 270 government, industry, and academic organizations from the United States and around the world.

EUROCAE

The European Organisation for Civil Aviation Equipment was formed at LUCERNE on the 24th April, 1963. At that time, there was no regular forum in Europe where administrations, airlines and industry could meet to discuss technical problems. EUROCAE was created to fill this gap.

EUROCAE started the preparation of minimum performance specifications for airborne electronic equipment.  This work was noted and supported from 1967 by the European Civil Aviation Conference (ECAC). ECAC later proposed to European National Airworthiness Authorities to take EUROCAE specifications as the basis of their national regulations.

Both organizations included a very broad cross-section of aerospace industry leaders and regulators such as the FAA and JAA, whose primary function is human safety. Their objective was to put together a set of standards that define the design, production, test and certification processes that lead to the highest level of safety possible for aircraft systems.

ED-12B is the "Software Considerations in Airborne Systems and Equipment Certification" document and is equivalent to DO178-B.  It was first published in 1993.

DO178B Details

At product and project conception the developer must register its intent to certify the product with the required regulators using the PSAC form.  This document, the Plan for Software Aspects of Certification, provides details on:
 

The Regulatory body assesses the PSAC and has the power to force the developer to make changes to it if it does not believe that the product (or process defined to produce that product) outlined in the PSAC meets the requirements of DO178B. At this point the developer is faced with the thought of having to implement the PSAC changes mandated by the Regulator which could potentially have a significant impact of his/her design or production costs. It is for this reason that the PSAC should be submitted at the earliest possible point in the product development lifecycle in order to minimize the cost and impact of change.

This is quite a task at the outset of development since some of the information required in the PSAC is not typically available until part way through the development process. It forces companies to spend more time planning developments properly and defining a good set of requirements upon which the development is based.

During the Product development phase the processes used by the company in the course of the development are monitored, as is the methodology employed in the design. This involves demonstrating that the development is requirements-driven and showing that a series of reviews by "independent" groups or individuals throughout the development have taken place, have been documented and the findings acted upon. This information, along with all "source data" form part of the Software Accomplishments Summary (SAS), which has to be submitted to the Regulatory body prior to achieving certification.

The SAS also contains all of the tests and test results that have been run by the developer to "Prove" that the development has been successful and that all design requirements have been met.

The Certification phase is the final phase during which the Regulatory body decides whether what has been achieved meets the requirements of DO178B. Even at this late stage (what would normally be deployment), the Regulators still have the power to enforce changes causing costly redevelopment, recertification and delaying the production of the product.

It should be noted that DO178B is very specific about several issues that will affect product development, some of which are:

1. Certification applies to the end product ie: an airframe in the aerospace industry (this would equate to a complete car in the automotive industry),
2. It encompasses all of the systems, subsystems, hardware, software, firmware and tools used in the development, production and testing of that product,
3. It applies to a given application of a given product (other applications of the same product require further certification),
4. It requires certain software coding practices that do not allow for, among other things, "dead code" and require all code produced to be traceable back to design requirements (all code MUST be there as a direct result of a requirement),
5. It requires full testing of the system and all component parts (including the software and firmware) on the target platform and in the target environment in which it is to be deployed,
6. It requires (at the highest level) code testing at Modified Condition and Decision level (MCDC testing)

The net result of the above is a considerable cost increase over non-certifiable project and products.  A range of 5 to 8 times the cost of the same development without DO178B.

Most of the cost differential is produced by the additional costs of project management, project and product documentation, fully documented and tested software and the large costs of verification and validation testing necessary for compliance.

DO178B is quite specific in saying that, if a company wishes to use tools to reduce or eliminate aspects of the certification process, the tools used must be "Qualified" for use on that program.

A tool, whether it be a development tool (one whose output forms part of the deliverable product such as a code generator) or a verification tool, (one whose use is limited to the development, testing and/or certification phases) can only be Qualified once its use on a given development has been approved by the Regulatory body on that development. Until this point, the tool can only be deemed to be "Qualifiable".

In order to make a development tool Qualifiable, the tool provider has to go through exactly the same process as the product developer (he/she has to effectively "Certify" the tool). The process for qualifying a verification tool is slightly less onerous, since the tool will not produce anything that ends up in the final product.

This means that in order to use tools to minimize the impact of Safety Critical System design standards in terms of additional cost and time scale, tools must first be available that have been through this stringent Qualification process.

The following sections list activities and associated deliverable that are expected as part of the overall process.

planning

standards

development

software requirement verification

software design verification

software code verification

verification of integration process

Ensure testing methodology of Software Verification Plan was used

verification of verification process