Integrating an assurance case into DO-178B compliant software development

Full text

1
INTEGRATING AN ASSURANCE CASE INTO DO-178B COMPLIANT
SOFTWARE DEVELOPMENT
John Knight, Jonathan Rowanhill, Dependable Computing, Charlottesville, VA
Uma Ferrell, Ferrell And Associates, Charlottesville, VA
Alec Bateman, Neha Gandhi, Barron Associates, Charlottesville, VA
Abstract
Software assurance in the aviation industry is
closely tied to compliance with RTCA DO-178B. In
this paper, we introduce an approach to enhancing the
value of DO-178B using a software assurance case.
The heart of the approach is to use an assurance case
to link the detailed development techniques chosen
by developers to the objectives defined in the
guidance in a rigorous way. The assurance case
documents precisely and explicitly the developers’
rationale for stating that the objectives have been
satisfied. The use of an assurance case has three
major advantages: (1) the contributions to assurance
of the technologies used in development are
documented and can be examined to determine
weaknesses and omissions, (2) the system’s
stakeholders can scrutinize the assurance case to
assess completeness of software assurance, and (3)
auditors can guide their analyses of the subject
system using the assurance case. We present details
of the approach and illustrate the approach by
applying it to the planning phase of DO-178B. We
show how savings elsewhere in development yielded
by the enhancement approach can accommodate the
cost of the assurance case itself.
The approach can be adapted easily to DO-
178C.
Introduction
Assurance in software development in the
aviation industry is closely tied to RTCA DO-178
compliance [1]. Combined with the approval audit
functions, DO-178 provides a wealth of technical
information and indicators of potential problems in
development of software using an objective based
system.
Even with the release of DO-178C and the FAA
Advisory Circular 20-115C that codifies DO-178C
and cancels the use of DO-178B for future projects,
DO-178B is being used on projects for which the
approval basis was set before the release of DO-
178C. DO-178B is also being used on projects that
meet specific criteria per AC 20-115C. Further, the
research reported in this paper was conducted to
determine the possible use of a software assurance
case to support approval with DO-178B, and the
results can easily be adapted to DO-178C.
To date, the use of rigorous software assurance
cases in the industry has been negligible. This
situation is understandable, because the general use
of software assurance cases could be quite disruptive
to the established software development and approval
cycle. In this paper we present an approach to
integrating an assurance case into software
development intended to be approved based on the
DO-178B guidelines and discuss the various
advantages of doing so. The intent of this approach is
to enhance the value of the objective based
compliance to focus on the goal of software
assurance. Such an approach could be extended to
develop alternate means of compliance where
specific objectives cannot be satisfied using
conventional methods as new tools, techniques,
methodologies and architectures are introduced in
both software and processor engineering.
The heart of the approach is to use an assurance
case to link the detailed development techniques
chosen by developers to the objectives defined in the
guidance in a rigorous way. Using the enhanced
approach, developers document precisely and
explicitly the rationale for their opinion that the
objectives have been satisfied. The assurance case
includes an argument that explains why the evidence,
either planned or generated, leads to their opinion
that the objectives have been met.
The use of an assurance case in this manner has
three major advantages:
• By both building and reviewing the assurance
case, developers can see the role of the
development technologies that they have chosen

