International Journal of Computer Systems (ISSN: 2394-1065), Volume 03 Issue 02, February, 2016

Available at http://www.ijcsonline.com/

Software Safety in Aviation Industry

Kadupukotla Satish Kumar A and Panchumarthy Seetha RamaiahB

Dept of Computer Science, JNTU Kakinada, India, satishkmca@yahoo.com

Dept of Computer Science and Systems Engineering, AU Visakhapatnam, India, psrama@gmail.com

Abstract
On an average, more than 8 million people fly in around 100,000 commercial flights everyday around the world.
Software plays a crucial role in the system. Even though accidents occur rarely and the role of software in those
accidents is debatable still, learning from other domains, steps should be taken to ensure if any mishap occurs in future,
software failure is not the cause for the accident. This paper proposes some safety measures that should be taken by
software developers while developing software for aviation industry.
Keywords: Software Safety, Aviation Industry.

I.

INTRODUCTION

A general definition for safety is the "freedom from

those conditions that can cause death, injury, illness,
damage to or loss of equipment or property or cause
environmental harm''. The definition of safety-critical
software is more subjective. A generally accepted
definition for Safety Critical Software is: "Software whose
use in a system can result in unacceptable risk, safetycritical software includes software whose operation or
failure to operate can lead to a hazardous state, software
intended to recover from hazardous states, software
intended to mitigate the severity of an accident''. The
software safety standard published by the U.S. National
Aeronautics and Space Administration (NASA) (NASASTD-8719.13C) [10] identifies software as safety-critical if
at least one of the following criteria is satisfied.

It resides in a safety-critical system, at least one of the

following:
i. The degree of control that the software exercises
over the systems safety critical functions.
ii. The

complexity of the software. From

autonomous control of a hazard to timed
intervention
to
engineering
data
evaluation, to human in the loop, greater
complexity dramatically increases the
chances of errors.

iii. The timing criticality of hazardous control

actions.

From these definitions, it can be concluded that

software by itself is neither safe nor unsafe; however, when
it is part of a safety-critical system, it can cause or
contribute to unsafe conditions [6].
This paper is organized as follows. In the next section
we talk about importance of Safety Critical Software. In
Section III we talk about Software in Aviation Industry. In
Section IV we talk about the safety measures that should be
taken for software in the aviation industry. In section V we
present our conclusion.
II.

Software, unlike hardware, does not follow the laws of

physics - it does not wear out or break under known
conditions, or fail in predictable ways. Some other unique
characteristics are follows:

Programs can be complex and difficult to

understand, even if they are short. Patriot Missile
Defense System (1991)

Software tends to improve with time because latent

errors are discovered and corrected. Iran Air Flight
655 (1988)

Correcting an error in one area can introduce

another error which can be in a seemingly
unrelated area.

Software can interface with dozens or even

hundreds of other software modules.

Unlike hardware, software does not provide

forewarning when it fails. Latent software errors

iv. The likelihood a hazard will occur.

v. The worst possible effect of the hazard
(severity).

It processes data or analyzes trends that lead directly to

safety decisions.

It provides full or partial verification or validation of

safety-critical systems, including hardware or
software system.

IMPORTANCE OF SAFETY CRITICALSOFTWARE

The role of software has increased over the last 20

years. As software has become more pervasive, the system
and safety processes have also evolved. The traditional
analog and mechanical system failure analysis and
reliability techniques do not work on software because of
its complexity and uniqueness. Two points to be considered
firstly, "Software uniqueness that drives the need for the
development assurance process'' and secondly, ``How
software fits into the system and safety process''.

121 | International Journal of Computer Systems, ISSN-(2394-1065), Vol. 03, Issue 02, February, 2016

Kadupukotla Satish Kumar et al.

Software Safety in Aviation Industry

can remain invisible for years and then suddenly

appear.

Software can be easily changed (which is why its

called soft-ware)

Finding an error in software can be long and

laborious, especially if not handled proactively.

In order to successfully implement safe software [1]

