See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/276153236

Software Certification of Safety-Critical Avionic Systems: DO-178C and Its

Impacts

Article  in  IEEE Aerospace and Electronic Systems Magazine · April 2015

DOI: 10.1109/MAES.2014.140109

CITATIONS READS
31 18,814

4 authors, including:

Wonkeun Youn Kyung Ryoon Oh

Chungnam National University Korea Aerospace Research Institute
31 PUBLICATIONS   460 CITATIONS    10 PUBLICATIONS   60 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

State estimation/navigation/tracking/multi-sensor fusion View project

All content following this page was uploaded by Wonkeun Youn on 18 March 2021.

The user has requested enhancement of the downloaded file.

Software Certification of Safety-Critical Avionic
Systems: DO-178C and Its Impacts
Won Keun Youn, Seung Bum Hong, Kyung Ryoon Oh, and Oh Sung Ahn
Aeronautics Research and Development Head Office
Daejeon, Republic of South Korea
INTRODUCTION
T
he rapid growth in the use of software in airborne systems and
equipment in the early 1980s resulted in a need for industry-
accepted guidance for satisfying airworthiness requirements
[1]. To assure the reliability of the software and to ultimately en-
sure the safety of passengers, the U.S. Federal Aviation Admin-
istration (FAA) has imposed software certification suited to the
development of safety-critical systems. The FAA has accepted
guidelines developed by the Radio Technical Commission for
Aeronautics (RTCA) that respond to the necessity of reliability
and safety, which are vital in this field: DO-178B/EUROCAE
ED-12B (DO-178B), titled Software Considerations in Airborne
Systems and Equipment Certification [1]. DO-178B prescribes
design assurance guidance for airborne software. The aim of DO-
178B is to assure that software developed for avionics systems is
reliable and safe to use in flight [2].
Since its release, DO-178B has enjoyed widespread accep-
tance and has been the primary means for receiving regulatory
approval for using software on commercial aircraft [3]. Despite
frequent criticisms of the guidelines, there is strong empirical evi-
dence that it has been successful [4]. For instance, no hull-loss
accidents have been ascribed to software developed under DO-
178B. Software developed under DO-178B has been a significant
contributing factor in only a small number of accidents and in-
flight upsets [5], [6].
However, there have been strong calls by the aviation industry
for clarification or refinement of the key DO-178B concept due
to its relative ambiguity and flexibility [7]. Moreover, the rapid
advance in modern software technology has resulted in software
development and verification technologies and methods that were
not adequately covered in DO-178B, and the effectiveness of
DO-178B has become questionable as the size and complexity of
modern avionic software increase. For instance, DO-178B makes
Authors’ current address: Aeronautics Research and Develop-
ment Head Office, Korea Aerospace Research Institute, 169-84
Gwahangno Yuseong-gu, Deajeon 305-806, Republic of South
Korea, E-mail: wkyoun@kari.re.kr.
Manuscript received May 27, 2014, revised August 20, 2014,
and ready for publication October 12, 2014.
DOI. No. 10.1109/MAES.2014.140109.
Review handled by W. Walsh.
0885/8985/15 $26.00 © 2015 IEEE
4 IEEE A&E SYSTEMS MAGAZINE APRIL 2015
little or no allowance for current development and verification
technologies and methods such as model-based development, for-
mal methods, and object-oriented technologies.
Thus, the FAA and representatives of the aviation industry
initiated a discussion with RTCA regarding the advances in soft-
ware technology since the guidance’s release in 1992. In Decem-
ber 2004, RTCA and the European Organisation for Civil Avia-
tion Equipment (EUROCAE) decided that DO-178B should be
updated to reflect the many advances in software engineering that
had been made since 1992 [8]. Thus, a joint RTCA Special Com-
mittee (SC-205) and EUROCAE Working Group (WG-71) were
established to prepare DO-178C. This joint group began meet-
ing in March 2005 and completed its work in November 2011.
DO-178C and other supplementary documents received official
regulatory authority approval by the FAA in July 2013.
Although a number of studies have explored software and
hardware guidelines [9] [10], few studies have reviewed the simi-
larities and differences between DO-178B and DO-178C. One of
the reasons for the high development costs of avionic systems
complying with DO-178B/C may be a lack of sufficient under-
standing of how to implement the guidance efficiently. Thus, it is
important to understand DO-178B/C and how to change avionic
systems to effectively manage the processes required by these
standards; this understanding will minimize the development cost
while ultimately ensuring the integral safety of the avionics.
Therefore, this article presents an overview of the new guide-
lines for safety-critical airborne software contained in DO-178C
and supplementary documents. The similarity between DO-
178B and DO-178C is presented by reviewing the basics of DO-
178 verification philosophy, and an overview of the major new
guidance in DO-178C is presented to highlight what has been
changed, along with a description of the impact of DO-178C on
the industry. The remaining sections of the article provide a dis-
cussion of the new guidelines in the supplementary documents:
DO-330 to DO-333.
OVERVIEW OF DO-178C
DO-178C, Software Considerations in Airborne Systems and
Equipment Certification, is a document published in December
2011 by RTCA, in joint effort with EUROCAE, and officially ap-
proved in July 2013. RTCA’s SC-205 and EUROCAE’s WG-71
were established to update DO-178B. The membership of SC-
205/WG-71 was open to anyone who wished to participate. These
members come from many countries and represent a range of or-
ganizations, including certification authorities such as the FAA
and European Aviation Safety Agency; aviation industries such
as Boeing and Airbus; and engine and equipment manufacturers
such as GE Aviation, Rolls-Royce, Honeywell, and Pratt & Whit-
ney, together with a number of small, specialist organizations and
consultants. Any change of context requires the consensus of all
members present at a plenary meeting [8]. The RTCA/EURO-
CAE joint committee’s work was divided into seven subgroups:

✓✓SG 1: SC/WG Document Integration

✓✓SG 2: Issues and Rationale

✓✓SC 3: Tool Qualification

✓✓SG 4: Model-Based Development and Verification

✓✓SG 5: Object-Oriented Technology

✓✓SG 6: Formal Methods

Figure 1.
✓✓SG 7: Safety-Related Considerations The relationship between DO-178C and supplementary documents.

All work is coordinated via a website that is a collaborated

work management mechanism. Working artifacts and draft docu-
ments were held in a restricted area available to group members
only. The terms of reference for SC-205/WG-71 can be summa-
rized as follows:
✓✓Maintain the current objective-based approach for software
assurance.
✓✓Maintain the technology-independent nature of DO-178B
objectives.
✓✓Maintain backward compatibility with DO-178B.
✓✓Address clear errors or inconsistencies and fill any gaps.
The purpose of DO-178C remains essentially unchanged “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.” DO-178C defines a consensus of the aerospace
industry regarding the approval of airborne software [8].
Overall, DO-178C keeps most of the DO-178B text, but it is
not merely an update of DO-178B. The RTCA/EUROCAE joint
committee has produced four development technology supple-
ments for DO-178C: tool qualification (DO-330), model-based
development and verification (DO-331), object-oriented technol-
ogy (OOT) and related techniques (DO-332), and formal methods
(DO-333). DO-248C, an updated version of DO-248B, provides a
list of frequently asked questions, discussion papers, and rational
for DO-178C, as shown in Figure 1. These supplements associ-
ated with DO-178C have been published by the RTCA as stand-
alone documents:
✓✓DO-248C: Supporting Information for DO-178C and DO-
278A
✓✓DO-330: Software Tool Qualification Considerations
✓✓DO-331: Model-Based Development and Verification Sup-
plement to DO-178C and DO-278A
✓✓DO-332: Object-Oriented Technology and Related Tech-
niques Supplement to DO-178C and DO-278A
✓✓DO-333: Formal Methods Supplement to DO-178C and
DO-278A
Like DO-178B, the design assurance level of DO-178C is es-
tablished at the system level using a system safety assessment
process based on the failure conditions associated with the soft-
ware component [8]. The safety conditions are divided into five

APRIL 2015 IEEE A&E SYSTEMS MAGAZINE 5

Certification of Safety-Critical Avionic Systems

Table 1.

DO-178B/C Safety Criticality Overview (ARP4761 and AC25.1309) [8]

FAR/JAR failure-
Level System failure Description probability definition
(P = probability)

A Catastrophic Failure may cause multiple fatalities, usually with P < 10−9
loss of the airplane
B Hazardous/ Failure has a large negative impact on the safety 10−9 < P < 10−7
severe-major or performance, reduces the ability of the crew to
operate the aircraft, or has an adverse impact upon
the occupants
C Major Failure results in a significant reduction in safety, 10−7 < P < 10−5
significantly increases the crew’s workload, and may
cause discomfort to the occupants
D Minor Failure slightly reduces the safety margin or 10−5 < P
increases the crew’s workload and causes an
inconvenience for the occupants
E No effect Failure has no effect on the safe operation of the N/A
aircraft