2
and determine whether those technologies are the
best for the associated product. The resulting
emphasis is on engineering to support
compliance rather than compliance to support
engineering.
• All of the system’s stakeholders can scrutinize
the assurance case. As a result, stakeholders can
gain confidence that the objectives have been met
adequately and verify that activities appropriate
for the technology choices have been undertaken.
• Reviewers can guide their analysis of the subject
system using the assurance case. Without the
reasoning documented in an assurance case,
reviewers sometimes have to review a set of
activities that can be a “force fit” to the DO-178B
guidance.
We present details of the approach and illustrate
the approach by applying it to the planning phase of
DO-178B. Along with several other items, a planning
review requires preparation of the Plan for the
Software Aspects of Certification (PSAC). We show
how the required elements of the PSAC along with
the associated plans and development standards are
motivated by the structure and content of the
assurance case. We also show how the plans and
associated assurance case allow appropriate project
resources to be assigned and justified. Finally, we
show how the cost of the assurance case itself can be
accommodated by savings elsewhere.
DO-178B Guidance
The DO-178B guidance defines a set of 66
objectives at the highest level of software criticality
(level A). At lower levels of criticality, a subset of
the objectives needs to be satisfied for compliance.
Some objectives at higher software levels have to be
satisfied by independence. Two data control
categories prescribe configuration management
procedures for lifecycle data; some lifecycle data at
all levels require lower level of control and more data
at lower levels require lower levels of control. The
guidance does not provide a comprehensive rationale
for the objectives, independence or the control
categories.
The guidance does not prescribe technical
approaches to satisfying the objectives, although
examples are provided that illustrate activities to
support an objective. Determination of whether the
objectives have been met rests largely with
developers’ reviews, quality-assurance audits, and
certification liaison audits (see below).
The guidance is based on the principle of
correctness by construction. Applicants first plan the
technical approach that cover appropriate and
relevant engineering that would provide evidence of
regulatory compliance. Applicants (software
developers) follow these plans and processes
including conduct of reviews to support correctness
of software as well as compliance. The applicant’s
quality-assurance engineers have the responsibility of
making sure that the plans for the project comply
with applicable regulations, and the developers
follow the agreed upon plans. The applicable
regulations often differ from project to project,
because the regulations depend upon the engineering
activities required to support the selected
development techniques and methods as well as any
contractual obligations.
The FAA provides substantial additional
information including a Job Aid for software reviews
(audits) by the FAA or a designated engineer who
will act as the certification liaison for the project [3].
Concerning the objectives for the software
planning process, for example, the guidance states:
“Reviews and assurance of the software
planning process are conducted to ensure that
the software plans and software development
standards comply with the guidelines of this
document and means are provided to execute
them.”
This text refers to the applicant’s responsibilities
for peer and quality-assurance reviews. The word
“review” is overloaded in DO-178B, and in the Job
Aid. DO-178B is referring mostly to the applicant’s
peer review and quality-assurance activities, but
software reviews referenced in the Job Aid are audit
activities conducted on behalf of the certification
authority. Software development artifacts to be
supplied by the applicant to support these reviews are
discussed in section 9 of DO-178B. The meaning of
the word “review” must be determined by the context
in which the word is used.
An important class of auditors, referred to as
certification liaisons, maintain independence from
the artifacts and products being reviewed. The role of
a certification liaison is to examine development
artifacts and interact with developers in various ways

