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

little or no allowance for current development and verification

INTRODUCTION technologies and methods such as model-based development, for-

T
he rapid growth in the use of software in airborne systems and mal methods, and object-oriented technologies.
equipment in the early 1980s resulted in a need for industry- Thus, the FAA and representatives of the aviation industry
accepted guidance for satisfying airworthiness requirements initiated a discussion with RTCA regarding the advances in soft-
[1]. To assure the reliability of the software and to ultimately en- ware technology since the guidance’s release in 1992. In Decem-
sure the safety of passengers, the U.S. Federal Aviation Admin- ber 2004, RTCA and the European Organisation for Civil Avia-
istration (FAA) has imposed software certification suited to the tion Equipment (EUROCAE) decided that DO-178B should be
development of safety-critical systems. The FAA has accepted updated to reflect the many advances in software engineering that
guidelines developed by the Radio Technical Commission for had been made since 1992 [8]. Thus, a joint RTCA Special Com-
Aeronautics (RTCA) that respond to the necessity of reliability mittee (SC-205) and EUROCAE Working Group (WG-71) were
and safety, which are vital in this field: DO-178B/EUROCAE established to prepare DO-178C. This joint group began meet-
ED-12B (DO-178B), titled Software Considerations in Airborne ing in March 2005 and completed its work in November 2011.
Systems and Equipment Certification [1]. DO-178B prescribes DO-178C and other supplementary documents received official
design assurance guidance for airborne software. The aim of DO- regulatory authority approval by the FAA in July 2013.
178B is to assure that software developed for avionics systems is Although a number of studies have explored software and
reliable and safe to use in flight [2]. hardware guidelines [9] [10], few studies have reviewed the simi-
Since its release, DO-178B has enjoyed widespread accep- larities and differences between DO-178B and DO-178C. One of
tance and has been the primary means for receiving regulatory the reasons for the high development costs of avionic systems
approval for using software on commercial aircraft [3]. Despite complying with DO-178B/C may be a lack of sufficient under-
frequent criticisms of the guidelines, there is strong empirical evi- standing of how to implement the guidance efficiently. Thus, it is
dence that it has been successful [4]. For instance, no hull-loss important to understand DO-178B/C and how to change avionic
accidents have been ascribed to software developed under DO- systems to effectively manage the processes required by these
178B. Software developed under DO-178B has been a significant standards; this understanding will minimize the development cost
contributing factor in only a small number of accidents and in- while ultimately ensuring the integral safety of the avionics.
flight upsets [5], [6]. Therefore, this article presents an overview of the new guide-
However, there have been strong calls by the aviation industry lines for safety-critical airborne software contained in DO-178C
for clarification or refinement of the key DO-178B concept due and supplementary documents. The similarity between DO-
to its relative ambiguity and flexibility [7]. Moreover, the rapid 178B and DO-178C is presented by reviewing the basics of DO-
advance in modern software technology has resulted in software 178 verification philosophy, and an overview of the major new
development and verification technologies and methods that were guidance in DO-178C is presented to highlight what has been
not adequately covered in DO-178B, and the effectiveness of changed, along with a description of the impact of DO-178C on
DO-178B has become questionable as the size and complexity of the industry. The remaining sections of the article provide a dis-
modern avionic software increase. For instance, DO-178B makes cussion of the new guidelines in the supplementary documents:
DO-330 to DO-333.

Authors’ current address: Aeronautics Research and Develop-

ment Head Office, Korea Aerospace Research Institute, 169-84 OVERVIEW OF DO-178C
Gwahangno Yuseong-gu, Deajeon 305-806, Republic of South
DO-178C, Software Considerations in Airborne Systems and
Korea, E-mail: wkyoun@kari.re.kr.
Equipment Certification, is a document published in December
Manuscript received May 27, 2014, revised August 20, 2014,
and ready for publication October 12, 2014. 2011 by RTCA, in joint effort with EUROCAE, and officially ap-
DOI. No. 10.1109/MAES.2014.140109. proved in July 2013. RTCA’s SC-205 and EUROCAE’s WG-71
Review handled by W. Walsh. were established to update DO-178B. The membership of SC-
0885/8985/15 $26.00 © 2015 IEEE 205/WG-71 was open to anyone who wished to participate. These

