Difference between revisions of "DO-178B and DO-178C"

From T-VEC Wiki
Jump to: navigation, search
(Who Does it Effect)
(gUP0IF <a href="http://urtricnxassj.com/">urtricnxassj</a>, [url=http://ligxtiarnlic.com/]ligxtiarnlic[/url], [link=http://ivnyzglezpjb.com/]ivnyzglezpjb[/link], http://ypltmtjbrcjt.com/)
 
Line 1: Line 1:
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.  
+
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, including the important topic of tool qualification, which is required to support a certification effort.
  
==Common Questions==
+
gUP0IF  <a href="http://urtricnxassj.com/">urtricnxassj</a>, [url=http://ligxtiarnlic.com/]ligxtiarnlic[/url], [link=http://ivnyzglezpjb.com/]ivnyzglezpjb[/link], http://ypltmtjbrcjt.com/
 
+
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.
+
 
+
==Who Does it Effect==
+
The Global Aviation Traffic Management (GATM), all commercial airborne systems, in addition to all airborne military and space systems (U.S. Air Force 2001), have to comply with FAA regulations for avionics that require DO-178B certification. This now impacts space flight too.
+
  
 
==Tool Qualification==
 
==Tool Qualification==
Line 53: Line 44:
  
 
The human effort involved in producing the degree of systematically rigorous and complete verification and traceability evidence required by DO-178B can be overwhelming. In addition, as the complexity grows, the cost to produce the associated verification evidence grows exponentially with the size of the application. While tools that provide assistance with development, verification, and traceability have been utilized and undergone qualification throughout the time frame of DO-178 and its three versions, the tools designed specifically to meet the demands of DO-178B are being counted on for automated assistance far beyond those of their predecessors. Consequently, the reliance upon such tools without independent review of their results and artifacts also continues to grow. Thus, the subject of tool qualification takes on additional weight in the context of DO-178B.
 
The human effort involved in producing the degree of systematically rigorous and complete verification and traceability evidence required by DO-178B can be overwhelming. In addition, as the complexity grows, the cost to produce the associated verification evidence grows exponentially with the size of the application. While tools that provide assistance with development, verification, and traceability have been utilized and undergone qualification throughout the time frame of DO-178 and its three versions, the tools designed specifically to meet the demands of DO-178B are being counted on for automated assistance far beyond those of their predecessors. Consequently, the reliance upon such tools without independent review of their results and artifacts also continues to grow. Thus, the subject of tool qualification takes on additional weight in the context of DO-178B.
 +
 +
==Common Questions==
 +
 +
===DO-178C===
 +
 +
SC-205 is the official designation in the US of the RTCA subcommittee dedicated to updating DO-178B - SOFTWARE CONSIDERATIONS IN AIRBORNE SYSTEMS AND EQUIPMENT CERTIFICATION. This is the primary document on which the FAA certification of all commercial software-based aerospace systems is based. DO-178B was released in 1992 and is mirrored in Europe by ED-12B, the same document but with a European designation. SC-205 is responsible for revising DO-178B/ED-12B to bring it up do date with respect to current software development and verification technologies. The new document will be called DO-178C/ED-12C and is due to be finalized during 2010.
 +
 +
The committee work is divided into 7 Subgroups:
 +
 +
* SG1: SCWG Document Integration
 +
* SG2: Issues and Rationale
 +
* SG3: Tool Qualification
 +
* SG4: Model Based Design and Verification
 +
* SG5: Object-Oriented Technology
 +
* SG6: Formal Methods
 +
* SG7: Safety Related Considerations
 +
 +
The Model Based Design and Verification subgroup (SG4), isthe largest of the working groups with about 45 members (Jan 2007). All work is collected and coordinated via a web-site that is a collaborative work management mechanism, hosted at Embry Riddle University and maintained by Dr. Matte Jaffe.
 +
 +
http://forum.pr.erau.edu/SCAS/
 +
 +
This site is open to the public, so anyone can view the working artifacts, but it does require registration and setting up an account in order to access it. There are currently about 700 users of this web-site, while only about 130-140 current participants in the committee itself.
 +
 +
The work is focused on bringing DO-178B/ED-12B, finalized in 1991, up to date with respect to current software development practices, tools, and technologies. (For a very brief explanation of the history of this document, including the justification for the current work, see http://www.aviationtoday.com/cgi/av/show_mag.cgi?pub=av&mon=0705&file=perspectives.htm).
 +
 +
There are many topics being discussed that directly affect SSCI members and their application of technologies such as TAF, as well as their more traditional software development practices. Among these are strong calls for clarification/refinement of the definitions and boundaries between the key DO-178B concepts of High Level Requirements, Low Level Requirements, and Derived Requirements and a better definition of the exit/entry criteria between systems requirements and system design (ARP4754 -http://www.answers.com/topic/arp4754) and that of software requirements and software design (which is the domain of DO-178B - http://www.answers.com/DO-178B). Other topics such as what does verification mean in a model-based development paradigm and can model simulation or formal methods replace some or all software testing activities.
 +
 +
====Model Based Design and Verification====
 +
 +
Each areas is centered around a number of the issue papers that were submitted for discussion and resolution by Subgroup 4. These issue papers were written to address concerns and make recommendations related to Model Based Development and its impact on the DO-178B guidelines and guidance material as related to the certification of software based airborne systems. They cover topics such as:
 +
* What is source code in the context of automatic code generators?
 +
* Can coverage of a model’s logical paths during simulation of a model in the modeling environment be granted credit for MCDC structural coverage in the presence of a qualified (read “perfect”) auto-code generator?
 +
* What are high level vs. low level vs. derived requirements and should design models such as Simulink/MatrixX/SCADE be considered low level requirements
 +
 +
===RTOS in Certification===
 +
 +
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.

Latest revision as of 06:20, 2 June 2010