3
and at various times in what in known as Stage of
Involvement (SOI) audit. The FAA’s Job Aid
provides substantial additional information for
software reviews (audits) by the FAA or a designated
engineer who will act as the certification liaison for
the project [3]. Concerning the role of review (audit),
the Job Aid states:
“The purpose of the software review is to
assess whether or not the software developed
for a project complies with the applicable
objectives of RTCA/DO-178B, Software
Considerations in Airborne Systems and
Equipment Certification...”
The guidance does not prescribe specific review
activities. The Job Aid states:
“This Job Aid should be used as a reference
tool during the software review process. It is
not intended to be used as a checklist and is
not all inclusive of all possible situations that
need to be reviewed. Nor is the Job Aid
intended to replace DO-178B—it should be
used in conjunction with DO-178B. Likewise,
this Job Aid may include questions that are not
appropriate for the specific project being
evaluated. Reviewers should keep in mind that
each software project has some unique
characteristics and should use the Job Aid as
best fits the specific situation.”
The inevitable variance between different
systems is accommodated by the apparent flexibility
in the guidance and the associated Job Aid. But the
unavoidable result is the need for auditors to elicit a
variety of information about why the various
development technologies were chosen, how the
technologies were applied, and how developers can
be confident that the technologies were applied
correctly. The use of a software assurance case deals
with these issues and provides additional benefits.
RTCA has published an instructional document,
DO-248B [5], that explains concepts within DO-
178B, and the Certification Authorities Software
Team (CAST) [6] has published a number of
technical papers on issues that needed additional
explanations and opinions from the certification
authority. A variety of technical papers have been
released as a result of research activities funded by
the regulatory authority [7]. Privately funded entities,
such as the Aerospace Vehicle Systems Institute
(AVSI), have published research results that are open
to only its membership [8]. Many papers published
by NASA are publicly available. None of this
published information is binding, but most
developers and regulators tend to treat them as such.
There are a number of FAA Orders that guide
the FAA and the certification liaison on the
perspectives on technical issues that must be used
during the SOI audits.
While all of these reference materials and FAA
Orders offer help, the developer is responsible for
assembling the engineering activities relevant to the
project and demonstrating adequate evidence to
prove compliance. Use of an assurance case provides
a framework for the presentation of a holistic
interconnected set of engineering activities and
accompanying data.
Figure 1. The major elements of an assurance case.
Software Assurance Cases
Assurance Case Structure
A software assurance case is a variant of a
safety case. The U.K. Ministry of Defence defines a
safety case as [2]:
The Safety Case shall consist of a structured
argument, supported by a body of evidence
that provides a compelling, comprehensible
and valid case that a system is safe for a given
application in a given environment.
A software assurance case uses a rigorous
argument and various items of evidence to document
Assurance
Claim
Context Within
Which Claim Is
Made
Body of Evidence About System Including Details
Of Development, Analysis, Testing, Etc.
Assumptions
Made About
The System
Rigorous Argument
Linking Body of Evidence
to Safety Claim

4
the rationale for opinions that a software item meets a
required goal, for example that the software is
adequately dependable for its intended application.
The major elements of a software assurance case
are shown in Figure 1. The desired software property
is stated as a goal that is required to be true within
the relevant system context and with a set of explicit
assumptions. To justify confidence in the goal, an
explicit rigorous argument documents how the goal
follows from a body of evidence about the subject
system, including the results of analysis of the system
and details of how the system was developed.
Example Argument
Although the concepts in a software assurance
case might be unfamiliar, many of the elements of
such a case are always present in every development
intended to be compliant with DO-178B guidance.
For example, there is always an implicit assurance
goal that developers are trying to meet, system
context documents, and assumptions. Development
activities are motivated by: (a) the assurance goal
(software correctness), and (b) details of the subject
systems. Thus, developers have an “argument” that
“explains” why they think the assurance goal will be
met by satisfaction of objectives through specific
activities.
The main differences between the status quo and
an assurance case are that, in current practice,
arguments are informal, implicit and not documented
(i.e., they remain in the minds of the engineers), and
ad hoc. The current objective-based framework
focuses on the evidence needed to pass the regulatory
audits rather than questioning the engineering needed
to reach the requisite level of software assurance. An
explicit rigorous argument records the engineers
reasoning in a manner that is systematic and open for
review. Skeptical review of the argument enables
debate about whether the reasoning is valid and
complete.
As an example of an explicit argument, consider
a goal of assuring that the fixed-point computations
in a single source-code function will not overflow in
operation. Developers might undertake a variety of
analyses to establish this goal. The role of the explicit
argument is to document the reasons that the
developers have for thinking that the goal will be met
using the analysis they selected. Analysis might
include static analysis of the source code, unit testing
based on identified ranges of values of the
parameters, and a code inspection. The argument,
however, has to address the question:
Does the set of analyses that were undertaken
address all known circumstances that might
cause overflow and hence be considered
sufficient to warrant approval of compliance
with the guidance?
Answering this question requires examination of
the performance specifications of the analysis
techniques, checking to make sure that there are no
errata to the specifications, and coupling the results
of the analyses together to make sure that all of the
source code was covered and all of the parameter
values were covered.
Dealing with this question often raises additional
questions that must be answered and for which the
answers then become part of the argument. Other
questions that might arise include:
• How were the analysis tool and techniques
applied and were they applied correctly? A
mistake in applying a tool could lead to a
problem being missed.
• How were the ranges of values used for the
parameters determined and were the values
used correct? Could other values arise
because of unexpected circumstances in
the calling function?
• Would additional tests derived from edge
cases reveal unusual circumstances that
could arise that have not been covered by
other tests? If so why, and if not why not?
These questions do not cover the assurance issue
fully, because they do not address the wider issue of
process completeness and necessary documentation.
To complete the assurance picture in a manner that
the guidance and the FAA intend, other questions that
arise include:
• How did the developers ensure that the
analysis was fully consistent with the plan
as defined in the planning documents and
has the reasoning for that consistency been
documented fully?
• How did the developers ensure that the
verification analysis was consistent with
the associated development activities and