[2], one must first understand its role in the system.
Focusing only on the software without considering the
system and its safety characteristics is like treating the
symptoms of a serious illness without getting to the root
cause of the illness. There are five key factors that must be
thoroughly and constantly addressed when developing
safety-critical software.
A. Well-documented systems architecture and
requirements definition
The System architecture and requirements must focus
on safety and should be written down. It is next to
impossible to successfully implement documentation
requirements. To ensure they are the right requirements, the
system requirements also need to be validated for
correctness and completeness.
B. Solid safety practices at all levels of development
Throughout the development, potential hazards and
risks must be identified and addressed. Safety should be
integral to all processes at all levels of the development
not just the responsibility of the safety organization.
C. Disciplined implementation
The documented requirements and safety attributes
must be accurately implemented. This includes both
assuring that the requirements have been properly
implemented and that no unintended functionality is
added.
D. Well-qualified personnel
Safety-critical systems are implemented by human
beings. The persons involved in the implementation must
possess good knowledge of the domain, safety, and the
technology being used to implement the system. People
working in the safety-critical field should be the cream of
the crop-perfectionists who strive for 100\% on every task.
Safety-Critical Systems demand a commitment to
excellence.

operated and the overall system safety process. An aircraft

is a large system comprising multiple system, it is
essentially a system of systems. Aircrafts system can
include navigation, communication, landing gear, flight
control, displays, environmental control, collision
avoidance, in-flight entertainment, electrical power,
engine control, fuel details, ground steering, thrust
reversers, Recording system (black box), air data and
more. Each system has an effect on the overall operation
of the aircraft. Obviously, some have more safety impact
than others. Because of this the civil aviation regulations
and supporting advisory material classify failure
categories according to risk. Five failure condition
categories are used: Catastrophic, hazardous/ Severe
major, major, minor and no effect. Each function in each
system, as well as the combination of functionality, is
assessed for its overall impact on safe aircraft operation.
The aircraft operation includes multiple phases, such as
taxi, take-off, climb, cruise, descent and landing. System
safety is evaluated for each phase, as the effects of failure
conditions can vary greatly, depending on the phase.
Developing a safe system typically requires years of
domain expertise with the specific type of system [7][9],
as well as thorough understanding of how an aircraft and
its systems operate and interact with each other and human
operators. in recent years, some stakeholders alarmed that
some organizations seems to believe that anyone with an
engineering degree can develop an aircraft system. Even
ISIS is developing their own missiles and bombs. We
cannot oppose to globalization and profit, but developing
the core expertise and competency to build safety-critical
system requires significant time, resources and integrity.
III.

SOFTWARE IN AVIATION INDUSTRY

The contribution of software to aircraft accidents is

debatable, because the software is part of a larger system
and most investigations focus on the system-level aspects.
However, in other domains (e.g., nuclear, medical and
space) software error have definitely led to loss of life or
mission [8]. The Mars Orbiter mission failure [16], ArianeV rocket explosion [13], the Therac 25 [14] radiation
overdoses, and the Patriot missile system shutdown during
the Gulf war [15] are some of the more well-known
examples. The historical record for safety-critical software
in civil aviation has been quite respectable.

E. Thorough testing at all levels

There is definitely a role for reviews and analyses, but
they cannot replace the need to prove functionality and
safety claims with the integrated software and hardware
[5].

Even though the case of the role of software in any

accidents in aviation industry has not been reported, still
steps should be taken to make sure that no accident occurs
due to software failure in future. The aviation industry
should not become a reactive industry i.e. it will take action
only when incident happens, rather precautionary steps
should be taken before any mishap happens.

It is important to understand the context of software in

the overall system. Software operates in the context of a
system, and safety is a property of the overall system.
Software, in and of itself, is neither safe nor unsafe.
However, software influences safety in a variety of
system types, including aircraft systems, automotive
systems, nuclear systems and medical systems. In order to
develop software that enhances rather than impairs safety,
one must first understand the system in which the software

With the advancement of technology, there is

continuous quest for more automation. Increasing
reliability on systems controlled by computer has to be
done only when they are all safe. The current safety
standards or measures may not be adequate for future
systems and may fall short in preventing an accident or
incident. The measures will not be adequate in the future as
it will be more challenging or presents more risk due to the
following reasons:

122 | International Journal of Computer Systems, ISSN-(2394-1065), Vol. 03, Issue 02, February, 2016

