Running head: SPACECRAFT AND SOFTWARE

Spacecraft and Software:

The stability and solidarity of software in spacecraft, its validation, and dependability.
Jerod M. Heck
Embry-Riddle Aeronautical University
Space Mission and Launch Operations

SPACECRAFT AND SOFTWARE

Abstract
As spacecraft continue to rocket into our orbits the need for well-designed software is critical to
the longevity of such vehicles. With more than one million seven hundred thousand lines of
code currently running on the International Space Station, code quality is a colossal concern.
Companies such as Space X, Blue Origin, and United Launch Alliance have found that the code
quality has to be assured before it is applied to a vehicle before launch or while in orbit. Test
Driven Development is an important process to verifying that code meets its intended purpose,
combined with the COMPASS toolset developers and systems engineers can prove the validity of
their code. Developers must assure that their code is put through rigorous process before being
approved for production.

SPACECRAFT AND SOFTWARE

Table of Contents
Abstract................................................................................................................................2
Introduction..........................................................................................................................4
Problem Statement...............................................................................................................5
Restrictions and Background...............................................................................................6
System Architecture and Software Architecture Validation................................................8
Test Driven Development..................................................................................................10
Case Study.........................................................................................................................12
Analysis, Conclusions, and Recommendations.................................................................14
References..........................................................................................................................16

Figure 1"Lines of Code", Brat (2006)-------------------------------------------------------------6

Figure 2: Functional view of the COMPASS Platform. Bozzano, 2014----------------------8
Figure 3: Degrees of state space increase (Bozzano, 2014)------------------------------------9
Figure 4: Red-Green-Refractor, Pathfinder Solutions (2012)---------------------------------10
Figure 5: TDD Time to Market Payoff, Pathfinder Solutions (2012)------------------------11
Figure 6: "Normal Status" to "Objects Separation", JAXA, 2016---------------------------12
Figure 7: ASTRO-H (Hitomi) Spec, JAXA, 2016---------------------------------------------13

SPACECRAFT AND SOFTWARE

Introduction
In the 21st century, our daily lives are ruled by the constant flow of technology.
Technology which functions only by the aid of software. The software is the machine code
which describes the processes and duties which the devices should perform. Some systems
perform simple, but necessary functions with only a few lines of code while others contain
millions of lines of code. For the most part, engineers typically build aeronautical systems with
embedded coding developed more often than not with the C programming language. However,
as with the aerospace industry embedded programming isnt capable of giving engineers and
industry leaders the full suite of enterprise software capabilities.
Most government contracts require a zero fault policy. With the increase in system
complexity, the opportunity for errors and system bugs increases exponentially. Many
commercial companies have enacted policies and practices to reduce such mistakes. Practices
like test driven development improve the integrity of such systems.
As engineers begin to formulate new ways to improve the low-level systems often
integrated into current spacecraft systems, its important to make good practices at the start of
each project. Engineers often push software development to lower priorities tending to focus on
the hardware aspects. This kind of mentality has led to poor system development and if not
checked will lead to future disasters such as the Japanese satellite Hitomi. In the following
paper, we will look at several ways in which to improve the current software development for
space systems, including validation and testing of the code upon them.

SPACECRAFT AND SOFTWARE

Problem Statement
Aerospace and Space Industries should use proven test driven development processes.
Aerospace and Space Industries should look at existing data found in many enterprise
commercial software industries. Aerospace and Space Industries should explore the use of
software engineering principles and knowledge over attempting to come up with new processes
and methods for software testing from a completely new and isolated standpoint.
However, Aerospace and Space Industries have gotten into the habit of trying to build
software for space destined platforms without using software engineering principles and
methods. The study of software engineering is the study of software design and development
with the use of engineering principles and guidelines. Yet Space Industries often ignore the
knowledge base which lies in the software engineering disciple tending to build new processes
and utilize mechanical, electrical, and other engineers in development of system software.
The outcome of this type of development is inefficient and bug infested systems which
can ultimately cause catastrophic results. Without proper test driven development and utilization
of human computer interaction methods for astronauts the likely hood of errors rises drastically.
While the need for better software grows rapidly, the cost of cross training traditional engineers
is grossly more expensive then hiring the appropriate individuals for the job.

SPACECRAFT AND SOFTWARE

Review of Relevant Literature

Restrictions and Background
The development of software over the years has developed from simple functional
programming to larger systems that require greater attention. The focus of this research
document is one of three mission critical systems. The three mission critical systems consist of
flight software, ground software, and simulation software. Of the three mission types the flight
software is arguably the most critical.