5
has the reasoning for that consistency been
documented fully?
• How did the developers ensure that the
results of the analyses and all the process
elements were integrated correctly into the
documentation to be supplied to the
auditor and has the reasoning for that
integration been documented fully?
Combining the answers to the original and all of
these derived questions into an explicit statement
brings together the reasoning behind the developers
statement that the goal has been met, i.e., an explicit
argument that the goal has been met.
The explicit argument is precisely what is
needed for an audit. In existing practice, the auditor is
presented with the results of analyses but not the
reasoning behind the use of the analyses. The auditor
is then forced to recreate the argument behind the
supplied analysis as part of the audit. Doing so is
tedious, time consuming and likely error prone.
Advantages of An Assurance Case
The fundamental promise of a software
assurance case is that the rationale for confidence in
the assurance goal is presented explicitly and so can
be subject to scrutiny. Scrutiny, if applied carefully,
provides one of the best ways presently known to
identify engineering defects in safety-critical
systems. Scrutiny permits each stakeholder to ask a
variety of questions about the system and the
software assurance goal:
• Independent engineers can review the
assurance case skeptically seeking possible
flaws.
• Development engineers can base
systematic reviews on the assurance case
and check their own opinion that the
development process has created software
with adequate dependability.
• Reviewers can use the assurance case as a
“map” showing all of the evidence and
how that evidence is used.
• Regulators can examine the assurance case
and use the case to support the approval
process.
Figure 2. Structure of assurance case for objectives
An Assurance Case For Objectives
Annex A of DO-178B in which the objectives
are listed is not a checklist. The objectives identify
properties that should be present in any software
system development that is compliant. Behind the
objectives is the intent of the guidance. The intent of
the guidance is to ensure that a compliant software
system development will result in a software entity
whose dependability meet the needs of the avionics
system of which the software entity is a part.
The concept of an assurance case for objectives
is to supplement the materials normally supplied by
developers with an assurance case that: (a)
documents explicitly the reasons that the developers
have for claiming that the intent will be met, and (b)
organizes that supplement in a systematic way. The
goal is to provide all stakeholders with a clear
statement of the developers’ rationale.
An assurance case for objectives is tailored to a
specific purpose and has a particular structure that is
determined by the intent of the guidance, the
associated objectives, and the role of the assurance
case. The general concept is illustrated in Figure 2.
The top-level goal in the assurance case is that
the intent of the guidance has been met. The
argument and body of evidence document the
developers’ reasons for stating that the intent has
been met.
The context defines all of the materials upon
which the assurance case depends. The context does
not contain anything unusual. The role of context in
this structure is to define the terminology, concepts
Objectives
Objectives
The Intent Of
The Guidance
Is Met
Intent Of Guidance
System Details
Process Details
Operational Details
Assumptions
FARs & Guidance
Approval Requ's
Body of Evidence
Rigorous
Argument
Context Goal
Objectives
Inference
Annex A