Kadupukotla Satish Kumar et al.

Software Safety in Aviation Industry

A. Increased lines of code:

The number of lines of code used in safety-critical
systems is increasing. For example, the lines of code
from the Boeing 777 to the recently certified Boeing
787 have increased eight fold to ten fold, and future
aircraft will have even more software.
B. Increased complexity:
The complexity of systems and software is increasing.
For example, Integrated Modular Avionics (IMA) [17]
provides weight savings, easier installation, efficient
maintenance, and reduced cost of change. However,
IMA also increases the systems complexity and
results in functions previously isolated to physically
different federated hardware being combined onto a
single hardware platform with the associated loss of
multiple functions should the hardware fail. This
increased complexity makes it more difficult to
thoroughly analyze safety impact and prove that
intended functionality is met without unintended
consequences.

Because of the market demands and the shortage of

engineers, more and more safety-critical software is
being outsourced and off shoring. While not always an
issue, oftentimes, outsourced and off shored teams do
not have the systems domain knowledge and the safety
background needed to effectively find and remove
critical errors. In fact, without appropriate oversight,
they may even inject errors.
G. Attribution of experienced engineers:
A number of engineers responsible for the current
safety record are retiring. Without a rigorous training
and mentoring program, younger engineers and
managers do not understand why key decisions and
practices were put into place. So they either dont
follow them or they have them removed altogether.
H. Lack of available training:
There are very few safety focused degree programs.
Additionally, there is little formal education available
for system and software validation and verification.
IV.

C. Increased Criticality:
At the same time that size and complexity of software
are increasing, so is the criticality. For example, flight
control surface interfaces were almost exclusively
mechanical ten years ago, now, many aircraft
manufactures are transitioning to fly-by-wire software
to control the flight control surfaces, since the fly-bywire software includes algorithms to improve aircraft
performance and stability
D. Technology Changes:
Electronics and software technology are changing at a
rapid rate. It is challenging to ensure the maturity of a
technology before it becomes obsolete. For example,
safety domains require robust and proven
microprocessors; however, because a new aircraft
development takes around 5 years, the microprocessors
are often nearly obsolete before the product is flight
tested. Additionally, the changes in software
technology make it challenging to hire programmers
who know assembly, C or Ada (the most common
languages used for airborne software). These real-time
languages are not taught in many universities.
Software developers are also getting further away from
the actual machine code generated.
E. More with less:
Because of economic drivers and the pressure to be
profitable, many (may be even most) engineering
organizations are being requested to do more with less.
Most good engineers are doing the work of what was
previously done by two or more people. They are
spread thin and exhausted. People are less effective
after months of overtime. A colleague of mine puts it
this way: overtime is for sprints, not for marathons.
Yet, many engineering products are working overtime
for months or even years.
F. Increased outsourcing and off shoring:

SAFETY MEASURES

For civil aviation, developers are encouraged to use

SAEs (Society of Automotive Engineers) Aerospace
Recommended Practice (ARP) 4754 revision A (referred to
as ARP4754A [11]), entitled guidelines for Development
of civil Aircraft and systems, ARP4754 was published by
SAE in 1996 and developed by a team of aircraft and
avionics manufacturers, with input from certification
authorities. ARP4754 divides the system development
process into six phases.

Planning
Aircraft Function Development
Allocation of Aircraft Functions to Systems
Development of System Architectures
Allocation of System Requirements to items
(including allocation to software and hardware)
System Implementation (including the software and
hardware development).
These six phases are started from scratch onwards
because airplane construction takes 5 years. Each phase
will have coordination with other phases.
A. System Safety Assessment
Safety is assessed in parallel with the aircraft and
system development. An overview of civil aviation safety
assessment process, as well as explanation of how software
fits into the system and safety framework. Fig. 2 below
shows the iterative nature of the system and safety
development, as the system develops, the safety aspects are
identified and addressed by the design. SAEs ARP4761
[12], entitled guidelines and methods for conducting the
safety assessment process on civil airborne systems and
equipment, provides a detailed description of the
expectations for civil aviation.
1) Safety Program Plan
The safety Program Plan development is typically the
first task performed in the overall assessment of the aircraft
safety. The plan identifies how the aircraft safety will be
ensured, how safety-related requirements will be identified,