Figure 1"Lines of Code", Brat (2006)

Flight software must conform to several strict guidelines. First it must fit onto radiationhardened processors. Radiation-hardened processors are currently being led by the High
Performance Spaceflight Computing (HPSC) Processor Chiplet program for NASA and U.S. Air
Force manned and unmanned spacecraft (Keller, 2016). Radiation-hardened processors are
essential to avoid effects of radiation in space, such as solar charging, which can cause
unexpected results in equipment.

SPACECRAFT AND SOFTWARE

Second it will have limited memory resources. Modern systems have improved
drastically however once launched, system resources cant be increased. Storage space and
memory are critical to the design and development of software. These resources act as
constraints in which developers must build within.
Third, the software must contain proper logging, this is possibly the most critical element
in development. Without proper logging the ability to create patches or fixes is greatly hindered.
Developers must create logging calls appropriately. In the same way that too little logging leaves
developers at a loss of system failures or bug errors, too much logging can create an environment
where so many logs are created that they fill up available storage, or worse, the clutter cause
critical errors to be missed or overlooked.
Finally, the software must be patchable or capable of receiving a new version during the
mission. Given the nature of space craft and their distant locations in space make the ability to
update existing software essential to the health of the overall system and mission. The initial
architecting of the system can cause future modularity and smooth transitions or cause hours of
inefficient code refactoring and failure to meet deadlines.
Over time mission software has increased in complexity. Large source repositories can
often hold more than one million lines of code. The code may be years old and consist of
multiple programming languages, sometimes layered one upon the other. Commonly algorithms
and low level development will be performed in the C programming language and framed with
Python or wrapped in a larger architecture with C++. As time progresses every little error or
weak line of code causes a trickle effect turning small problems or simple work arounds into
large amounts of code debt. This code debt will eventually have to be paid through many hours

SPACECRAFT AND SOFTWARE

spent in code repair and refactoring. Some debt becoming such an issue that an entirely new,
untested, system is easier to create.
System Architecture and Software Architecture Validation
In their 2014 Reliability Engineering and System Safety article Spacecraft early design
validation using formal methods, Marco Bozzano, Allesandro Cimatti, Joost-Pieter Katoen,
Panagiotis Katsaros, Konstantinos Mokos, Viet Yen Nguyen, Thomas Noll, Bart Postma, and
Marco Roveri wrote about the use of the COMPASS project and its use in validating software in
spacecraft at an embedded level. COMPASS is expressed through a single modeling language
known as the Architecture Analysis & Design Language (AADL). Through the AADL language
the COMPASS toolset is able to automate analyses which are currently only done through
manual, error prone, techniques (Bozzano et al, 2014).

Figure 2: Functional view of the COMPASS Platform. Bozzano, 2014

The COMPASS toolsets is made up of about 100,000 lines of Python code, and handles
multiple AADL models as inputs. Combined with a properties file asking for user runtime

SPACECRAFT AND SOFTWARE

specified variables, called patterns, the COMPASS tool uses patterns to allow changes to be
applied dynamically. The tool then is capable of generating multiple outputs, such as fault trees,
traces, and FMEA tables, diagnosability and performance measures (Bozzano et al , 2014).

Figure 3: Degrees of state space increase (Bozzano, 2014)

Figure 3 shows Bozzano et al (2014) and their teams effort to prove out the analysis
funciontality of the COMPASS tool. The figure describes the state space increase as a multiplier
of the nominal state space, which is 48 million states. In general the figure indicates the degree
of scalability that can be expected with the level of computing technology available as of 2010.
Test Driven Development
According to the article Effective TDD for Complex Embedded Systems by Pathfinder
Solutions (2012), Test Driven Development, or TDD, is a process of test-first development in

SPACECRAFT AND SOFTWARE

10

which test cases are built prior to each aspect of feature implementation and behavioral design.
This process is formed around individual functional test cases which test an individual method or
function. By doing this the software is proven to always be in a healthy state, allowing
developers to change as much, or little, of the code as they wish without fear of damaging the
end result. This type of development is often counter intuitive for most developers, yet is proven
to strengthen the integrity of the source code.
A primary principle of TDD is Red-Green-Refractor, which describes how the test and
behavior is implemented. A developer first writes a simple test which fails. Then the bare
minimum of code is developed in order for the test to pass. Typically this is spaghetti code, and
not a polished version, thus the Refractor aspect of the mantra. The Refractor aspect is where the
code is then hardened, cleaned, and polished. The test is simple. The code developed to
complete the task should be nearly as simple, discounting complex algorithms, transforms, or
other complicated mathematical functions.

