What is RTCA/ DO-178B?
A Software Considerations in Airborne Systems and Equipment Certification. RTCA is the acronym for Radio Technical Commission for Aeronautics and is located at 1828 L Street, NW, Suite 805, Washington, D.C. 20036. RTCA/DO-178B was developed by the commercial avionics industry to establish software guidelines for avionics software developers.
The first version, DO-178 covered the basic avionics software lifecycle.
The second version, DO-178A, added avionics software criticality level details and emphasized software component testing to obtain quality.
The current version, DO-178B, evolved avionics software quality via added planning, continuous quality monitoring, and testing in real-world conditions. Technically, DO-178B is merely a guideline. In reality, it is a strict requirement. At merely 100 pages, DO-178B is all things to all people, which means it is quite broad in nature and requires in-depth understanding of intent, voluminous ancillary documentation, and case studies to be properly used.
The latest version, DO-178C will be the latest revision to DO-178B; DO178C was initiated in March 2005 with formal publication planned for 2008. HighRely’s DERs have provided input to DO178C and also participate in the ongoing committee meetings. D0-178C will have the following key attributes which differ, or clarify DO-178B: improved clarification on avionics object oriented technology, formal avionics software modeling, avionics systems versus software boundaries, more consistency across the avionics software lifecycle, and consolidate various RTCA avionics documents. Otherwise, D0178C will maintain most of the principles of its predecessor. HighRely’s DO-178C training provides all the information necessary to succeed with your DO178C software project.
What is a DO-178B Criticality Level?
There are five D0/178B criticality levels, with DO-178B Level A being most critical and DO-178B Level E being least critical. The DO-178B criticality level is based upon the contribution of the associated software to potential failure conditions. DO-178B failure conditions are determined by the FAA system safety assessment process. Each avionics system has one defined criticality level (and must be approved by the FAA); however, different components within that system can have differing criticality levels subject to certain guidelines. The higher the DO-178B criticality level, the greater the amount of software development effort required. Our DO-178B Training provides additional details on DO-178B criticality levels and how to determine, apply and optimize. Additional information on each DO-178B critical level are provided below:
What is DO-178B Level A?
DO-178B Level A software is software whose anomalous behavior, as shown by the system safety assessment process, would cause or contribute to a failure of system function resulting in a catastrophic failure condition for the aircraft. Failure of DO-178B Level A software could be typified by total loss of life. Approximately 20-30% of avionics systems and 40% of avionics software code must meet DO-178B Level A criteria.
What is DO-178B Level B?
DO-178B Level B software is software whose anomalous behavior, as shown by the system safety assessment process, would cause or contribute to a failure of system function resulting in a hazardous/severe-major failure condition for the aircraft. Failure of DO-178B Level B software could be typified by some loss of life. Approximately 20% of avionics systems and 30% of avionics software code must meet DO-178B Level B criteria.
What is DO-178B Level C?
DO-178B Level C software is software whose anomalous behavior, as shown by the system safety assessment process, would cause or contribute to a failure of system function resulting in a major failure condition for the aircraft. Failure of DO-178B Level C software could be typified by serious injuries. Approximately 25% of avionics systems and 20% of avionics software code must meet DO-178B Level C criteria.
What is DO-178B Level D?
DO-178B Level D software is software whose anomalous behavior, as shown by the system safety assessment process, would cause or contribute to a failure of system function resulting in a minor failure condition for the aircraft. Failure of DO-178B Level D software could be typified by minor injuries. Approximately 20% of avionics systems and 10% of avionics software code must meet DO-178B Level D criteria.
What is DO-178B Level E?
DO-178B Level E software is software whose anomalous behavior, as shown by the system safety assessment process, would cause or contribute to a failure of system function with no effect on aircraft operational capability or pilot workload. Failure of DO-178B Level E software would have no impact on passenger or aircraft safety. Approximately 10% of avionics systems and 5% of avionics software code must meet DO-178B Level E criteria (note however that the amount of DO-178B Level E sourcecode is increasing due to passenger entertainment and internet communications subsystems that are currently designated Level E; it is deemed likely by us that the criticality levels of these systems will increase due to integration with other, more critical, avionics systems).
What is a DER?
A DER (Designated Engineering Representative) is an appointed engineering resource who has the authority to pass judgment on aviation-related design/development. An avionics software Designated Engineering Representative may be appointed to act as a Company DER and/or a Consultant DER. A Company DER can act as a Designated Engineering Representative for his/her employer and may only approve or recommend approval of technical data to the FAA for that company. A Consultant DER is an individual appointed to act as an independent consultant DER to approve or recommend approval of technical data to the FAA.
What is MC/DC?
The official definition of MCDC, Modified Condition/Decision Coverage is Every point of entry and exit in the program has been invoked at least once, every condition in a decision in the program has taken on all possible outcomes at least once, and each condition has been shown to affect that decision outcome independently. A condition is shown to affect a decisions outcome independently by varying just that decision while holding fixed all other possible conditions. The key to successful, and accurate, MCDC testing is to analyze each sourcecode construct for potential MCDC applicability and then develop sufficient test cases to ensure that each condition in that construct is independently verified per the aforementioned MC/DC definition. Today, most MC/DC testing is done with the assistance of DO-178B qualified structural coverage tools, particularly MCDC tools.
What is avionics dead code?
DO-178B dead code is executable (binary) software that will never be executed during runtime operations. D0178B generally does not allow for the presence of dead code: it must be removed. Dead code does not trace to any software requirements, hence does not perform any required functionality. Note that unreferenced variables or functions which are not called (hence are unreferenced) elsewhere in the program are usually removed via the compiler or linker; since they are not present in the binary executable load image, they are not dead code per DO-178B. Our DO178 training provides additional details for handling dead code.
What is avionics deactivated code?
DO-178B deactivated code is executable (binary) software that will not be executed during runtime operations of a particular software version within a particular avionics box; however, the code may be executed during maintenance or special operations, or be executed within a different or future version of the software within a different configuration or avionics box. Unlike dead code (see above), deactivated code may be left in the source baseline. Special DO-178B deactivated code aspects must be followed; these are fully described in our DO-178B classes.
What is DO-178B Requirements Traceability?
D0178B requirements traceability pertains to the correlation of individual requirements to the design, code, and test elements affiliated with implementing and verifying each requirement. Requirements traceability can be many-to-one, and one-to-many. Requirements traceability needs to be from top-to-bottom (requirements to design to code, and requirements to test); this proves that all requirements have corresponding design elements, sourcecode, and tests. Requirements traceability also needs to be bottom-to-up (tests to requirements, code to design, and design to requirements); this proves that all code, design, and test elements are necessary and have requirements which they implement or verify. Our company uses RelyTRACE (from HighRely) for requirements traceability with templates to fully handle your productivity and tracking needs.