123 | International Journal of Computer Systems, ISSN-(2394-1065), Vol. 03, Issue 02, February, 2016

Kadupukotla Satish Kumar et al.

Software Safety in Aviation Industry

what safety standards will be applied, what data will be

produced, what methods will be employed, who will
perform the tasks, key milestones, and how the various
tasks will be coordinated in order to ensure correctness,
completeness and consistency.
Safety Program Plan, which may be used as a template
to start an aircraft specific safety plan. In addition to the
aircraft-level safety program plan, many systems will also
have a system-level safety plans may be referenced from
the aircraft-level safety program plan. Either the safety
program plan or the aircraft-level certification plan
typically shows the relationship between the various
aircraft-level and system-level plans and data.

The system functional hazard assessment (SFHA) is

similar to the FHA, except it goes into more detail for each
of the systems on the aircraft. It analyzes system
architecture to identify and classify failure conditions and
combinations of failure conditions. This may lead to an
update of the FHA and the overall aircraft or system
design.

Fig 2. Assessment

Fig. 1 System
2) Functional Hazard Assessment
FHA is developed once the basic aircraft functionality
and conceptual design are documented. The FHA
identifies and classifies failure conditions associated with
aircraft functions and combinations of functions. The
effects of the failure conditions on the aircraft are assessed
against the regulations and supporting guidance that
establish the safety requirements and objectives for the
aircraft. In the aviation world, the required safety
objectives vary by aircraft type (e.g., transport category
airplanes, small airplanes, small rotorcraft, transport
category rotorcraft, engines or propellers. The large
transport category aircraft tend to have the most rigid
requirements due to the overall risk to human life. Small
aircraft have some alleviation, depending on the aircraft
size and its area of operation.
3) System Functional Hazard Assessment

4) Preliminary Aircraft Safety Assessment

The preliminary aircraft safety assessment (PASA) is a
systematic examination of a proposed architecture(s) to
determine how failures could cause the failure conditions
identified by FHA. The PASA is the highest level
preliminary safety analysis and is developed from the
aircraft FHA. The PASA is typically performed by the
aircraft manufacturer and considers combinations of
systems and interfaces between them. The PASA inputs
include the aircraft-level and system-level FHAs,
preliminary common cause analyses (CCAs), and proposed
system architectures and interfaces. The PASA may
identify updates to the FHA and SFHA and will typically
generate lower level safety requirements.
5) Preliminary System Safety Assessment
Like the PASA, the preliminary system safety
assessment (PSSA) is a top down examination of how
failures can lead to functional hazards identified in the
FHA and SFHAs. While the PASA focuses on the aircraft
architecture and integration of systems, the PSSA focuses
on the proposed architecture of a specific system,
subsystem or product. Each major aircraft system will
have a PSSA. There may be multiple hierarchical levels of
PSSAs for systems that have multiple subsystems into
detail for each system on the aircraft. As the aircraft
systems mature, the PSSAs provide feedback to the
PASA.
The PASA and PSSA processes may lead to additional
protection or architectural mitigation (e.g., monitoring,
partitioning, redundancy, or built-in-test). The PASA and
PSSA output serve as feedback or input to the FHA and

124 | International Journal of Computer Systems, ISSN-(2394-1065), Vol. 03, Issue 02, February, 2016

Kadupukotla Satish Kumar et al.

Software Safety in Aviation Industry

SFHAs, system architecture, and system requirements.