6
and scope of the assurance case in detail and in a
fixed, prescribed location.
A crucial element of the context is a precise
definition of the intent of the guidance. This
definition must be sufficiently clear and precise that
the question of whether it has been met can be stated
as a testable proposition, i.e., a statement that can
only be true or false. In addition, all of the relevant
documents or other reference sources are cited along
with any documents that supplement and help explain
the guidance. More specifically, the context includes:
• Definition of the intent.
• Detailed description of the application
system.
• Details of the development process.
• Details of the planned operational
environment.
• Assumptions that have to be made.
• FARs and guidance including DO-178B.
• Approval requirements.
Since the objectives in Annex A of DO-178B
are statements of properties that should be present in
a software system development that is compliant, a
specific development must be shown to have these
properties. With the assurance case documenting the
developers’ reasons for stating that the intent is met,
the necessary reasoning to justify meeting the
objectives will be contained in the assurance case.
Inferring that the objectives are met is
straightforward in such circumstances.
Development of the assurance case for
objectives begins prior to commencement of the
development of the system. At that stage, the
assurance case might be partially incomplete, because
some development choices might not be made until
development is underway. The assurance case might
also be incorrect in the sense that certain items of
evidence might turn out to be inappropriate,
insufficient, or not necessary. Proceeding in this
manner, however, allows the assurance case to
provide a focus project planning. The potential
incompleteness of the assurance case indicates where
further development decisions need to be made, and
the overall structure of the assurance case provides
both input to planning and input to developing
confidence that no critical steps have been omitted.
Assurance Case Support For Review
Current Review Practice
The FAA Job Aid lays out a framework of four
Stage of Involvement audits that are conducted at
specific time periods during the development process
in order to identify any problems in the applicant’s
process and products. The applicant can see the
intent to be met and the associated objectives in DO-
178B and work towards activities, evidence and an
argument that satisfies the goal holistically. For
example, the goal of a Stage of Involvement audit is
to ascertain whether the intent of the guidance is met;
not just to just conduct a review, but to conduct the
review to make sure that any problems in the artifact
under review are addressed whether or not the
problem fits into the perceived realm of the explicit
objectives.
Clearly, there is a requirement to ensure that a
problem once found is tracked and resolved. Sound
engineering practice dictates that problems are
tracked using comprehensive configuration control
from the outset of development in order to show that
the intent of the guidance is met no matter when they
are found.
For all four of the Stage of Involvement audits,
but especially for first audit (planning), existing uses
of DO-178B place a broad and substantial burden on
the audit process and hence on the auditor. For the
planning audit in particular, the auditor has to review
a wealth of documentation and try to distill the
reasons why the developers think that the plan meets
the intent of the guidance. In essence, this distillation
process corresponds to recreating to the extent
possible the reasoning that the developers had in
mind for the inclusion of the process steps and
evidence artifacts in the PSAC. In other words, the
auditor is forced to recover the development team’s
implicit argument; an argument that the team had but
did not write down.
Once the auditor has recovered the developers’
argument, the auditor has to assess the PSAC and the
recovered argument in order to locate any
weaknesses or deficiencies in the plan.
As should be clear at this point, the use of an
assurance case prepared by the development team
would facilitate, streamline, and simplify the audit
process considerably by eliminating the argument