categories according to their effects on the aircraft, crew, and pas-
sengers: catastrophic, hazardous/severe-major, major, minor, and
no effect [11], [12]. DO-178C guidance then determines five as-
surance levels, which relate to the above categorization of failure
conditions (Levels A–E), with Level A denoting the most rigor-
ous (on which the most rigorous objectives were set) and Level E
denoting the lowest level (on which no objectives were set). The
number of objectives to be satisfied (some with independence)
is determined by the software level. More detailed information,
including the safety conditions corresponding to these assurance
levels and Federal Aviation Regulation/Joint Aviation Require-
ments (FAR/JAR) failure probability, is given in Table 1.
Like DO-178B, coverage of DO-178C refers to the degree
to which it can be proved that the verification activities cover
all requirements, code structures, and object codes [8]. DO-178C
divides coverage into two types: requirement-based coverage
and structural coverage. Requirement-based coverage analyzes
the software test cases to confirm that they provide proof that all
requirements have been satisfied. Structural coverage is met by
proving that the test cases execute all code statements and that all
data coupling and control paths have been tested.
COMPARISONS BETWEEN DO-178B AND DO-178C
contained in the supplementary documents and discussed in later
sections of this article. The subsections here highlight some of the
new guidance contained in the DO-178C core document.
GENERAL: GAPS AND CLARIFICATIONS
DO-178C addresses known issues regarding errors and inconsis-
tencies, addressing the errata of DO-178B and removing incon-
sistencies across the tables of DO-178B Annex A [8]. Also, DO-
178C provides more precise, clearer language and terminology
standardization throughout the document. In addition, DO-178C
added hyperlinks to the document in Annex A to objectives and
life cycle data, for better usability, and the so-called hidden ob-
jective of DO-178B in Annex A (objective 9 of Table A-7 and
objective 1 of Table A-9). DO-178C address clear gaps in DO-
178B and addresses clarification of the guidance that was subject
to differing interpretations in DO-178B [8]. Examples of hidden
objectives include the following:
✓✓Verification of additional code that cannot be traced to
source code is achieved (objective 9 of Table A-7).
✓✓Assurance is obtained that software plans and standards
are developed and reviewed for compliance with this docu-
ment and for consistency (objective 1 of Table A-9).

Since the main structure and content of DO-178C are essentially
the same as those seen in DO-178B, the utility of this similarity
is to make DO-178C backward-compatible with DO-178B by de-
sign. This means that existing software that has been previously
approved under DO-178B can also be approved under DO-178C.
Although DO-178C keeps most of the DO-178B guidance, several
distinct improvements clarify or update DO-178B and reflect the
many advances in software engineering since 1992. The major new
guidance, additions, and modifications introduced in DO-178C are
Examples of gaps addressed include the following:
✓✓The modified condition/decision coverage definition has
been changed to support masking and short circuit, as well
as unique cause.
✓✓Derived requirements should be fed into all system pro-
cesses, including the system safety assessment process,
rather than just provided to the system safety assessment
process.

6 IEEE A&E SYSTEMS MAGAZINE APRIL 2015


Table 2.
Objective/Independence Allocation of DO-178B/C
DO-178B
Software level
(objective/independence)
Level A: 66/25
catastrophic
Level B: hazardous 65/14
Level C: major 57/2
Level D: minor 28/2
Level E: no effect 0 0
Examples of clarifications include the following:
✓✓Structural coverage analysis of data and control coupling
between code components should be performed by evaluat-
ing the results of the requirement-based tests (6.4.4.2.c).
✓✓All tests added to achieve structural coverage are based on
requirements (6.4.4.2.d).
✓✓Deactivated code design consideration to the design guid-
ance section (5.2.4) and the handling method in one of two
ways, depending upon its defined category, has been clari-
fied (6.4.4.3.d).
OBJECTIVES AND ACTIVITIES
DO-178C (section 2) uses the same software levels as were used
in DO-178B. The meaning of these levels is the same from the
meaning in DO-178B, as described in the previous section. How-
ever, the number of objectives to be satisfied (some with indepen-
dence) was changed as shown in Table 2: the number of objec-
tives and independence increases except for Levels D and E.
DO-178C emphasizes that the full body of DO-178C should
be taken into consideration in order to fully understand the guid-
ance. For example, tables in Annex A now include references to
each activity, as well as to each objective, and section 1.4, titled
How to Use This Document, reinforces that activities are a major
part of the overall guidance. Thus, the applicant should plan and
perform an activity that satisfies the objectives and provides ob-
jective evidence, as listed in section 11, to substantiate that objec-
tives have been satisfied.
LIFE CYCLE PROCESS/DATA
Like DO-178B, DO-178C primarily focuses on the production
processes; it is an evidence-based approach and does not address
any specific life cycle model [13]. These processes are divided
into three categories (Figure 2): a software planning process; a
software development process, including software requirements,
software design, software coding, and integration; and an integral
process, including software verification, software configuration
management, quality assurance, and certification liaison. The
APRIL 2015 IEEE A&E SYSTEMS MAGAZINE 7
Youn et al.
DO-178C
Change
(objective/independence)
71/30 +5/5
69/18 +4/4
62/5 +5/3
26/2 −2/0
No change
sections contained in DO-178C describing the software planning
process, software development process, integral process, and
overall verification activities to be performed are generally the
same as those presented in DO-178B.
The applicant should submit software data produced during
the life cycle to demonstrate compliance with DO-178C (summa-
rized in Table 3). There are 22 life cycle data items in DO-178C
and 20 items in DO-178B. In general, the life cycle data items of
DO-178C are identical to those of DO-178B except for two new
life cycle data items. However, there are several distinct life cycle
process/data differences. The subsections below highlight some
of the new or modified guidance associated with software life
cycle process/data.
Supplier Oversight
In DO-178C, the applicant is responsible for oversight of all
of its suppliers who are involved with any of the software life
cycle processes or the outputs of these processes [8]. The soft-
ware quality assurance process should provide assurance that
the process and output of the supplier comply with the approved
software plan and standards. DO-178C adds the need to include
supplier oversight information in the plan for software aspect of
certification (PSAC; 11.1.h), software configuration management
plan (11.4.e), software quality assurance plan (11.5.g), and soft-
ware accomplishment summary (11.20.g). Unlike in DO-178C,
supplier oversight in DO-178B is not clearly defined.
Parameter Data Item
DO-178C introduces parameter data items (configuration files) as
software life cycle data items, including two additional objectives
in the Annex tables (objectives 8 and 9 of Table A-5), and treats
parameter data items in the same manner as executable object code.
In DO-178C, parameter data form a data set that influences the be-
havior of the software without modifying the executable object
code and is treated as a separate configuration item [8]. The param-
eter data file consists of a form of data that is directly usable by the
processing unit of the target computer. Parameter data items can
be used to configure the software or provide database information
that the executable code can use in execution. Parameter data items
may contain data that can do the following [8]:
Certification of Safety-Critical Avionic Systems