The PASA and PSSA also impact software and hardware
requirements. Overall, the PASA and PSSAs are intended
to show that the proposed design will meet the safety
requirements of the regulations and the FHA and SFHSs.
The PASA and PSSA serve as inputs to the as-built final
aircraft safety assessment (ASA) and system safety
assessments provide the development assurance levels
FDALs) and the software and electronic h/w (item
development assurance levels IDALs).
6) Common Cause Analysis
The CCA evaluates system architecture and aircraft design
to determine sensitivity to any common cause events. This
helps to ensure that 1. Independence is achieved where
needed and 2. Any dependencies are acceptable to support
the required safety level. The CCA verifies that the
independence needed for safety and regulatory compliance
exists, or that the lack of independence is acceptable.
ARP4754A explains that the CCA establishes and
verifies physical and functional separation, isolation and
independence requirements between system and items and
verifies that these requirements have been met. The
output of the CCA is input to the PASA and/or PSSA and
the ASA and/or SSA. Three separate analyses are typically
performed to evaluate common cause; each is explained in
the following:
PRP A particular risk analysis evaluates events or
influences which are outside the system(s) and
items(s) concerned, but which may violate failure
independence claims. ARP4761 provides several
examples of events or influences external to the
aircraft or external to the system or item being
evaluated.
ZSA A zonal safety analysis is performed for each
zone on the aircraft. Example zones include nose bay,
cockpit, cabin, left wing, right wing, tail cone, fuel
tanks, cargo bay and avionics bay. A ZSA ensures that
the installation meets the safety requirements with
respect to basic installation, interferences between
systems, or maintenance errors. The ZSA is carried
out for each identified zone of the aircraft and includes
design, installation guidelines, examination to ensure
conformance to the guidelines, and inspection to
identify any interferences (based on the failure modes
and effects analysis and summary)
CMA The common mode analysis considers any kind
of common effect during development, implementation,
test, manufacturing, installation, maintenance or crew
operation that may lead to a common mode failure.
CMAs are performed at multiple hierarchical levels of
the aircraft development- all the way from the top
aircraft level down to the individual circuit cards. CMAs
verify that events ANDed together in the fault tree
analysis dependence diagrams, and/or markov analysis
are truly independent. This analysis has an impact on
software development because it considers common
modes such as software development errors, system
requirement errors, functions and their monitors and
interfaces. The CMA helps determine what development

assurance levels are assigned for the system, software,

and hardware are.
7) Aircraft and System Safety Assessment
The ASA and SSAs verify that the implementation
aircraft and system design meets the safety requirements
defined in the FHA, SFHAs, PASA and PSSAs. The ASA
and SSAs are performed on the as-built, implemented
design, whereas the PASA and PSSAs are based on the
proposed design. The ASA and SSAs are the final
evidence that the aircraft meets the regulatory safety
requirements. As with the PASA and PSSAs the ASA is
usually performed by the aircraft manufacturer, and the
SSAs are performed by the systems developers. The ASA
considers combination and integration of systems and is
closely coordinated with the multiple SSAs.
8) Development Assurance
In complex and highly integrated electronic systems
with software and/or programmable hardware, it is not
feasible to test all combinations of inputs and outputs to
assign a probability of failure. This limitation, combined
with the fact that computer programs do not deteriorate or
fail over time like physical components, leads to the need
for a concept called development assurance. Development
assurance is used to ensure confidence in the process used
to develop the system and its items. Development
assurance is all of those planned and systematic actions
used to substantiate, at an adequate level of confidence,
that errors in requirements, design and implementation
have been identified and corrected such that the system
satisfies the applicable certification basis. Development
assurance assumes that a more rigorous process is more
likely to identify and remove errors before the product is
delivered that a less rigorous process. The concept of
development assurance was initially introduced to address
software; however, it also applied in civil aviation, along
with the industry documents that provide the guidance for
each domain. Development assurance levels are
established by the safety assessment process, based on the
potential safety impact system. ARP4754A defines
development assurance level as the measure of rigor
applied to the development process to limit, to a level
acceptable for safety, the likelihood of errors occurring.
B. Software Development Assurance
Because of the inability to accurately apply reliability
models to software, the concept of development assurance
is applied by most safety-focused industries, including the
aviation industry. The goal of development assurance is to
apply rigorous processes to the development process in
order to prevent, identify and remove errors.
Addressing Software in the System Safety Process is a
system attribute not a software attribute. Sound systems,
safety, hardware and software engineering are necessary
for safe system implementation. Here are some
suggestions for improving the coordination between the
two disciplines:

Assign safety attributes to the software requirements

that specifically support safety protection, in order to
identify which software requirements are most crucial

125 | International Journal of Computer Systems, ISSN-(2394-1065), Vol. 03, Issue 02, February, 2016

Kadupukotla Satish Kumar et al.

