DO-178B and DO-178C

From T-VEC Wiki
Revision as of 12:24, 13 January 2007 by 69.165.165.243 (Talk)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

There are many questions related to DO-178B support from T-VEC as well as the implications from the proposed DO-178C. This page provides some information related to these topics.

Here's an example of a question that may be asked by some users have developed a RTOS that used in airborne system, and they want their RTOS to be certified under DO-178B.

DO-178B is much more than just a certification, it is a process that starts the same day as the development project itself. It is nearly impossible to take an existing application that was not developed in cooperation with the FAA or European equivalent and get it certified for any DO-178B levels, and definitely impossible for Level A applications. At the very beginning of a DO-178B development project, a document called Plans for Software Aspects of Certification is supposed to be created and supplied to the certification authority for approval. This plan describes the process and tools and procedures that the developer will utilitize during the development and verification of the avionics software application. This plan also describes the application and its use in terms of safety impact on the aircraft. The developer and the certification authority will decide what level of safety criticality the application should be developed to and certified to. This determined the objectives and deliverables that must be met and produced during the development and verification phases of the project.

To take an existing application like a customer's RTOS and get it certified under DO-178B, and entire development effort would be necessary - not to produce the actual code itself - but to go back and develop all of the additional material necessary to support the certification. For example, DO-178B Level A requires that verification testing include sufficient tests for 100% MCDC level object code coverage, and all of the tests are required to be traceable back to specific software requirements that the code was designed to satisfy. There are a lot of objects to be met and deliverables required to be produced and sent or made available to the certification authority.