Avionics Software StandardsSushma-COE11B010

Kuladeep-COE11B026

December 8, 2012

Contents1 Introduction 2

2 History of DO-178B 22.1 DO-178 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2 DO-178A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.3 DO-178B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 Features of DO-178B 33.1 DO-178B Document Structure . . . . . . . . . . . . . . . . . . . . . . . . 4

3.1.1 Software Life-Cycle Processes . . . . . . . . . . . . . . . . . . . . . 43.1.2 Integral Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4 Drawbacks of DO-178B 6

5 DO-178C 65.1 DO-178C Includes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

6 Conclusion 7

7 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 standardsfor de- velopment of aviation softwares. The difference between creating aviationsoftware 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 alsogive brief introduction to the future version DO-178C documents. The developmentand verification process using document RTCA DO-178B/ED-12B.

1

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-178

The 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-178A

The 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

2.3 DO-178B

DO-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 thoseobjectives

• 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- WithLevel 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 ina hazardous or severe failure condition

C Major Conditions which would significantly 57 2reduce aircraft safety, crew ability towork under adverse operation.

D Minor Conditions which would not significantly 28 2reduce aircraft safety, slight increase increw workload.

E No Effect Conditions which do not affect the 0 0aircraft operation or crew workload.

Table 1: DO-178B SW levels and characteristics

3

3.1 DO-178B Document Structure

DO-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 IntegralProcesses detailed in Sections 6, 7, 8 and 9.

• Section 11 provides details on the life cycle data and Sec- tion 12 gives guidanceto any additional considerations.

• Annex A provides a leveling of objectives. Annex B provides the document’sglossary.

• Appendices A, B, C, and D provide additional material including a brief historyof the document, the index,a list of contributors, and a process improvement formrespectively.

3.1.1 Software Life-Cycle Processes

The 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. Theyare

• 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 DevelopmentProcesses, Software requirements process, Software design process, Software cod-ing process and Integration process. There is a section on requirements traceabilitythat 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 andtraceability from low level design requirements to the source code and object code.

4

Software Coding Standards

• For a programming language,reference the data that unambiguously definesthe syntax, the control behaviour, the data behaviour and side-effects of thelanguage. 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 developmentand verification process is determined by requirements coverage or traceability.This analysis assures that software requirements are properly associated with therequisite test cases and can be traced from their highest level through the designto 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 thirdsof the total.

The objectives of the Software Verification Process are “to detect and report errorsthat may have been introduced during the software development processes.”Theseobjectives are satisfied “through a combination of reviews, analyses, the devel-opment of test cases and procedures, and the subsequent execution of those testprocedures. Review and analyses provide an assessment of the accuracy, complete-ness and verifiability of the software requirements, software architecture and sourcecode.”

The requirements based test cases may not have completely exercised the codestructure, so structural coverage analysis is performed and additional verificationproduced to structural coverage.

Structural Coverage Analysisa) The analysis should confirm the degree of structural coverage appropriate tothe 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 thecode components.

5

– Level D: Software verification requires test coverage of high-level requirementonly. 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 thatthe source code can be shown to map directly to object code. The reason for thisrule is that some compilers may introduce code or structure that is different fromsource code.

2. Software Configuration ManagementThe six objectives in this are uniquely defined to meet all software levels which areas 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 AssuranceSoftware quality assurance (SQA) objectives provide oversight of the entire DO-178B process and require independence at all levels. SQA guarantees detection ofplans 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

• 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 6.4.4.2bbut 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, thatcannot 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 Includes

Formal 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 ConclusionThe 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

7 References1. 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