Software Safety in Aviation Industry

to safety. This also helps to ensure that the safety

implications of charges are fully considered.
Involve the system and safety engineers in the review
of software requirements and architecture.
Coordinate derived software requirements with the
safety team as soon as they are identified to ensure
that there are no safety impacts. Include rationale in
derived requirements, so that they can be understood,
evaluated for safety and maintained.
Co-locate system, safety, hardware and software
teams.
Perform PSSA early in order to identify software
levels and clearly identify what system functions have
safety impact; that is, make it clear what drives the
software level assignment or what mitigations
(protection) are needed in the software.
Provide a summary of the PSSA to the entire
software team to ensure that they understand the
rationale for the software level and the impacts of
their work on safety.
Consider carrying the safety assessment down in to
the software to support the overall safety assessment
process. This is particularly beneficial where
protection (e.g., partitioning or monitoring) is
implemented in the software.
Train the software team in the basics of system
development, the SSA process, development
assurance level assignment, common techniques used
for developing safety-critical systems, and what they
should be aware of for their system.
Use experienced teams. If junior engineers are used
(we all have to start somewhere), pair them with
experienced engineers.
Develop a safety focused culture. If top-level
management supports safety and walks the talk, it
makes an incredible difference in how it is viewed
and implemented down in the trenches.
Every year make a team from civil aviation experts
to form a consortium. Whenever safety-critical
systems changes take place, information should be
passed on to everyone in the consortium.
V.

[3]

[4]
[5]

[6]

[7]

[8]

[9]

[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]

M Ben Swarup, P Seetha Ramaiah A Software Safety Model for

Safety Critical Applications International Journal of Software
Engineering and Its Applications Vol. 3, No.4, October 2009
B P Douglass Safety Critical Systems Design
T R S Prasad Babu, Dimmiti Srinivas Rao, Prathipati Ratna Kumar
Negative Testing is Trivial for Better Software Products,
IJRAET, Vol 3, No 1, pp:36-41, 2015
Lorin J. May, "Major Causes of Software Project Failures".
[Available
at]
http://www.cic.unb.br/~genaina/ES/ManMonth/SoftwareProjectFail
ures.pdf
Jonathan S Ostroff Formal methods for the specification and
design of real-time safety critical systems, Journal of Systems and
Software archive, Vol 18, No 1, pp 33 - 60, April 1992
W. Eric Wong, Vidroha Debroy and Andrew Restrepo, "The Role
of Software in Recent Catastrophic Accidents," IEEE Reliability
Society 2009 Annual Technology Report, January 2010
Jonathan Bowen Safety-Critical Systems, formal methods and
standards, Software Engineering Journal, Vol 8 ,No 4, pp 189-209,
Jul 1993
http://www.hq.nasa.gov/office/codeq/doctree/NS871913C.pdf
http://standards.sae.org/arp4754a/
http://standards.sae.org/arp4761/
Ariane 501 Inquiry Board, [Available at]
https://www.ima.umn.edu/~arnold/disasters/ariane5rep.html
http://sunnyday.mit.edu/papers/therac.pdf
http://www.gao.gov/products/IMTEC-92-26
http://mars.jpl.nasa.gov/msp98/news/mco991110.html
https://www-users.cs.york.ac.uk/~philippa/IMA.html

CONCLUSION

Aviation industry is heavily dependent on software for its

functioning. A software failure in aviation industry can put
many lives at risk. In this paper we have shown what are
the challenges that lie ahead for the software developers
when writing code for aviation industry. We have also
presented some guidelines or benchmarks that should be
followed while writing code for the aviation industry.
Sticking to the guidelines will ensure that the software
does not fail inadvertently resulting in an accident.
REFERENCES
[1]

[2]

J. C. Knight, Safety critical systems: challenges and directions,

IEEE Proceedings of the 24th International Conference on Software
Engineering. ICSE 2002, pp. 547 550
W. R. Dunn, Designing safety-critical computer systems, IEEE
Transactions on Computers, Vol. 36, No. 11, pp. 40 46,
November 2003.

126 | International Journal of Computer Systems, ISSN-(2394-1065), Vol. 03, Issue 02, February, 2016