Example: air traffic controller

27 - davi.ws

2001 by CRC Press LLC 27 RTCADO-178B/EUROCAE ED-12B Int roduction Comparison with Other Software Standards Document Overview Software as Part of the System Software Life-Cycle Processes Software Planning Process Software Development Process Integral Process Software Verification Software Configuration Management Software Quality Assurance Certification Liaison Process Additional Considerations Previously Developed Software Tool Qualification Additional Guidance Synopsis References Further Information Introduction This chapter provides a summary of the document RTCA DO-178B, Software Considerations in AirborneSystems and Equipment Certification , 1 with commentary on the most common mistakes made in under-standing and applying DO-178B.

© 2001 by CRC Press LLC including a brief history of the document, the index, a list of contributors, and a process improvement form, respectively.

Information

Domain:

Source:

Link to this page:

Please notify us if you found a problem with this document:

Other abuse

Transcription of 27 - davi.ws

1 2001 by CRC Press LLC 27 RTCADO-178B/EUROCAE ED-12B Int roduction Comparison with Other Software Standards Document Overview Software as Part of the System Software Life-Cycle Processes Software Planning Process Software Development Process Integral Process Software Verification Software Configuration Management Software Quality Assurance Certification Liaison Process Additional Considerations Previously Developed Software Tool Qualification Additional Guidance Synopsis References Further Information Introduction This chapter provides a summary of the document RTCA DO-178B, Software Considerations in AirborneSystems and Equipment Certification , 1 with commentary on the most common mistakes made in under-standing and applying DO-178B.

2 The joint committee of RTCA Special Committee 167 and EUROCAE*Working Group 12 prepared RTCA DO-178B** (also known as EUROCAE ED-12B), and it was subse-quently published by RTCA and by EUROCAE in December 1992. DO-178B provides guidance for theproduction of software for airborne systems and equipment such that there is a level of confidence inthe correct functioning of that software in compliance with airworthiness requirements. DO-178B rep-resents industry consensus opinion on the best way to ensure safe software. It should also be noted thatalthough DO-178B does not discuss specific development methodologies or management activities, thereis clear evidence that by following rigorous processes, cost and schedule benefits may be realized.

3 Theverification activities specified in DO-178B are particularly effective in identifying software problemsearly in the development process. *European Organization for Civil Aviation Equipment.**DO-178B and ED-12B are copyrighted documents of RTCA and EUROCAE, respectively. In this chapter, DO-178B shall be used to refer to both the English version and the European equivalent. This convention was adoptedsolely as a means for brevity. Thomas K. Ferrell Ferrell and Associates Consulting Uma D. Ferrell Ferrell and Associates Consulting 2001 by CRC Press LLC Comparison with Other Software Standards DO-178B is a mature document, having evolved over the last 20 years through two previous revisions,DO-178 and DO-178A.

4 It is a consensus document that represents the collective wisdom of both theindustry practitioners and the certification authorities. DO-178B is self-contained, meaning that noother software standards are referenced except for those that the applicant produces to meet DO-178 Bobjectives. Comparisons have been made between DO-178B and other software standards such as MIL-STD-498, MIL-STD-2167A, IEEE/EIA-12207, IEC 61508, and Defense Standard 0-55. All of thesestandards deal with certain aspects of software development covered by DO-178B. None of them hasbeen found to provide complete coverage of DO-178B objectives.

5 In addition, these other standards lackobjective criteria and links to safety analyses at the system level. However, organizations with experienceapplying these other standards often have an easier path to adopting DO-178B. Advisory Circular AC 20-115B specifies DO-178B as an acceptable means, but not the only means,for receiving regulatory approval for software in systems or equipment being certified under a TechnicalStandard Order (TSO) Authorization, Type Certificate (TC), or Supplemental Type Certificate (STC).Most applicants use DO-178B to avoid the work involved in showing that other means are equivalent toDO-178B. Even though DO-178B was written as a guideline, it has become the standard practice withinthe industry.

6 DO-178B is officially recognized as a de facto international standard by the InternationalOrganization for Standardization (ISO). Document Overview DO-178B consists of 12 sections, 2 annexes, and 3 appendices as shown in Figure 2 and Section 10 are designed to illustrate how the processes and products discussed in DO-178 Brelate to, take direction from, and provide feedback to the overall certification process. Integral Processesdetailed in Sections 6, 7, 8, and 9, support the software life cycle processes noted in Sections 3, 4, and 5. Section 11 provides details on the life cycle data and Section 12 gives guidance to any additionalconsiderations.

7 Annex A, discussed in more detail below, provides a leveling of objectives. Annex Bprovides the document s glossary. The glossary deserves careful consideration since much effort and carewas given to precise definition of the terms. Appendices A, B, C, and D provide additional material FIGURE Document Aspects Relating ToSoftware Development - Section 2 Overview of Aircraft and EngineCertification - Section 10SW Life Cycle - Section 3SW Planning - Section 4SW Development - Section 5SW Life Cycle Data - Section 11 Additional Considerations - Section 12SW Verification - Section 6SW Configuration Mgmt. - Section 7SW Quality Assurance - Section 8 Certification Liaison - Section 9 Integral ProcessesSW Life Cycle ProcessesAppendices A, B, C, & DAnnex A & B 2001 by CRC Press LLC including a brief history of the document, the index, a list of contributors, and a process improvementform, respectively.

8 It is important to note that with the exception of the appendices and some examplesembedded within the text, the main sections and the annexes are considered normative, , required toapply 12 sections of DO-178B describe processes and activities for the most stringent level of software.*Annex A provides a level by level tabulation of the objectives for lower levels of software.** This levelingis illustrated in Figure extracted from Annex A Table A-4, Verification of Outputs of Software addition to the leveling of objectives, Annex A tables serve as an index into the supporting text byway of reference, illustrate where independence is required in achieving the objective, which data itemsshould include the objective evidence, and how that evidence must be controlled.

9 More will be said aboutthe contents of the various Annex A tables in the corresponding process section of this text. If an applicantadopts DO-178B for certification purposes, Annex A may be used as a checklist to achieve these FAA s position is that if an applicant provides evidence to satisfy the objectives, then the software isDO-178B compliant. Accordingly, the FAA s checklists for performing audits of DO-178B developmentsare based on Annex A discussing the individual sections, it is useful to look at a breakout of objectives as contained inAnnex A. While DO-178B contains objectives for the entire software development life cycle, there is a clearfocus on verification as illustrated by Figure Although at first glance it appears that there is only oneobjective difference between levels A and B, additional separation between the two is accomplished through FIGURE Example objective from Annex A.

10 FIGURE Objectives over the software development life cycle. *Levels are described in Section , Software as part of system. **Software that is determined to be at level E is outside the scope of SW LevelOutputControlCategoryby SWLevelDescription Ref. A B C D Description Ref. A B C D1 Low-levelRequirementscomply 2 2 2 2 0510152025303540 Level ALevel BLevel CLevel 2001 by CRC Press LLC the relaxation of independence requirements. Independence is achieved by having the verification orquality assurance of an activity performed by a person other than the one who initially conducted theactivity.


Related search queries