In nearly all instances, DO-

178C replaces the phrase “execut-
able object code” used in DO-178B
with “executable object code and
parameter data items.” In making
this change, DO-178C calls for the
same verification process to be fol-
lowed for parameter data file items
as that done for executable object
code. For instance, if parameter
data items are planned, the high-
level requirements should describe
how each parameter data item is
used by the software.

Trace Data: Bidirectional Software

Figure 2.
The software life cycle described in DO-178C.
✓✓Influence paths executed through the executable object
code
✓✓Activate or deactivate software components and functions
✓✓Adapt the software computation to the system configura-
tion
✓✓Be used as computational data
✓✓Establish time and memory partitioning allotments
✓✓Provide initial values to the software component
Table 3.
Traceability
DO-178C emphasizes that two-
way or bidirectional traceability
is required between (1) system re-
quirements (allocated to software)
and high-level requirements, (2)
high-level requirements and low-
level requirements, (3) low-level
requirements and source code, (4) software requirements and test
cases, (5) test cases and procedures, and (6) test procedures and
test results [8]. Although DO-178B probably had this intent, the
wording implied traceability only in the decomposition direction
from high-level requirements to source code. DO-178C clarifies
that traceability needs to be verifiable in both directions and that
verifiable trace data between these entities must exist.
In DO-178C, trace data provide evidence of traceability of
development and verification processes’ software life cycle data.

Software Life Cycle Data

DO-178C life cycle data (22 items)

Plan for software aspect of certificationa Executable object code

Software development plan Software verification cases and procedures
Software verification plan Software verification results
Software configuration management plan Software life cycle environment configuration index
Software quality assurance plan Software configuration indexa
Software requirement standards Problem reports
Software design standards Software configuration management records
Software code standards Software quality assurance records
Software requirement data Software accomplishment summarya
Design description Trace datab
Source code Parameter data item fileb
a
Must be submitted to certification authority.
b
New life cycle data.

8 IEEE A&E SYSTEMS MAGAZINE APRIL 2015