7
distillation step. In effect, the explicit argument that
the development team prepares becomes a “road
map” of the team’s reasoning. The audit process can
proceed in a sequence of stages determined by the
structure of the supplied argument.
Review Based On An Assurance Case
The fundamental goal underlying DO-178B is
for an applicant to demonstrate that the translation of
the requirements to an implementation is correct and
complete. The applicant is expected to:
• Take steps to avoid any errors that may be
introduced into the overall development
process.
• Find, track, and resolve errors found
during the development process.
• Assess any known unresolved problems
for safety and operational limitations and
resolve if necessary.
• Assure that:
as-specified = as-built,
as built = as-verified, and
as verified = as-delivered.
The reasoning underlying the Stage of
Involvement audits creates an environment of
“common language” between the regulator and the
applicant. Further, this common understanding
motivates different regulators to review an
applicant’s materials from similar perspectives while
maintaining the advantage of individual skeptical
examination of the evidence with different technical
reasoning.
The introduction of an assurance case for
objectives provides a comprehensive and regular
structure within which the common language,
common understanding, and similarity of
perspectives can be codified. The consistency of
representation provides convenient access to the
materials without imposing any restrictions on the
individuality or skepticism of the reviews.
Representing Rigorous Arguments
Various mechanisms have been developed for
documenting rigorous arguments. In this paper, we
use the Goal Structuring Notation (GSN) [4]. GSN is
a commonly used graphic notation that structures
arguments by recursive decomposition of high-level
goals using decomposition strategies through layers
of refinement to low-level goals that can be
established with one or more items of evidence
thereby terminating decomposition. An argument in
GSN includes explicit references to the target
system’s context, assumptions, related
documentation, and documentation of evidence
thereby tying all of the components together.
Figure 3. Overview of GSN
Figure 3 summarizes the primary elements of the
GSN graphic notation. The hierarchic decomposition
of goals is represented vertically. The set of subgoals
that result from the decomposition of a goal are
represented horizontally. The strategies are placed
between a goal and the associated set of subgoals.
6.2: Evidence
Reason for stating that
subsubgoal 2 is true
5.2: Subsubgoal 2
Decomposition of subgoal 2
6.1: Evidence
Reason for stating that
subsubgoal 1 is true
5.1: Subsubgoal 1
Decomposition of subgoal 1
4.2: Strategy
Reason why truth of subsubgoals
1-2 infer truth of subgoal 2
3.2: Subgoal 2
Decomposition of top-level goal
4.1: Evidence
Reason for stating that subgoal 1 is true
3.1: Subgoal 1
Decomposition of top-level goal
2.1: Strategy
Reason why truth of subgoals 1-2
infer truth of the top-level goal
1.2: Context
References to relevant
elements of context
1.1: Top-Level Goal
Guidance intent

8
The dot-separated integers on each node are to allow
convenient identification of nodes in explanatory
text.
Representation of arguments in GSN provides
several advantages including provision of:
• A uniform, standardized notation
permitting consistent communication of
arguments.
• A well-defined and accessible structure for
the overall argument that supports detailed
scrutiny and analysis of the argument.
• Complete explicit representation of
essential content.
• A structure within which various forms of
quantification can be described and
analyzed with dependencies documented
explicitly in the graph structure of the goal
decomposition.
Resource Requirements
Concerns over the cost of compliance with DO-
178B have been expressed, and the introduction of a
new artifact as we propose seems likely to increase
the cost. With careful planning and the use of
assurance case templates and other assets, the cost of
developing the assurance case is modest.
The use of a software assurance case can result
in substantial cost savings over the lifecycle of the
software. As well as the advantages noted earlier,
resources could be saved in three different ways:
• Using the assurance case as a focus for
planning enables unnecessary development
activities to be detected and eliminated at
the planning stage.
• Preparation for and conduct of all of the
necessary reviews (audits) can be
extremely efficiently.
• Some rework can be eliminated because
the reasons motivating the various
development activities are documented in
the assurance case prior to undertaking
those activities. Combined with
appropriate reviews, the assurance case
allows defects in planned development to
be detected before the plan is executed.
These three opportunities for saving
development resources do not guarantee that the use
of an assurance case will be cost effective. Anecdotal
evidence from a wide variety of Stage of
Involvement audits conducted by one of the authors
(Ferrell) suggests that resource savings could be
substantial.
Argument Applied To Planning
In this section, we present an illustrative
example of a simple assurance case for objectives. To
keep the length of this paper within the publication
limit, we restrict the discussion to the planning
aspects of the guidance, i.e., Annex A, Table A-1.
We further restrict the discussion to the assurance
argument since that is the least familiar element of an
assurance case.
Arguments documented in GSN are often large
structures. For convenience, in this example the
argument is partly summarized in natural language
and partly presented in fragments.
Figure 4. Top-level goal, contexts and strategy
Annex A, Table A-1 lists seven objectives and
four outputs. The outputs required are a plan for
development of the subject software entity, i.e., the
PSAC. The intent of the guidance for the PSAC is
that, if executed fully as specified, the plan will lead
to a software entity that could be approved.
Early preparation and documentation of the
PSAC and conduct of the associated audit is a risk-
reduction strategy. If development proceeded without
an audited plan, the developers might go down a path
3.2: Process
Plan to monitor process, and
seek and repair defects complete
3.1: System Requirements
Plan to derive software
requirements from system
requirements complete and correct
2.1: PSAC Sections
Argument over development phases
1.5: Intent
Definition of DO-178B intent for PSAC
1.4: Guidance
DO-178B, DO-248, relevant CAST
papers, relevant supplements
1.3: FARs
Applicable Federal Aviation
Regulations
1.2: System
Application system documentation
1.1: PSAC
PSAC will yield a software system
that meets the intent of DO-178B