Figure 4: Red-Green-Refractor, Pathfinder Solutions (2012)

With day to day business time constraints the software industries perform against
tightening competition, schedules, and deadlines. This is true especially in the space industry
where deadlines are rarely met and budgets regularly run over. TDD increases productivity and
reduces the overall time that it takes to move software from requirements to software shipment.

SPACECRAFT AND SOFTWARE

Figure 5: TDD Time to Market Payoff, Pathfinder Solutions (2012)

11

SPACECRAFT AND SOFTWARE

12

Case Study
In February of 2016, JAXA, the Japanese space agency, launched an X-ray Telescope
called Hitomi, formally ASTRO-H. Its mission consisted of three years of planned observations,
with an expected ten years of additional scientific research, the full mission totaled $286 million
(JAXA, 2016).

SPACECRAFT AND SOFTWARE

On March 2016 Hitomi commenced a rotation to point at the galaxy Markarian 205.
However, when the Attitude Control System (ACS) initiated the Star Tracking Systems (STT)
data to control the satellite, it is believed, it failed to update the Inertial Reference Unit or IRU.

13

SPACECRAFT AND SOFTWARE

This led to the ACS incorrectly determining its attitude as rotating while it was still stationary.

14

SPACECRAFT AND SOFTWARE

Figure 6: "Normal Status" to "Objects Separation", JAXA, 2016

15

SPACECRAFT AND SOFTWARE

16

The JAXA believes that it was at this point that the Reaction Wheel was activated which
lead to the rotation of the satellite. They also noted that the ACS did not handle the unloading of
angular velocity via the Magnetic Torquer, because of the attitude anomaly. Furthermore, the
angular momentum continued to accumulate in the Reaction Wheel. At this point, the ACS
triggered the Safe-Hold mode to halt the negative momentum. Unfortunately, this compounded
Hitomis problems as the thrusters were provided atypical commands and inappropriate thruster
control parameters thus leading to accelerating the satellites rotation (JAXA, 2016). Finally,
with the satellites rotational speed increasing exponentially, its extremities began to rip off the
vehicle. This included the solar array paddles, Extensible Optical Bench, and others.

Figure 7: ASTRO-H (Hitomi) Spec, JAXA, 2016

SPACECRAFT AND SOFTWARE

17

Hitomis demise was caused by a failure in the software system. Poor design and a lack
of proper testing resulted in unexpected results. Whatever procedures JAXA expects their
developers to follow were not enough or were not followed when approving the state of the ACS
and STT software. This type of scenario should have been a part of the test procedures, and
incorporated into integration tests. In the end, the failure of JAXAs software team cost the space
agency millions and the threat of another largely uncontrollable object hurtling around the earth.
Analysis
The combined use of the COMPASS toolset combined with Test Driven Development
principles and practices are ideal for the Aerospace and Space Industries. They perform
validation task that enables developers to create clean code and package source with the
knowledge that it can be applied with minimal error. It is imperative that space-oriented
companies and organizations use forward-thinking methods to better prepare software for
placement on spacecraft.
NASA still finds itself behind the curve of commercial software and testing. They often
rely on proprietary software that often deals with scope creep that leads to exponential increases
in cost (Berger, 2016). Additionally, NASAs Ground Systems Development and Operations
(GSDO) and Congress have created a culture in which they rely on large government contractors
who rely on legacy systems in the creation of launch programs such as the Space Launch
System. Although these companies often have time proven methodologies and practices they
often try to force old, outdated and vulnerable, software systems onto new space craft. This habit
leads to the potential hacking of systems or fatal incongruences between old software and new
hardware.

SPACECRAFT AND SOFTWARE

18

In drastic differences, SpaceX utilizes commercial software from smaller software