Table 4.
Tool Qualification in DO-178B and DO-178C
DO-178B DO-178C
Development tool Criterion 1
Verification tool Criterion 2
Criterion 3
This ensures that orphan source code and dead source code are
not inadvertently produced. DO-178C allows an exception to re-
quirement traceability for compilers that produce object code that
is not directly traceable to source code. However, the software
planning process must provide a means to detect this code and
ensure its verification.
PRODUCT SERVICE HISTORY
If equivalent safety for the software can be demonstrated by the
use of the product service history of the software, DO-178C pro-
vides expanded guidance for using product service history as a
means to gain certification credit under alternative methods (sec-
tion 12.3). Use of service history data for certification credit is
based on sufficiency, relevance, and types of reported problems
during the service history period. For instance, related software
that has been in service a length of time and whose executable
object code has not been modified in an uncontrolled manner may
be given certification credit.
DO-178C states that the software developer should propose
the amount of certification credit sought in the PSAC. Although
DO-178B states the use of product service history as a means to
gain certification credit under alternative methods, guidance for
determining the applicability of service history and the length of
service history needed is not described sufficiently compared to
DO-178C.
SUPPLEMENTS
As discussed earlier, the revision to the guidance is not limited to
clarification but also includes four new supplementary documents
to address the state of the art and practice in software technol-
ogy. Each technology supplement is objective based and expands
on the objectives in the DO-178C core document for its specific
technology. Each technology supplement describes how the ob-
jectives of DO-178C apply, are modified, or are replaced. The
following subsections provide a summary of the major new guid-
ance contained in the supplementary documents.
Tool Qualification (DO-330)
In DO-178C, a software tool is defined as “A computer program
used to help develop, test, analyze, or modify another program
or its documentation. Examples are an automated design tool, a
compiler, test tools, and modification tools” [14]. Due to the in-
creasing number of software tools being used and the number of
third-party tool manufacturers, the guidance of tool qualification
APRIL 2015 IEEE A&E SYSTEMS MAGAZINE 9
Youn et al.
Table 5.
Tool Qualification Level Determination of DO-178C
Criteria
Software level
1 2 3
Level A TQL-1 TQL-4 TQL-5
Level B TQL-2 TQL-4 TQL-5
Level C TQL-3 TQL-5 TQL-5
Level D TQL-4 TQL-5 TQL-5
was expanded and separated from DO-178C into a stand-alone
document, DO-330. DO-178C refers the applicant to this tool
qualification supplement for specific guidance.
Tool qualification is the process used to gain certification
credit for a software tool whose output is not verified indepen-
dently when the tool is used to eliminate, automate, or replace
processes required by DO-178C in the document [15]. Prior to
the use of a tool, tool assessment and qualification should be
performed to ensure the capability of conducting the particular
development or verification activities to an acceptable level of
confidence. The purpose of the tool qualification process is to en-
sure that the tool provides a confidence level at least equivalent to
the one that process eliminated, reduced, or automated.
In DO-178B, tools are classified as either development tools
(or design tool), which can cause errors into the product, or
verification tools, which cannot cause errors but may fail to de-
tect them. DO-178B addressed tool qualification with a simple
partition into development tools and verification tools. Unlike
DO-178B, in DO-178C, the potential impact of tool use in the
software life cycle process should be assessed to one of five tool
qualification levels (TQLs). Tool qualification in DO-178B and
DO-178C is summarized in Table 4. The following criteria should
be used to determine the impact of the tool [14]:
1. A tool whose output is part of the airborne software and thus
could insert an error
2. A tool that automates the verification process, and thus could
fail to detect an error, and whose output is used to justify the
elimination or reduction of either of the following:
a. Verification process other than that automated by the tool
b. Development process that could have an impact on the
airborne software
3. A tool that, within the scope of its intended use, could fail to
detect an error
Five levels of tool qualification, TQL-1 to TQL-5, are defined
based on tool use and its impact in the software life cycle process-
es (Table 5). TQL-1 has the most objectives requiring satisfaction
by independence. TQL-2 has fewer objectives requiring indepen-
dent satisfaction compared with TQL-1, but it requires almost the
same activities. TQL-3 has fewer activities compared with TQL-
2 and does not require independence of verification except for
Certification of Safety-Critical Avionic Systems
the quality assurance activities. TQL-4 (A special category that
has no equivalence to a DO-178C software level) provides less
stringent satisfaction of the tool planning process, the tool devel-
opment process, and the verification of outputs. TQL-5 further
relaxes the requirements by requiring no tool development pro-
cess, verification tool requirement process, integration process, or
testing of tool outputs.
DO-330 requires that a tool operational requirements (TOR)
document be written to specify the requirements of how the tool
will be used within the software life cycle. The requirements set
forth in the TOR are required to be verified and validated. The
structure and content of DO-330 are similar to those of DO-178C
in many respects, but DO-330 has its own set of objectives. DO-
330 also recommends the same software development life cycle
process as those specified in DO-178C but references the TOR
rather than system requirements. The tool requirements are, in
turn, developed from the TOR and are then used to develop the
tool architecture and low-level requirements. The verification of
the tool design process, the tool coding process, and the tool inte-
gration process are essentially similar to those presented in DO-
178C. Like DO-178C, DO-330 requires bidirectional traceability
between requirements and code.
Model-Based Development and Verification (DO-331)
In DO-331, a model is defined as follows: “an abstract represen-
tation of a given set of aspect of a system that is used for analy-
sis, verification, simulation, code generation, or any combination
thereof” [16]. DO-331 defines two types of models, specification
models and design models, and it makes a distinction between
requirements for specification models and those for design mod-
els. Specification models represent high-level software require-
ments to state the model functional, performance, interface, and
safety characteristics of a software component. Design models
use primarily low-level requirements and software architecture
specifications to represent internal data structures, data flow,
and control flow. In either case, DO-331 requires that the mod-
els specify the configuration items, modeling techniques, model
element libraries, interface descriptions, configuration items, and
model development environment. Traceability among the design
model, low-level requirements and the model code is required.
There should be no model code that cannot be traced back to low-
level requirements.
In DO-331, model coverage analysis is defined as follows: “An
analysis that determines which requirements expressed by design
model were not exercised by verification based on the requirements
from which the design model was developed” [16]. The objective
of model coverage analysis is to discover unintended function and
requirements contained in the model that were not exercised by
verification test cases. DO-331 recommends that model coverage
be shown for all state machine transitions, logic equation decisions,
numeric data equivalence classes (and boundary data), and derived
requirements. Model coverage analysis should be performed using
requirement-based verification test cases.
In DO-331, model simulation may be used to satisfy some of
the DO-331 verification objectives. The purposes of model simu-
lation are to verify that the model meets the requirements used to
10 IEEE A&E SYSTEMS MAGAZINE APRIL 2015
create it and to gather evidence that the model is accurate, consis-
tent, and compatible with all system-level, high-level, and low-
level requirements [16]. In order to gain certification credit for
simulation, DO-331 requires that the applicant clearly show what
reviews and analyses are needed to satisfy the model verification
objectives. The analyses must show that simulation cases exist
for each model requirement and that these simulations address
both normal range and robustness test inputs. Verification of the
executable object code is encouraged to be primarily performed
by testing in the target computer environment.
DO-331 recommends that software models be developed to
standards that define the modeling techniques, constraints, and
instructions used to build the models [16]. The software model
standards should specify the methods and tools used to develop
the models. In addition, the software model standards should in-
clude identification of modeling language to be used and any lan-
guage syntax, semantics, features, and limitations. The software
model standards should state the level of traceability between
requirements and other life cycle data. The software model stan-
dards should also specify any constraints on the use of modeling
tools and model supporting libraries.
OOT and Related Techniques (DO-332)
The objective of DO-332 was to provide guidance on the use of
object-oriented programming languages that use concepts such
as inheritance, polymorphism, overloading, type conversions, ex-
ception management, dynamic memory management, virtualiza-
tion, and other concepts not in common, universal usage at the
time DO-178B was developed [17]. The distinguishable feature
of OOT is the use of classes to define objects, along with the abil-
ity to create new classes via subclassing. In DO-332, a class de-
fines attributes, methods, relationships, and semantics that share
a common structure and behavior representative of a real-world
entity. The main difference between DO-332 and DO-178C can
be summarized as follows.
In the planning process of DO-332, three activities are add-
ed to the DO-178C planning process. First, any planned use of
virtualization and its associated executable program should be
described in the plans. Second, if component reuse is planned,
the plan should explain how the component will be integrated
with the new development. Third, the plans and standard should
describe how the vulnerabilities (DO-332 Annex OO.D) will be
addressed.
In the development process of DO-332, some OOT-specific
development guidelines, including class hierarchy, type consis-
tency, memory management, exception management, and deac-
tivated functionality, are added to the DO-178C development
process. For instance, DO-332 recommends that the class hierar-
chy used should be based on high-level requirements and verified
for consistency. A locally type-consistent class hierarchy should
be developed with associated low-level requirements wherever
substitution of types happens. DO-332 also calls for the software
development process to include a plan of strategy for dynamic
memory management and exception management. DO-332 states
that bidirectional trace data should exist to show traceability be-
tween requirements and methods, since all functionality is imple-