9
that has no chance of yielding a software entity that
has the quality necessary for approval.
Figure 4 shows the top of the assurance
argument, specifically:
• Top-level goal. The goal states the intent
that the PSAC defines a plan, which if
executed completely and correctly, will
lead to a system that could be approved.
• Some of the items of context. The context
elements displayed in the GSN structure
will define and link to the associated
detailed documents. Other contexts will be
needed, and part of the process of
developing the argument is to assure that
all of the necessary context items are
explicitly referenced.
• Top-level decomposition strategy. The
top-level goal has to be decomposed into a
set of subgoals that taken together with the
strategy imply the top-level goal.
The decomposition strategy indicates the
subgoals that will become the decomposition. These
subgoals, if true should imply the truth of the top-
level goal. The idea of the decomposition is to
determine a set of “simpler” goals that can be
addressed separately. Without undertaking this
decomposition, forming a credible opinion about the
top-level goal would be an impossible intellectual
challenge.
In this planning example, the strategy that has
been selected is to break the top-level goal down into
subgoals based on the various phases that are defined
for the PSAC: (1) software development plan, (2)
software verification plan, (3) software configuration
management plan, and (4) software quality assurance
plan. The idea is to claim that if reasons are given for
forming the opinion that each of these subplans will
contribute properly to the top-level goal then an
opinion that the top-level goal (intent) is met is valid.
A little experience with using the DO-178B
guidance reveals that this idea is wrong! These four
subplans: (a) must be properly coordinated, and (b)
must accommodate changes that arise during
development. Coordination is required between the
development and verification subplans, for example,
to ensure that these subplans are defined for precisely
the same artifacts. Unless additional reasons are
included in the argument for opinions that these two
further issues are dealt with, an opinion that the top-
level goal is met would be invalid.
Thus, to complete the decomposition of the top-
level goal in a credible way, two additional subgoals
are needed: (5) the subplans are properly coordinated,
and (6) the subplans accommodate the necessary
synchronization, assessment and update of the
subplans when changes become necessary.
The next step in the development of the
argument is to undertake a second decomposition
step in which each of these now six subgoals is
decomposed into simpler goals. As they stand, none
of the six could be considered sufficiently simple that
an opinion could be formed based on evidence alone.
The challenge in decomposition is to determine
just what subgoals provide the right refinement of a
goal. Consider as an example the subgoal of proper
coordination between the development and
verification subplans. How could one justify an
opinion that this subgoal is met?
The solution is to turn to the process elements
that developers might undertake. By doing so, not
only can a credible decomposition be reached in this
circumstance, but the decomposition also leads to
subgoals that are clear and simple enough to be
justified immediately with evidence. The key to
coordination is ensuring that the necessary elements
required for coordination are defined and that their
proper execution will be undertaken, monitored, and
recorded.
Figure 5 shows an initial decomposition.
Subgoal 3.1 essential states that all the necessary
management artifacts are properly defined. Subgoal
3.2 essentially states that the necessary meetings of
managers and developers have been properly defined.
Both of these subgoals become part of the
evolving plan, i.e., the plan needed to ensure proper
coordination will include these entities. During actual
development, evidence will need to be generated
confirming that the subgoals are justified.
Again, however, this decomposition is wrong,
or, more accurately, incomplete. Having an opinion
that proper coordination is achieved between
development and verification is not justified by the
subgoals 3.1 and 3.2. Based on this simple
decomposition, there is no reason to think that the
development team and the verification team are