providers. This type of dynamic approach to software is an essential piece to high performance
and software integrity. Developed by external software companies, SpaceX relies on software
companies to perform proper TDD and integration testing. Upon receiving the software, further
tests are carried out ensuring that many eyes have validated the integrity of the spacecrafts
software.
Conclusions
Given that many companies are experiencing a revitalization in public opinion and
interest in the space industry companies should begin to reassess ways to secure the health and
quality performance of their craft. Companies like SpaceX and Blue Origin, who are using new
systems which need newly developed code, should add TDD and COMPASS to their processing
methods. Other space industry giants like Boeing, Lockheed Martin, and ULA should make sure
that legacy systems are thoroughly vetted before reuse. Its important that corners arent cut as
we attempt to conquer and explore space. When we develop new devices we must ensure that
they receive every bit of testing and validation possible, the alternatives are not an option.

SPACECRAFT AND SOFTWARE

19

References
Brat, G. (2006). Software Verification for Space Applications. Retrieved September 11, 2016,
from https://ti.arc.nasa.gov/m/pub-archive/1338/1338 (Brat).pdf
Brat, G., Denney, E., Giannakopoulou, D., Frank, J., & Jnsson, A. (2006, March). Verification
of autonomous systems for space applications. In 2006 IEEE Aerospace Conference (pp.
11-pp). IEEE.
Berger, E. (2016). NASA launch system software upgrade now 77% over budget. Retrieved
September 25, 2016, from http://arstechnica.com/science/2016/03/nasas-glue-ware-forcomputer-launch-systems-over-budget-behind-schedule/
Bozzano, M., Cimatti, A., Katoen, J., Katsaros, P., Mokos, K., Nguyen, V. Y., . . . Roveri, M.
(2014). Spacecraft early design validation using formal methods. Reliability Engineering
& System Safety, 132, 20-35. doi:10.1016/j.ress.2014.07.003
Edell, D., & Wortman, K. A. (2015). Visualization of a Spacecraft Mission Software
System. 2015 IEEE Aerospace Conference. doi:10.1109/aero.2015.7118894
Frederick, M. (2006). NASA Studying the Reuse of Spacecraft Software. Retrieved September
04, 2016, from http://www.space.com/2304-nasa-studying-reuse-spacecraft-software.html
Hernek, M. (2013). Model-Based Testing of Spacecraft Flight Software - nasa.gov. Retrieved
September 4, 2016, from https://www.nasa.gov/sites/default/files/03-03_modelbased_testing_of_spacecraft_flight_software.pdf

SPACECRAFT AND SOFTWARE

20

JAXA. (2016). Status of X-ray Astronomy Satellite Hitomi (ASTRO-H). Retrieved September
25, 2016, from http://global.jaxa.jp/projects/sat/astro_h/files/topics_20160415.pdf
Keller, J. (2016). Air Force, NASA to develop radiation-hardened ARM processor for nextgeneration space computing. Retrieved September 11, 2016, from
http://www.militaryaerospace.com/articles/2016/06/radiation-hardened-spaceprocessor.html
Krupiarz, C. (2013). Learning Spacecraft Flight Software. Retrieved September 04, 2016, from
https://medium.com/@chriskrupiarz/learning-spacecraft-flight-softwarec5e7fb20c82#.wwj3dtmip
Liang, K., Guo, J., & Wang, J. (2014). On-board software maintenance for manned
spacecraft. 2014 IEEE 5th International Conference on Software Engineering and Service
Science. doi:10.1109/icsess.2014.6933552
Leveson, N. G. (2004). Role of Software in Spacecraft Accidents. Journal of Spacecraft and
Rockets, 41(4), 564-575. doi:10.2514/1.11950
Lockney, D. (2016). Advanced Spacecraft Integration & System Test Software (ASIST) Version
20.0. Retrieved September 04, 2016, from https://software.nasa.gov/software/GSC16783-1
Mirantes, M. A., Spezio, M., & Wortman, K. A. (2014). Confidence in Spacecraft Software:
Continuous process improvement in requirements verification. 2014 IEEE Aerospace
Conference. doi:10.1109/aero.2014.6836196

SPACECRAFT AND SOFTWARE

21

Nicewarner, K. E. (2008). A New Spacecraft Software Development Paradigm Enabled by HighPerformance Commercial Processors. 2008 IEEE Aerospace Conference.
doi:10.1109/aero.2008.4526528
Pathfinder Solutions. (2012). Effective TDD for Complex Embedded Systems - Pathfinder
Solutions. Retrieved September 11, 2016, from http://www.pathfindersolns.com/wpcontent/themes/pathfinder/downloads/EffectiveTDDforComplexEmbeddedSystems.pdf
Witze, A. (2016). Software error doomed Japanese Hitomi spacecraft. Nature, 533(7601), 18-19.
doi:10.1038/nature.2016.19835