4 IEEE A&E SYSTEMS MAGAZINE APRIL 2015

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- development and verification (DO-331), object-oriented technol-
ments were held in a restricted area available to group members ogy (OOT) and related techniques (DO-332), and formal methods
only. The terms of reference for SC-205/WG-71 can be summa- (DO-333). DO-248C, an updated version of DO-248B, provides a
rized as follows: list of frequently asked questions, discussion papers, and rational
for DO-178C, as shown in Figure 1. These supplements associ-
✓✓Maintain the current objective-based approach for software
ated with DO-178C have been published by the RTCA as stand-
assurance.
alone documents:
✓✓Maintain the technology-independent nature of DO-178B
✓✓DO-248C: Supporting Information for DO-178C and DO-
objectives.
278A
✓✓Maintain backward compatibility with DO-178B.
✓✓DO-330: Software Tool Qualification Considerations
✓✓Address clear errors or inconsistencies and fill any gaps.
✓✓DO-331: Model-Based Development and Verification Sup-
plement to DO-178C and DO-278A
The purpose of DO-178C remains essentially unchanged “to
provide guidelines for the production of software for airborne ✓✓DO-332: Object-Oriented Technology and Related Tech-
systems and equipment that performs its intended function with niques Supplement to DO-178C and DO-278A
a level of confidence in safety that complies with airworthiness
✓✓DO-333: Formal Methods Supplement to DO-178C and
requirements.” DO-178C defines a consensus of the aerospace
DO-278A
industry regarding the approval of airborne software [8].
Overall, DO-178C keeps most of the DO-178B text, but it is Like DO-178B, the design assurance level of DO-178C is es-
not merely an update of DO-178B. The RTCA/EUROCAE joint tablished at the system level using a system safety assessment
committee has produced four development technology supple- process based on the failure conditions associated with the soft-
ments for DO-178C: tool qualification (DO-330), model-based 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- contained in the supplementary documents and discussed in later
sengers: catastrophic, hazardous/severe-major, major, minor, and sections of this article. The subsections here highlight some of the
no effect [11], [12]. DO-178C guidance then determines five as- new guidance contained in the DO-178C core document.
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
GENERAL: GAPS AND CLARIFICATIONS
denoting the lowest level (on which no objectives were set). The DO-178C addresses known issues regarding errors and inconsis-
number of objectives to be satisfied (some with independence) tencies, addressing the errata of DO-178B and removing incon-
is determined by the software level. More detailed information, sistencies across the tables of DO-178B Annex A [8]. Also, DO-
including the safety conditions corresponding to these assurance 178C provides more precise, clearer language and terminology
levels and Federal Aviation Regulation/Joint Aviation Require- standardization throughout the document. In addition, DO-178C
ments (FAR/JAR) failure probability, is given in Table 1. added hyperlinks to the document in Annex A to objectives and
Like DO-178B, coverage of DO-178C refers to the degree life cycle data, for better usability, and the so-called hidden ob-
to which it can be proved that the verification activities cover jective of DO-178B in Annex A (objective 9 of Table A-7 and
all requirements, code structures, and object codes [8]. DO-178C objective 1 of Table A-9). DO-178C address clear gaps in DO-
divides coverage into two types: requirement-based coverage 178B and addresses clarification of the guidance that was subject
and structural coverage. Requirement-based coverage analyzes to differing interpretations in DO-178B [8]. Examples of hidden
the software test cases to confirm that they provide proof that all objectives include the following:
requirements have been satisfied. Structural coverage is met by
✓✓Verification of additional code that cannot be traced to
proving that the test cases execute all code statements and that all
source code is achieved (objective 9 of Table A-7).
data coupling and control paths have been tested.
✓✓Assurance is obtained that software plans and standards
are developed and reviewed for compliance with this docu-
COMPARISONS BETWEEN DO-178B AND DO-178C ment and for consistency (objective 1 of Table A-9).

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

