Avionics Software Standards


Published on

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Avionics Software Standards

  1. 1. Avionics Software Standards Sushma-COE11B010 Kuladeep-COE11B026 December 8, 2012Contents1 Introduction 22 History of DO-178B 2 2.1 DO-178 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2 DO-178A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.3 DO-178B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Features of DO-178B 3 3.1 DO-178B Document Structure . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1 Software Life-Cycle Processes . . . . . . . . . . . . . . . . . . . . . 4 3.1.2 Integral Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Drawbacks of DO-178B 65 DO-178C 6 5.1 DO-178C Includes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Conclusion 77 References 8 Abstract This paper is intended for the people who are completely unaware of DO-178B/ED- 12B document. The purpose of this paper is to explore certifications and standards for de- velopment of aviation softwares. The difference between creating aviation software and other software can be summarized in one simple phrase: "RTCA DO- 178B". This paper will give some overview on the history of DO-178 as well as also give brief introduction to the future version DO-178C documents. The development and verification process using document RTCA DO-178B/ED-12B. 1
  2. 2. 1 IntroductionAvionics software is embedded software with legally mandated safety and reliability con-cerns used in avionics. The main difference between avionic software and conventionalembedded software is that the development process is required by law and is optimizedfor safety. It is claimed that the process described is only slightly slower and more costlythan the normal ad-hoc processes under for commercial software.Since most softwarefails because of mistakes,eliminating the mistakes at the earliest possible step is also arelatively inexpensive,reliable way to produce software.To assure safety and reliability, national regulatory authorities like FAA,CAA,DODrequire software development standards. Some representative standards like MIL-STD-2167 for military systems,RCTA DO-178B for civil aircraft are introduced.2 History of DO-178BEarlier, the softwares were considered as the easy and flexible way to enhance the func-tionality of mechanical and analog electrical systems. But very soon, it was realizedthat the usual approach to seek the safety and reliability will not work for Safety criticalsystems. There was a great need for finding design errors which came out in the formof first DO- 178 certification document.2.1 DO-178The rules were developed by trial and error over time. The concept was first introducedby DO-178 that describes the software verification requirements which were dependenton the safety criticality of the software. The software applications were divided into threecategories: critical, essential, and nonessential. DO-178 also established the relationshipbetween the software certification process and the other relevant Federal Aviation Reg-ulations.2.2 DO-178AThe content and features of DO-178A were very different from the original version. Theconcept of a system’s failure condition categories established classifications of softwareaccording to the effects of malfunctions or design errors and took into consideration theproduct application.Software development processes were described in a more systematic and structuredmanner. The verification process included distinctions in effort required by softwarelevel.Strengths and weaknesses of DO-178A soon became apparent. Literal interpretation,particularly from diagrams were a problem. Misuse included non-allowance of life cyclesother than the traditional waterfall model 2
  3. 3. 2.3 DO-178BDO-178B is the standard for developing avionics software-intensive systems jointly pre-pared by the Radio Technical Commission for Aeronautics (RTCA) safety critical work-ing group RTCA SC-167 and the European Organization for Civil Aviation EquipmentEUROCAE WG-12.DO-178B was initiated to address the problems. The purpose was to provide detailedguidelines for the production of software for airborne systems that perform intendedfunctions with a level of confidence in safety and which comply with airworthiness re-quirements. The goal was the following: • Develop objectives for the life cycle processes. • Provide a description of the activities and design considerations for achieving those objectives • Provide a description of the evidence indicating the objectives have been satisfied.3 Features of DO-178BNot all avionics systems have the same criticality. Some systems may not require follow-ing a very rigorous development process since their malfunction may not affect safetyat all. To reflect this, DO-178B defines different failure condition categories.The soft-ware level is based upon the contribution of software to potential failure conditions asdetermined by the system safety assessment process. Table 1 shows the software levelper failure condition and the amount of DO-178B objectives associated to each. It alsoshows the number of objectives that have to be satisfied with independence. SW Failure Description Objec- With Level Condition tives Indep. A Catastropic Conditions which would prevent 66 25 continued safe flight and landing. B Hazardous Software that could cause or contribute 65 14 to the failure of the system resulting in a hazardous or severe failure condition C Major Conditions which would significantly 57 2 reduce aircraft safety, crew ability to work under adverse operation. D Minor Conditions which would not significantly 28 2 reduce aircraft safety, slight increase in crew workload. E No Effect Conditions which do not affect the 0 0 aircraft operation or crew workload. Table 1: DO-178B SW levels and characteristics 3
  4. 4. 3.1 DO-178B Document StructureDO-178B consists of 12 sections, 2 annexes and 3 appendices. • Section 2 and 10 provide a feedback to the overall certification process. • Software life cycle processes given in Sections 3,4 and 5 are supported by Integral Processes detailed in Sections 6, 7, 8 and 9. • Section 11 provides details on the life cycle data and Sec- tion 12 gives guidance to any additional considerations. • Annex A provides a leveling of objectives. Annex B provides the document’s glossary. • Appendices A, B, C, and D provide additional material including a brief history of the document, the index,a list of contributors, and a process improvement form respectively.3.1.1 Software Life-Cycle ProcessesThe data exchange between the software and systems de- velopment processes is definedas the part of the software life-cycle processes in DO-178B. This includes the planningprocess, the software development processes. 1. Software Planning Process: DO-178B defines five types of planning document for a software development. They are • Plan for Software Aspects of Certification. • Software Development Plan. • Software Verification Plan. • Software Configuration Management Plan. • Software Quality Assurance Plan. 2. Software Development Process: Four high level activities are identified in the DO-178B Software Development Processes, Software requirements process, Software design process, Software cod- ing process and Integration process. There is a section on requirements traceability that embodies the evolution and traceability of requirements from system level re- quirements to source code. DO-178B specifies that software must meet certain software coding process re- quirements. These include adherence to a set of software coding standards and traceability from low level design requirements to the source code and object code. 4
  5. 5. Software Coding Standards • For a programming language,reference the data that unambiguously defines the syntax, the control behaviour, the data behaviour and side-effects of the language. This may require limiting the use of some features of a language. • Source code presentation standards and source code documentation stan- dards. • Naming conventions for components, subprograms, variables and constants. DO-178B mandates that the correctness of the requirements-based development and verification process is determined by requirements coverage or traceability. This analysis assures that software requirements are properly associated with the requisite test cases and can be traced from their highest level through the design to the final implementation and deployment of the software on the hardware.3.1.2 Integral Process 1. Software Verification Process: Verification is the most important in DO-178B which accounts to over two thirds of the total. The objectives of the Software Verification Process are “to detect and report errors that may have been introduced during the software development processes.”These objectives are satisfied “through a combination of reviews, analyses, the devel- opment of test cases and procedures, and the subsequent execution of those test procedures. Review and analyses provide an assessment of the accuracy, complete- ness and verifiability of the software requirements, software architecture and source code.” The requirements based test cases may not have completely exercised the code structure, so structural coverage analysis is performed and additional verification produced to structural coverage. Structural Coverage Analysis a) The analysis should confirm the degree of structural coverage appropriate to the software level. b) The structural coverage analysis may be performed on the source code, un- less the software is level A c) The analysis should confirm data coupling and control coupling between the code components. 5
  6. 6. – Level D: Software verification requires test coverage of high-level requirement only. No structural cover- age is required. – Level C: Low-level requirement testing is required. – Level B: Decision coverage is required. – Level A: Code requires Modified Condition Decision Coverage (MCDC). Struc- tural coverage analysis may be performed on source code only to the extent that the source code can be shown to map directly to object code. The reason for this rule is that some compilers may introduce code or structure that is different from source code. 2. Software Configuration Management The six objectives in this are uniquely defined to meet all software levels which are as follows. • What is to be configured? • How baselines and traceability are established? • How problem reports are dealt with? • How the software is archived and loaded? and • How the development environment is controlled? 3. Software Quality Assurance Software quality assurance (SQA) objectives provide oversight of the entire DO- 178B process and require independence at all levels. SQA guarantees detection of plans and standards, deviated during development process are recorded, evaluated, tracked and resolved.4 Drawbacks of DO-178BSince the release of DO-178B, there have been strong calls by DERs for clarifica-tion/refinement of the definitions and boundaries between the key DO-178B conceptsof High Level Requirements, Low Level Requirements, and Derived Requirements anda better definition of the exit/entry criteria between systems requirements and systemdesign and that of software requirements and software design. Other topics such aswhat does verification mean in a model-based development paradigm and can modelsimulation or formal methods replace some or all software testing activities.It has strongemphasis on requirements-based testing and traceability of life cycle data but does notconsider new development methodologies like MBT.5 DO-178CThe structure of the document remains largely the same from B to C. A few changes areas follows: 6
  7. 7. • Provide clearer language and terminology, provide more consistency. • More objectives (for Levels A, B, and C) • Clarified the "hidden objective", which was implied by DO-178B in section but not listed in the Annex A tables. This objective is now explicitly listed in DO- 178C, Annex A, Table A-7, Objective 9: "Verification of additional code, that cannot be traced to Source Code, is achieved." • clarifying software tools and avionics tool qualification and addressing object- oriented software and the conditions under which it can be used. • addressing formal methods to complement (but not replace) testing.5.1 DO-178C IncludesFormal Methods - Mathematical based techniques used for specification, developmentand verification of a avionics software. Formal methods can be used to "prove that soft-ware is an accurate representation of the mathematical expressions”. Object OrientedProgramming: Languages like C++ and Ada are popular because they are at a higherlevel of abstraction than other languages which lead to promote re-use and promisemore efficient development. Model-Based development which model systems at veryhigh-level, domain-specific languages, are often used to automatically generate sourcecode directly from the model.6 Conclusion The DO-178B solely focuses on design assurance where the required assurance is de-fined on the basis of the criticality levels A to E.The major concern with DO-178B isthat it is often misunderstood as software development standard rather than a assurancestandard. Inclusion of object oriented programming languages like C++ and Ada facilitate ahigh degree of automation of the verification and test techniques. The Formal Methodsallow to look on the parts or the whole code and enable the software verification processto begin earlier which reduces the development risk. And the Model-based developmenttools are used for modeling a system of high level which allows it to automaticallygenerate the source code directly from the model. DO-178C which is partially approved,clarified most of the unclear topics of DO-178Band includes few latest technologies Model Based Development tools makes it far betterstandard than its predecessor. DO-178C is the Bible of Avionics Software. 7
  8. 8. 7 References 1. RTCA DO-178B (EUROCAE ED-12B) @ Ankit Singh 2. Introduction to DO-178B @ Eduardo Trejos, Quality Engineer and Jose Lopez, Software Engineer, Avionyx, 2010 3. Analyzing Software Requirements Errors in Safety-Critical, Embedded Systems @ @ RObyll It. Jultz Jet Propulsion I,aboratory California Institute of ’cch]lology. 8