mented in methods in object-oriented programs. In addition, a
requirement that traces to a method in a class should also trace to
the method in its subclasses.
In the verification process of DO-332, three activities are
added or modified to ensure (1) verification of class hierarchy
for consistency with requirements, (2) local type consistency, (3)
verification of the memory management system for consistency
with the strategy defined in the software architecture, and (4)
verification of the exception management system for consistency
with the strategy defined in the software architecture. In addition,
normal-range testing should be performed to ensure “class con-
structors properly initialize the state of their objects and that the
initial stage is consistent with the requirements for the class” [17].
In DO-332, vulnerabilities analysis (Annex OO.D) should be
address to clarify issues related to the feature of new language
and to potential complications encountered with satisfying well-
established safety objectives. Vulnerabilities analysis is divided
into two categories: key feature and general issues. The vulner-
ability analysis for key feature includes inheritance, parametric
polymorphism, overloading, type conversion, exception manage-
ment, dynamic memory management, and virtualization. The vul-
nerability analysis for general issues is not directly related to any
object orientation–specific feature and thus consists of integral
issues that should always be considered regardless of the features
used in the project. The vulnerability analysis for general issues
explain how traceability, structural coverage, component usage,
and resource analysis may be complicated by a number of factors
inherent in object orientation and provides additional guidance to
consider when using OOT and related techniques [17].
Formal Methods (DO-333)
DO-333 defines formal methods as “descriptive notations and
analytical methods used to construct, develop and reason about
mathematical models of system behavior. A formal method is a
formal analysis carried out on a formal behavior” [18]. The objec-
tive of the supplement is to provide additions to and modification
of the DO-178C objectives, activities, explanatory text, and soft-
ware life cycle data that apply when formal methods are used as
part of the software life cycle. Formal methods are usually only
used in the development of safety, business, and mission critical
software where the cost of faults is high.
Formal methods are composed of two types of activities, for-
mal modeling and analysis, and they may be applied at various
stages in software development and used as a verification tech-
nique [19]. A formal model is “an abstract representation of a giv-
en set of aspects of a system that is used for analysis, simulation,
code generation, or any combination thereof. A formal model is
a model defined using formal notation” [18]. Formal modeling
represents system abstraction with unambiguous, mathematically
defined syntax and semantics, and it can be used for analysis,
simulation, and code generation. The formal models may be
graphical (e.g., state machine diagrams), differential equations,
or computer languages. Because formal notations are precise and
unambiguous, they can be used to assist verification by helping to
show accuracy and consistency in the representation of require-
ments and life cycle data.
APRIL 2015 IEEE A&E SYSTEMS MAGAZINE 11
Youn et al.
A formal analysis is “the use of mathematical reasoning to
guarantee that properties are always satisfied by a formal model”
[18]. The main differences between DO-178C and DO-333 are in
the area of verification. Since formal analysis has the ability to
prove the correctness of a formal model, the review, analysis, and
test objective of DO-178C may be replaced by formal analysis.
For example, DO-333 does not require all requirements of a for-
mal model to be formally expressed. However, if the high-level
requirements and low-level requirements are both formally mod-
eled, the formal analysis can be used to show compliance.
Formal methods were briefly introduced in DO-178B as al-
ternative methods, but the guidance was somewhat vague and
no explicit provisions were provided. Since formal methods
may find faults that are not detected by testing, formal meth-
ods are complementary to testing. Thus, formal methods can
increase confidence that no anomalous behavior will occur.
Since formal methods cannot establish verification evidence for
the target hardware, DO-178C still requires software/hardware
integration testing to be performed to ensure that code works
correctly on the target.
DISCUSSION
DO-178 is designed to be flexible and allow for various devel-
opment methods as long as they can show compliance with the
objectives of DO-178. However, DO-178B contains ambiguities
that could be misinterpreted by the applicant due to lack of ap-
plicant understanding. This may result in the applicant failing to
meet some of the DO-178B objectives. In addition, compliance
with DO-178 guidelines in software development is often consid-
ered as contributing to the high expense of commercial aviation
systems because DO-178 requires rigorously iterative processes
and extensive documentation throughout the entire software life
cycle. Although applicants who have used DO-178B in the past
may still be able to use the same means of compliance for cer-
tification projects, upgrading applicants’ process to DO-178C is
highly recommended [20]. New applicants or developers who
are establishing software life cycle processes should do so in
accordance with DO-178C. Thus, it is important to understand
the changes between DO-178B and DO-178C and their effects
to effectively manage the processes required by these guidelines,
minimize development costs, and ultimately assure the integral
safety of entire avionic systems.
Compared to DO-178B, DO-178C and its supplements some-
what reduce the extent of this confusion and hence allow a more
consistent approach to developing and certifying safety-critical
software. Also, it was demonstrated that the process defined by
DO-178C became more clarified and detailed, the average number
of requirements increased, the entire scope was expanded, and the
variety of software development methods increased. More spe-
cifically, DO-178C acknowledged that one or more technology-
specific supplements may be used in conjunction with DO-178C
to modify the guidance for specific techniques. Thus, DO-178C
provides a more formal, more prescriptive approach for qualify-
ing formal methods and model-based tools and for verifying the
capabilities of object-oriented languages.
Certification of Safety-Critical Avionic Systems
However, there are a number of potential challenges when im-
plementing the technology in DO-178C supplements. Although
formal methods offer a number of potential benefits, including an
improved requirements definition, reduced errors, and maintain-
able software, formal methods have rarely been used in the civil
aviation field due to their limitations [21]. For instance, formal
methods are not applicable to all problems, and there are still
many project-by-project issues to be solved. Furthermore, it can
be highly challenging to combine formal and traditional nonfor-
mal methods in one project. Thus, DO-331, of all DO-178C sup-
plements, will likely be the most challenging to apply, especially
when trying to apply the guidance to existing models. Likewise,
OOT and model-based development and verification technology
are appealing technology to the aviation industry for several rea-
sons, including strong tool support, availability of programmers,
perceived cost savings, and potential for reusability, but they have
not been extensively used in aviation fields to date due to limita-
tions not seen with the traditional techniques. Above all, there
is no abundance of the technology among DO-178C supplement
practitioners, so this can be a barrier to successful use of the tech-
niques.
Therefore, implementing a new technology described in DO-
178C supplements for the first time can be a minefield of unex-
pected challenges and thus requires careful applicants [21]. In ad-
dition, since the technology described in DO-178C supplements
is still relatively new in the aviation field, the certification author-
ity will be more cautious with any new technology and tend to
oversee it closely. It is the responsibility of the applicant to ensure
that a supplement’s use is acceptable to the appropriate certifica-
tion authority. Therefore, coordination should be established with
the certification authority as early as possible to gain agreement
on the means of compliance for successful certification. Never-
theless, the new technology described in DO-178C supplements
offers a number of potential benefits, as discussed above, so a
number of applicants have recently initiated their project by using
the technology in the supplements and have received the certifica-
tion credit. As experience and the technology mature, the benefits
will likely increase. In addition, it can be expected that as the
use of software increases, technology evolves, and experience is
gained in the application of DO-178C and its supplements, there
may be some additional certification authority guidelines in the
near future to clarify development and verification issues.
CONCLUSION
This article provides a practitioner’s comprehensive view of the
new DO-178C standard and its supplements. The aim of this
article is to help those unfamiliar with DO-178C to gain clear
understanding of the scope of the information contained in the
nearly 1,000 pages. The similarities and differences between
DO-178B and DO-178C, along with the related supplementary
documents, have been extensively described in various aspects.
This article also describes how they will affect the applicant’s
organization, focusing on the practical implications of the many
changes between DO-178B and DO-178C. It can be summarized
that the process defined by the standards became more clarified
12 IEEE A&E SYSTEMS MAGAZINE APRIL 2015
and detailed, the number of requirements increased, the scope
was expanded, and the variety of software development methods
increased.
Although it was impossible to provide every detail of DO-
178C within the scope of this article, it is hoped that the compre-
hensive information herein, along with a description of the impact
of DO-178C, will help applicant to reduce potential compliance
problems, minimize development costs, and ultimately assure the
integral safety of avionic systems. The reader requiring specific
information must download these documents from RTCA in order
to fully appreciate and apply the new guidance.
To the best of our knowledge, there have been a few stud-
ies exploring software and hardware guidelines [9], [10], but few
studies have reviewed the similarities and differences between
DO-178B and DO-178C or described the impact of DO-178C on
the industry. Therefore, this study has significant implications in
terms of demonstrating an overview of and the similarities and
differences between DO-178B and DO-178C, along with the im-
pacts of DO-178C; this article may serve as a useful entry point
for those unfamiliar with DO-178C to understand the rationale
and clues behind this new certification guidance for airborne soft-
ware certification.
REFERENCES
[1] Software Considerations in Airborne Systems and Equipment Certifi-
cation. RTCA document DO-178B, 1992.
[2] Dodd, I., and Habli, I. Safety certification of airborne software: an
empirical study. Reliability Engineering & System Safety (2011).
[3] Kornecki, A., and Zalewski, J. Software certification for safety-critical
systems: A status report. In Proceedings of the IEEE, 2008, 665–672.
[4] Holloway, C. Towards understanding the DO-178C/ED-12C assur-
ance case.
[5] Daniels, D. Thoughts from the DO-178C committee. In Proceedings
of the 6th IET International Conference on System Safety, 2011, 1–7.
[6] Youn, W., and Yi, B.-J. Software and hardware certification of safety-
critical avionic systems: a comparison study. Computer Standards &
Interfaces, Vol. 36 (2014), 889–898.
[7] Kornecki, A., and Zalewski, J. Certification of software for real-time
safety-critical systems: state of the art. Innovations in Systems and
Software Engineering, Vol. 5 (2009), 149–161.
[8] Software Considerations in Airborne Systems and Equipment Certifi-
cation. RTCA document DO-178C, 2011.
[9] Kornecki, A. J., and Zalewski, J. Hardware certification for real-time
safety-critical systems: state of the art. Annual Reviews in Control,
Vol. 34 (2010), 163–174.
[10] Hesselink, H. A comparison of standards for software engineering
based on DO-178B for certification of avionics systems. Microproces-
sors and Microsystems, Vol. 19 (1995), 559–563.
[11] Guidelines for Development of Civil Aircraft and Systems. SAE Inter-
national document ARP4754A, 2010.
[12] Guidelines and Methods for Conducting the Safety Assessment Pro-
cess on Civil Airborne Systems and Equipment. SAE International
document ARP4761, 1996.
[13] Yan, F. Comparison of means of compliance for onboard software cer-
tification. In Proceedings of the IEEE, 2009, 917–920.

[14] Software Tool Qualification Considerations. RTCA document DO-
330, 2011.
[15] Kornecki, A., Butka, B., and Zalewski, J. Software tools for safety-
critical systems according to DO-254. Computer, Vol. 41 (2008),
112–115.
[16] Model-Based Development and Verification Supplement to DO-178C
and DO-278A. RTCA document DO-331, 2011.
[17] Object-Oriented Technology and Related Techniques Supplement to
DO-178C and DO-278A. RTCA document DO-332, 2011.
APRIL 2015 IEEE A&E SYSTEMS MAGAZINE 13
View publication stats
Youn et al.
[18] Formal Methods Supplement to DO-178C and DO-278A. RTCA doc-
ument DO-333, 2011.
[19] Gigante, G., and Pascarella, D. Formal methods in avionic software
certification: the DO-178C perspective. In Leveraging Applications of
Formal Methods, Verification and Validation. Applications and Case
Studies. Springer, 2012, 205–215.
[20] Airborne Software Assurance. FAA document AC 20-115C, 2013.
[21] Rierson, L. Developing Safety Critical Software. Boca Raton, FL:
CRC Press, 2013.