1. Avionics Software Standards
Sushma-COE11B010
Kuladeep-COE11B026
December 8, 2012
Contents
1 Introduction 2
2 History of DO-178B 2
2.1 DO-178 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 DO-178A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.3 DO-178B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 Drawbacks of DO-178B 6
5 DO-178C 6
5.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 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. 1 Introduction
Avionics software is embedded software with legally mandated safety and reliability con-
cerns used in avionics. The main difference between avionic software and conventional
embedded software is that the development process is required by law and is optimized
for safety. It is claimed that the process described is only slightly slower and more costly
than the normal ad-hoc processes under for commercial software.Since most software
fails because of mistakes,eliminating the mistakes at the earliest possible step is also a
relatively inexpensive,reliable way to produce software.
To assure safety and reliability, national regulatory authorities like FAA,CAA,DOD
require 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-178B
Earlier, 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 realized
that the usual approach to seek the safety and reliability will not work for Safety critical
systems. There was a great need for finding design errors which came out in the form
of first DO- 178 certification document.
2.1 DO-178
The rules were developed by trial and error over time. The concept was first introduced
by DO-178 that describes the software verification requirements which were dependent
on the safety criticality of the software. The software applications were divided into three
categories: critical, essential, and nonessential. DO-178 also established the relationship
between 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. The
concept of a system’s failure condition categories established classifications of software
according to the effects of malfunctions or design errors and took into consideration the
product application.
Software development processes were described in a more systematic and structured
manner. The verification process included distinctions in effort required by software
level.
Strengths and weaknesses of DO-178A soon became apparent. Literal interpretation,
particularly from diagrams were a problem. Misuse included non-allowance of life cycles
other than the traditional waterfall model
2

3. 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 Equipment
EUROCAE WG-12.
DO-178B was initiated to address the problems. The purpose was to provide detailed
guidelines for the production of software for airborne systems that perform intended
functions 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-178B
Not 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 safety
at 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 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.
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. 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 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 Processes
The data exchange between the software and systems de- velopment processes is defined
as the part of the software life-cycle processes in DO-178B. This includes the planning
process, 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. 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. – 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-178B
Since 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 concepts
of High Level Requirements, Low Level Requirements, and Derived Requirements and
a better definition of the exit/entry criteria between systems requirements and system
design and that of software requirements and software design. Other topics such as
what does verification mean in a model-based development paradigm and can model
simulation or formal methods replace some or all software testing activities.It has strong
emphasis on requirements-based testing and traceability of life cycle data but does not
consider new development methodologies like MBT.
5 DO-178C
The structure of the document remains largely the same from B to C. A few changes are
as follows:
6

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 6.4.4.2b
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 Includes
Formal Methods - Mathematical based techniques used for specification, development
and verification of a avionics software. Formal methods can be used to "prove that soft-
ware is an accurate representation of the mathematical expressions”. Object Oriented
Programming: Languages like C++ and Ada are popular because they are at a higher
level of abstraction than other languages which lead to promote re-use and promise
more efficient development. Model-Based development which model systems at very
high-level, domain-specific languages, are often used to automatically generate source
code 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 is
that it is often misunderstood as software development standard rather than a assurance
standard.
Inclusion of object oriented programming languages like C++ and Ada facilitate a
high degree of automation of the verification and test techniques. The Formal Methods
allow to look on the parts or the whole code and enable the software verification process
to begin earlier which reduces the development risk. And the Model-based development
tools are used for modeling a system of high level which allows it to automatically
generate the source code directly from the model.
DO-178C which is partially approved,clarified most of the unclear topics of DO-178B
and includes few latest technologies Model Based Development tools makes it far better
standard than its predecessor. DO-178C is the Bible of Avionics Software.
7

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