6 IEEE A&E SYSTEMS MAGAZINE APRIL 2015

 Youn et al.

Table 2.

Objective/Independence Allocation of DO-178B/C

DO-178B DO-178C
Software level Change
(objective/independence) (objective/independence)

Level A: 66/25 71/30 +5/5

catastrophic
Level B: hazardous 65/14 69/18 +4/4
Level C: major 57/2 62/5 +5/3
Level D: minor 28/2 26/2 −2/0
Level E: no effect 0 0 No change

Examples of clarifications include the following: sections contained in DO-178C describing the software planning
process, software development process, integral process, and
✓✓Structural coverage analysis of data and control coupling
overall verification activities to be performed are generally the
between code components should be performed by evaluat-
same as those presented in DO-178B.
ing the results of the requirement-based tests (6.4.4.2.c).
The applicant should submit software data produced during
✓✓All tests added to achieve structural coverage are based on the life cycle to demonstrate compliance with DO-178C (summa-
requirements (6.4.4.2.d). 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
✓✓Deactivated code design consideration to the design guid- DO-178C are identical to those of DO-178B except for two new
ance section (5.2.4) and the handling method in one of two life cycle data items. However, there are several distinct life cycle
ways, depending upon its defined category, has been clari- process/data differences. The subsections below highlight some
fied (6.4.4.3.d). of the new or modified guidance associated with software life
cycle process/data.

OBJECTIVES AND ACTIVITIES Supplier Oversight

DO-178C (section 2) uses the same software levels as were used
In DO-178C, the applicant is responsible for oversight of all
in DO-178B. The meaning of these levels is the same from the
of its suppliers who are involved with any of the software life
meaning in DO-178B, as described in the previous section. How-
cycle processes or the outputs of these processes [8]. The soft-
ever, the number of objectives to be satisfied (some with indepen-
ware quality assurance process should provide assurance that
dence) was changed as shown in Table 2: the number of objec-
the process and output of the supplier comply with the approved
tives and independence increases except for Levels D and E.
software plan and standards. DO-178C adds the need to include
DO-178C emphasizes that the full body of DO-178C should
supplier oversight information in the plan for software aspect of
be taken into consideration in order to fully understand the guid-
certification (PSAC; 11.1.h), software configuration management
ance. For example, tables in Annex A now include references to
plan (11.4.e), software quality assurance plan (11.5.g), and soft-
each activity, as well as to each objective, and section 1.4, titled
ware accomplishment summary (11.20.g). Unlike in DO-178C,
How to Use This Document, reinforces that activities are a major
supplier oversight in DO-178B is not clearly defined.
part of the overall guidance. Thus, the applicant should plan and
perform an activity that satisfies the objectives and provides ob-
Parameter Data Item
jective evidence, as listed in section 11, to substantiate that objec-
tives have been satisfied. 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
LIFE CYCLE PROCESS/DATA parameter data items in the same manner as executable object code.
Like DO-178B, DO-178C primarily focuses on the production In DO-178C, parameter data form a data set that influences the be-
processes; it is an evidence-based approach and does not address havior of the software without modifying the executable object
any specific life cycle model [13]. These processes are divided code and is treated as a separate configuration item [8]. The param-
into three categories (Figure 2): a software planning process; a eter data file consists of a form of data that is directly usable by the
software development process, including software requirements, processing unit of the target computer. Parameter data items can
software design, software coding, and integration; and an integral be used to configure the software or provide database information
process, including software verification, software configuration that the executable code can use in execution. Parameter data items
management, quality assurance, and certification liaison. The may contain data that can do the following [8]:

APRIL 2015 IEEE A&E SYSTEMS MAGAZINE 7

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

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

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

 Youn et al.

Table 4. Table 5.

Tool Qualification in DO-178B and DO-178C Tool Qualification Level Determination of DO-178C

DO-178B DO-178C Criteria

Software level
Development tool Criterion 1 1 2 3
Verification tool Criterion 2
Level A TQL-1 TQL-4 TQL-5
Criterion 3
Level B TQL-2 TQL-4 TQL-5
This ensures that orphan source code and dead source code are Level C TQL-3 TQL-5 TQL-5
not inadvertently produced. DO-178C allows an exception to re-
Level D TQL-4 TQL-5 TQL-5
quirement traceability for compilers that produce object code that
is not directly traceable to source code. However, the software
was expanded and separated from DO-178C into a stand-alone
planning process must provide a means to detect this code and
document, DO-330. DO-178C refers the applicant to this tool
ensure its verification.
qualification supplement for specific guidance.
Tool qualification is the process used to gain certification
PRODUCT SERVICE HISTORY credit for a software tool whose output is not verified indepen-
dently when the tool is used to eliminate, automate, or replace
If equivalent safety for the software can be demonstrated by the
processes required by DO-178C in the document [15]. Prior to
use of the product service history of the software, DO-178C pro-
the use of a tool, tool assessment and qualification should be
vides expanded guidance for using product service history as a
performed to ensure the capability of conducting the particular
means to gain certification credit under alternative methods (sec-
development or verification activities to an acceptable level of
tion 12.3). Use of service history data for certification credit is
confidence. The purpose of the tool qualification process is to en-
based on sufficiency, relevance, and types of reported problems
sure that the tool provides a confidence level at least equivalent to
during the service history period. For instance, related software
the one that process eliminated, reduced, or automated.
that has been in service a length of time and whose executable
In DO-178B, tools are classified as either development tools
object code has not been modified in an uncontrolled manner may
(or design tool), which can cause errors into the product, or
be given certification credit.
verification tools, which cannot cause errors but may fail to de-
DO-178C states that the software developer should propose
tect them. DO-178B addressed tool qualification with a simple
the amount of certification credit sought in the PSAC. Although
partition into development tools and verification tools. Unlike
DO-178B states the use of product service history as a means to
DO-178B, in DO-178C, the potential impact of tool use in the
gain certification credit under alternative methods, guidance for
software life cycle process should be assessed to one of five tool
determining the applicability of service history and the length of
qualification levels (TQLs). Tool qualification in DO-178B and
service history needed is not described sufficiently compared to
DO-178C is summarized in Table 4. The following criteria should
DO-178C.
be used to determine the impact of the tool [14]:

1. A tool whose output is part of the airborne software and thus

SUPPLEMENTS could insert an error
As discussed earlier, the revision to the guidance is not limited to
2. A tool that automates the verification process, and thus could
clarification but also includes four new supplementary documents
fail to detect an error, and whose output is used to justify the
to address the state of the art and practice in software technol-
elimination or reduction of either of the following:
ogy. Each technology supplement is objective based and expands
on the objectives in the DO-178C core document for its specific a. Verification process other than that automated by the tool
technology. Each technology supplement describes how the ob-
b. Development process that could have an impact on the
jectives of DO-178C apply, are modified, or are replaced. The
airborne software
following subsections provide a summary of the major new guid-
ance contained in the supplementary documents. 3. A tool that, within the scope of its intended use, could fail to
detect an error
Tool Qualification (DO-330)
Five levels of tool qualification, TQL-1 to TQL-5, are defined
In DO-178C, a software tool is defined as “A computer program based on tool use and its impact in the software life cycle process-
used to help develop, test, analyze, or modify another program es (Table 5). TQL-1 has the most objectives requiring satisfaction
or its documentation. Examples are an automated design tool, a by independence. TQL-2 has fewer objectives requiring indepen-
compiler, test tools, and modification tools” [14]. Due to the in- dent satisfaction compared with TQL-1, but it requires almost the
creasing number of software tools being used and the number of same activities. TQL-3 has fewer activities compared with TQL-
third-party tool manufacturers, the guidance of tool qualification 2 and does not require independence of verification except for

APRIL 2015 IEEE A&E SYSTEMS MAGAZINE 9

Certification of Safety-Critical Avionic Systems

the quality assurance activities. TQL-4 (A special category that create it and to gather evidence that the model is accurate, consis-
has no equivalence to a DO-178C software level) provides less tent, and compatible with all system-level, high-level, and low-
stringent satisfaction of the tool planning process, the tool devel- level requirements [16]. In order to gain certification credit for
opment process, and the verification of outputs. TQL-5 further simulation, DO-331 requires that the applicant clearly show what
relaxes the requirements by requiring no tool development pro- reviews and analyses are needed to satisfy the model verification
cess, verification tool requirement process, integration process, or objectives. The analyses must show that simulation cases exist
testing of tool outputs. for each model requirement and that these simulations address
DO-330 requires that a tool operational requirements (TOR) both normal range and robustness test inputs. Verification of the
document be written to specify the requirements of how the tool executable object code is encouraged to be primarily performed
will be used within the software life cycle. The requirements set by testing in the target computer environment.
forth in the TOR are required to be verified and validated. The DO-331 recommends that software models be developed to
structure and content of DO-330 are similar to those of DO-178C standards that define the modeling techniques, constraints, and
in many respects, but DO-330 has its own set of objectives. DO- instructions used to build the models [16]. The software model
330 also recommends the same software development life cycle standards should specify the methods and tools used to develop
process as those specified in DO-178C but references the TOR the models. In addition, the software model standards should in-
rather than system requirements. The tool requirements are, in clude identification of modeling language to be used and any lan-
turn, developed from the TOR and are then used to develop the guage syntax, semantics, features, and limitations. The software
tool architecture and low-level requirements. The verification of model standards should state the level of traceability between
the tool design process, the tool coding process, and the tool inte- requirements and other life cycle data. The software model stan-
gration process are essentially similar to those presented in DO- dards should also specify any constraints on the use of modeling
178C. Like DO-178C, DO-330 requires bidirectional traceability tools and model supporting libraries.
between requirements and code.
OOT and Related Techniques (DO-332)
Model-Based Development and Verification (DO-331)
The objective of DO-332 was to provide guidance on the use of
In DO-331, a model is defined as follows: “an abstract represen- object-oriented programming languages that use concepts such
tation of a given set of aspect of a system that is used for analy- as inheritance, polymorphism, overloading, type conversions, ex-
sis, verification, simulation, code generation, or any combination ception management, dynamic memory management, virtualiza-
thereof” [16]. DO-331 defines two types of models, specification tion, and other concepts not in common, universal usage at the
models and design models, and it makes a distinction between time DO-178B was developed [17]. The distinguishable feature
requirements for specification models and those for design mod- of OOT is the use of classes to define objects, along with the abil-
els. Specification models represent high-level software require- ity to create new classes via subclassing. In DO-332, a class de-
ments to state the model functional, performance, interface, and fines attributes, methods, relationships, and semantics that share
safety characteristics of a software component. Design models a common structure and behavior representative of a real-world
use primarily low-level requirements and software architecture entity. The main difference between DO-332 and DO-178C can
specifications to represent internal data structures, data flow, be summarized as follows.
and control flow. In either case, DO-331 requires that the mod- In the planning process of DO-332, three activities are add-
els specify the configuration items, modeling techniques, model ed to the DO-178C planning process. First, any planned use of
element libraries, interface descriptions, configuration items, and virtualization and its associated executable program should be
model development environment. Traceability among the design described in the plans. Second, if component reuse is planned,
model, low-level requirements and the model code is required. the plan should explain how the component will be integrated
There should be no model code that cannot be traced back to low- with the new development. Third, the plans and standard should
level requirements. describe how the vulnerabilities (DO-332 Annex OO.D) will be
In DO-331, model coverage analysis is defined as follows: “An addressed.
analysis that determines which requirements expressed by design In the development process of DO-332, some OOT-specific
model were not exercised by verification based on the requirements development guidelines, including class hierarchy, type consis-
from which the design model was developed” [16]. The objective tency, memory management, exception management, and deac-
of model coverage analysis is to discover unintended function and tivated functionality, are added to the DO-178C development
requirements contained in the model that were not exercised by process. For instance, DO-332 recommends that the class hierar-
verification test cases. DO-331 recommends that model coverage chy used should be based on high-level requirements and verified
be shown for all state machine transitions, logic equation decisions, for consistency. A locally type-consistent class hierarchy should
numeric data equivalence classes (and boundary data), and derived be developed with associated low-level requirements wherever
requirements. Model coverage analysis should be performed using substitution of types happens. DO-332 also calls for the software
requirement-based verification test cases. development process to include a plan of strategy for dynamic
In DO-331, model simulation may be used to satisfy some of memory management and exception management. DO-332 states
the DO-331 verification objectives. The purposes of model simu- that bidirectional trace data should exist to show traceability be-
lation are to verify that the model meets the requirements used to tween requirements and methods, since all functionality is imple-

10 IEEE A&E SYSTEMS MAGAZINE APRIL 2015

 Youn et al.

mented in methods in object-oriented programs. In addition, a A formal analysis is “the use of mathematical reasoning to
requirement that traces to a method in a class should also trace to guarantee that properties are always satisfied by a formal model”
the method in its subclasses. [18]. The main differences between DO-178C and DO-333 are in
In the verification process of DO-332, three activities are the area of verification. Since formal analysis has the ability to
added or modified to ensure (1) verification of class hierarchy prove the correctness of a formal model, the review, analysis, and
for consistency with requirements, (2) local type consistency, (3) test objective of DO-178C may be replaced by formal analysis.
verification of the memory management system for consistency For example, DO-333 does not require all requirements of a for-
with the strategy defined in the software architecture, and (4) mal model to be formally expressed. However, if the high-level
verification of the exception management system for consistency requirements and low-level requirements are both formally mod-
with the strategy defined in the software architecture. In addition, eled, the formal analysis can be used to show compliance.
normal-range testing should be performed to ensure “class con- Formal methods were briefly introduced in DO-178B as al-
structors properly initialize the state of their objects and that the ternative methods, but the guidance was somewhat vague and
initial stage is consistent with the requirements for the class” [17]. no explicit provisions were provided. Since formal methods
In DO-332, vulnerabilities analysis (Annex OO.D) should be may find faults that are not detected by testing, formal meth-
address to clarify issues related to the feature of new language ods are complementary to testing. Thus, formal methods can
and to potential complications encountered with satisfying well- increase confidence that no anomalous behavior will occur.
established safety objectives. Vulnerabilities analysis is divided Since formal methods cannot establish verification evidence for
into two categories: key feature and general issues. The vulner- the target hardware, DO-178C still requires software/hardware
ability analysis for key feature includes inheritance, parametric integration testing to be performed to ensure that code works
polymorphism, overloading, type conversion, exception manage- correctly on the target.
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 DISCUSSION
issues that should always be considered regardless of the features
DO-178 is designed to be flexible and allow for various devel-
used in the project. The vulnerability analysis for general issues
opment methods as long as they can show compliance with the
explain how traceability, structural coverage, component usage,
objectives of DO-178. However, DO-178B contains ambiguities
and resource analysis may be complicated by a number of factors
that could be misinterpreted by the applicant due to lack of ap-
inherent in object orientation and provides additional guidance to
plicant understanding. This may result in the applicant failing to
consider when using OOT and related techniques [17].
meet some of the DO-178B objectives. In addition, compliance
with DO-178 guidelines in software development is often consid-
Formal Methods (DO-333)
ered as contributing to the high expense of commercial aviation
DO-333 defines formal methods as “descriptive notations and systems because DO-178 requires rigorously iterative processes
analytical methods used to construct, develop and reason about and extensive documentation throughout the entire software life
mathematical models of system behavior. A formal method is a cycle. Although applicants who have used DO-178B in the past
formal analysis carried out on a formal behavior” [18]. The objec- may still be able to use the same means of compliance for cer-
tive of the supplement is to provide additions to and modification tification projects, upgrading applicants’ process to DO-178C is
of the DO-178C objectives, activities, explanatory text, and soft- highly recommended [20]. New applicants or developers who
ware life cycle data that apply when formal methods are used as are establishing software life cycle processes should do so in
part of the software life cycle. Formal methods are usually only accordance with DO-178C. Thus, it is important to understand
used in the development of safety, business, and mission critical the changes between DO-178B and DO-178C and their effects
software where the cost of faults is high. to effectively manage the processes required by these guidelines,
Formal methods are composed of two types of activities, for- minimize development costs, and ultimately assure the integral
mal modeling and analysis, and they may be applied at various safety of entire avionic systems.
stages in software development and used as a verification tech- Compared to DO-178B, DO-178C and its supplements some-
nique [19]. A formal model is “an abstract representation of a giv- what reduce the extent of this confusion and hence allow a more
en set of aspects of a system that is used for analysis, simulation, consistent approach to developing and certifying safety-critical
code generation, or any combination thereof. A formal model is software. Also, it was demonstrated that the process defined by
a model defined using formal notation” [18]. Formal modeling DO-178C became more clarified and detailed, the average number
represents system abstraction with unambiguous, mathematically of requirements increased, the entire scope was expanded, and the
defined syntax and semantics, and it can be used for analysis, variety of software development methods increased. More spe-
simulation, and code generation. The formal models may be cifically, DO-178C acknowledged that one or more technology-
graphical (e.g., state machine diagrams), differential equations, specific supplements may be used in conjunction with DO-178C
or computer languages. Because formal notations are precise and to modify the guidance for specific techniques. Thus, DO-178C
unambiguous, they can be used to assist verification by helping to provides a more formal, more prescriptive approach for qualify-
show accuracy and consistency in the representation of require- ing formal methods and model-based tools and for verifying the
ments and life cycle data. capabilities of object-oriented languages.

APRIL 2015 IEEE A&E SYSTEMS MAGAZINE 11

Certification of Safety-Critical Avionic Systems

However, there are a number of potential challenges when im- and detailed, the number of requirements increased, the scope
plementing the technology in DO-178C supplements. Although was expanded, and the variety of software development methods
formal methods offer a number of potential benefits, including an increased.
improved requirements definition, reduced errors, and maintain- Although it was impossible to provide every detail of DO-
able software, formal methods have rarely been used in the civil 178C within the scope of this article, it is hoped that the compre-
aviation field due to their limitations [21]. For instance, formal hensive information herein, along with a description of the impact
methods are not applicable to all problems, and there are still of DO-178C, will help applicant to reduce potential compliance
many project-by-project issues to be solved. Furthermore, it can problems, minimize development costs, and ultimately assure the
be highly challenging to combine formal and traditional nonfor- integral safety of avionic systems. The reader requiring specific
mal methods in one project. Thus, DO-331, of all DO-178C sup- information must download these documents from RTCA in order
plements, will likely be the most challenging to apply, especially to fully appreciate and apply the new guidance.
when trying to apply the guidance to existing models. Likewise, To the best of our knowledge, there have been a few stud-
OOT and model-based development and verification technology ies exploring software and hardware guidelines [9], [10], but few
are appealing technology to the aviation industry for several rea- studies have reviewed the similarities and differences between
sons, including strong tool support, availability of programmers, DO-178B and DO-178C or described the impact of DO-178C on
perceived cost savings, and potential for reusability, but they have the industry. Therefore, this study has significant implications in
not been extensively used in aviation fields to date due to limita- terms of demonstrating an overview of and the similarities and
tions not seen with the traditional techniques. Above all, there differences between DO-178B and DO-178C, along with the im-
is no abundance of the technology among DO-178C supplement pacts of DO-178C; this article may serve as a useful entry point
practitioners, so this can be a barrier to successful use of the tech- for those unfamiliar with DO-178C to understand the rationale
niques. and clues behind this new certification guidance for airborne soft-
Therefore, implementing a new technology described in DO- ware certification.
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
REFERENCES
is still relatively new in the aviation field, the certification author- [1] Software Considerations in Airborne Systems and Equipment Certifi-
ity will be more cautious with any new technology and tend to cation. RTCA document DO-178B, 1992.
oversee it closely. It is the responsibility of the applicant to ensure [2] Dodd, I., and Habli, I. Safety certification of airborne software: an
that a supplement’s use is acceptable to the appropriate certifica- empirical study. Reliability Engineering & System Safety (2011).
tion authority. Therefore, coordination should be established with [3] Kornecki, A., and Zalewski, J. Software certification for safety-critical
the certification authority as early as possible to gain agreement systems: A status report. In Proceedings of the IEEE, 2008, 665–672.
on the means of compliance for successful certification. Never- [4] Holloway, C. Towards understanding the DO-178C/ED-12C assur-
theless, the new technology described in DO-178C supplements ance case.
offers a number of potential benefits, as discussed above, so a [5] Daniels, D. Thoughts from the DO-178C committee. In Proceedings
number of applicants have recently initiated their project by using of the 6th IET International Conference on System Safety, 2011, 1–7.
the technology in the supplements and have received the certifica- [6] Youn, W., and Yi, B.-J. Software and hardware certification of safety-
tion credit. As experience and the technology mature, the benefits critical avionic systems: a comparison study. Computer Standards &
will likely increase. In addition, it can be expected that as the Interfaces, Vol. 36 (2014), 889–898.
use of software increases, technology evolves, and experience is [7] Kornecki, A., and Zalewski, J. Certification of software for real-time
gained in the application of DO-178C and its supplements, there safety-critical systems: state of the art. Innovations in Systems and
may be some additional certification authority guidelines in the Software Engineering, Vol. 5 (2009), 149–161.
near future to clarify development and verification issues. [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
CONCLUSION safety-critical systems: state of the art. Annual Reviews in Control,
This article provides a practitioner’s comprehensive view of the Vol. 34 (2010), 163–174.
new DO-178C standard and its supplements. The aim of this [10] Hesselink, H. A comparison of standards for software engineering
article is to help those unfamiliar with DO-178C to gain clear based on DO-178B for certification of avionics systems. Microproces-
understanding of the scope of the information contained in the sors and Microsystems, Vol. 19 (1995), 559–563.
nearly 1,000 pages. The similarities and differences between [11] Guidelines for Development of Civil Aircraft and Systems. SAE Inter-
DO-178B and DO-178C, along with the related supplementary national document ARP4754A, 2010.
documents, have been extensively described in various aspects. [12] Guidelines and Methods for Conducting the Safety Assessment Pro-
This article also describes how they will affect the applicant’s cess on Civil Airborne Systems and Equipment. SAE International
organization, focusing on the practical implications of the many document ARP4761, 1996.
changes between DO-178B and DO-178C. It can be summarized [13] Yan, F. Comparison of means of compliance for onboard software cer-
that the process defined by the standards became more clarified tification. In Proceedings of the IEEE, 2009, 917–920.

12 IEEE A&E SYSTEMS MAGAZINE APRIL 2015

 Youn et al.

[14] Software Tool Qualification Considerations. RTCA document DO- [18] Formal Methods Supplement to DO-178C and DO-278A. RTCA doc-
330, 2011. ument DO-333, 2011.
[15] Kornecki, A., Butka, B., and Zalewski, J. Software tools for safety- [19] Gigante, G., and Pascarella, D. Formal methods in avionic software
critical systems according to DO-254. Computer, Vol. 41 (2008), certification: the DO-178C perspective. In Leveraging Applications of
112–115. Formal Methods, Verification and Validation. Applications and Case
[16] Model-Based Development and Verification Supplement to DO-178C Studies. Springer, 2012, 205–215.
and DO-278A. RTCA document DO-331, 2011. [20] Airborne Software Assurance. FAA document AC 20-115C, 2013.
[17] Object-Oriented Technology and Related Techniques Supplement to [21] Rierson, L. Developing Safety Critical Software. Boca Raton, FL:
DO-178C and DO-278A. RTCA document DO-332, 2011. CRC Press, 2013.

APRIL 2015 IEEE A&E SYSTEMS MAGAZINE 13

View publication stats