| Introduction to DO-178B |
 |
 |
 |
|
By Eduardo Trejos, Quality Engineer and Jose Lopez, Software Engineer, Avionyx. SummaryThis paper provides a brief introduction to DO-178B. It discusses software airworthiness and how DO-178B was created as a tool to comply with certification requirements, including an overview of the software criticality levels and the number of objectives to be satisfied for each of them. Finally, it provides an overview of the development and integral processes along with their objectives and respective software life-cycle data. HistoryAvoiding aircraft accidents and providing air safety has always been a priority in aviation systems development. 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 and the creation of DO-178, later followed by DO-178A. With the evolution of glass cockpits, highly integrated systems that require real-time operating systems and millions of lines of code, DO-178B provides the guidance necessary to assure software runs reliably under all normal and abnormal conditions. What are the software guidelines for avionics?RTCA in cooperation with the European Organisation for Civil Aviation Equipment (EUROCAE) established special committees and working groups to develop and document the software practices that would support the development of software-based airborne systems. These practices were gathered in a document that evolved into DO-178B: Software Considerations in Airborne Systems and Equipment Certification (1992). The U.S. Department of Transportation’s Federal Aviation Administration (FAA), recognizes DO-178B as a means of evaluating software for the purposes of complying with the regulations in their Advisory Circular AC 20-115B. In Europe, the Joint Aviation Authority (JAA) recognizes ED-12B via Temporary Guidance Leaflet Number 4 (TGL No. 4). DO-178B‘s software quality assurance guidelines are approved by the FAA and the European Aviation Safety Agency (EASA) and other aviation authorities worldwide that approve the certification of all commercial aircraft produced. The Certification Authorities Software Team (CAST) Position Paper CAST-5 (Guidelines for Proposing Alternate Means of Compliance to DO-178B) establishes that if an applicant proposes a non-traditional approach to one or more of the DO-178B objectives, they still must show how that approach meets the “intent” of the DO-178B objectives. Many of the DO-178B objectives relate to completeness and rigor of development and verification processes in specific terms, whereas the generalized process models such as the Software Engineering Institute (SEI) Capability Maturity Model (CMM) and Software Process Improvement Capability Evaluation (SPICE) are focused on business process measurement and improvement. Those models stipulate and assess against many process attributes that are necessary but not sufficient conditions for high product integrity and safety. For example, the SEI CMM has no process activities, capabilities or metrics associated with verification (including review, analysis or test coverage). This is very important in DO-178B guidance because verification is a key factor in system safety. DO-178B at a glanceThe purpose of DO-178B is “to provide guidelines 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.” Not all avionics systems have the same criticality. Some systems may not require following a very rigorous development process since their malfunction may not affect safety at all. To reflect this, DO-178B defines different failure condition categories. The failure condition category of a system is established by determining the severity of failure conditions on the aircraft and its occupants. The software level is based upon the contribution of software to potential failure conditions as determined by the system safety assessment process. Table 1 shows the software level per failure condition and the amount of DO-178B objectives associated to each. It also shows the number of objectives that have to be satisfied with independence. Independence refers to a separation of responsibilities where the people who verify an objective must not be the developers of the item in question.
Table 1. DO-178B SW levels and characteristics DO-178B establishes processes that are intended to support the objectives, according to the software level. In general, there’s Integral and Development processes as shown in Figure 1.  Figure 1. DO-178B Software Life Cycle Process The processes of a software life cycle may be iterative as represented by the dotted lines in the Software Development Processes in Figure 1. The objective for each process and its respective Software Life Cycle Data are further explained in Table 2.
Table 2. SW Life Cycle Processes Objectives and Data |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