10
working with identical definitions of the entities
being developed and verified nor that the verification
requirements are documented and understood
identically.
Figure 5. Decomposition of coordination subgoal
Adding additional subgoals to address the need
for these (and possibly other) argument elements is
straightforward. The benefit of explicit
documentation of the reasons for having opinions that
various goals have been met should be clear. The
explicit argument presented in a clear and concise
way enables engineers to examine their reasons for
having what amount to crucial opinions. There is no
guarantee that defects in arguments will be identified,
but making the argument explicit facilitates detection
of argument defects, i.e., believing false opinions.
Conclusion
We have introduced an approach to enhancing
the value of DO-178B using a software assurance
case. The principal role of the approach is to use an
assurance case to link the detailed development
techniques chosen by developers to the objectives
defined in the guidance in a rigorous way. The
assurance case documents precisely and explicitly the
developers’ reasons for stating that the objectives
have been satisfied. The assurance case realizes four
significant advantages: (1) the assurance case can
contribute to project planning, (2) role of selected
development technologies can be examined to
determine weaknesses and omissions, (3)
stakeholders can scrutinize the assurance case to
assess completeness of software assurance, and (4)
reviews can be more effective and efficient. Despite
the requirement to prepare a new artifact during
software development, the savings resulting from the
assurance case can offset the cost of the assurance
case itself.
References
1. Software Considerations In Airborne Systems
and Equipment Certification, DO-178B, RTCA,
Inc., Washington DC (1992)
2. U.K. Ministry of Defence, Safety Management
Requirements for Defence Systems Defence
Standard 00-56 (June 2007)
3. FAA Aircraft Certification Service, Conducting
Software Reviews – Job Aid, Rev 1, FAA,
Washington DC (2004)
4. Weaver, R. and T. Kelly. The Goal Structuring
Notation - A Safety Argument Notation,
Workshop on Assurance Cases, Florence, Italy
(2004)
5. Final Report For Clarification of DO-178B
“Software Considerations In Airborne Systems
and Equipment Certification” DO-248B, RTCA,
Inc., Washington DC (2001)
6. http://www.faa.gov/aircraft/air_cert/design_appro
vals/air_software/cast/cast_papers/?print=go
accessed on August 8th, 2015
7. https://www.faa.gov/aircraft/air_cert/design_appr
ovals/air_software/research/ accessed on August
10th, 2015
8. http://www.avsi.aero/research/past_projects.HT
ML accessed on August 10th, 2015
Acknowledgments
This work was supported in part by NASA
Contract NNL13AA08C.
34th Digital Avionics Systems Conference
September 13-17, 2015
3.2: Meetings
Correct set of management meetings
defined and conducted correctly
3.1: Artifacts
Set of development artifacts
is correct and complete
2.1: Management
Argue over management entities
1.1: Coordination
Development and verification
subplans are properly coordinated