Content uploaded by Miguel A Nunes
Author content
All content in this area was uploaded by Miguel A Nunes on Feb 17, 2015
Content may be subject to copyright.
Content uploaded by Joan C. Differding
Author content
All content in this area was uploaded by Joan C. Differding on Dec 31, 2014
Content may be subject to copyright.
978-1-4577-0557-1/12/$26.00 ©2012 IEEE
1
Plug and Play Mission Operations
Trevor Sorensen
Hawaii Space Flight Laboratory
University of Hawaii at Manoa
2820 East-West Rd., POST 501
Honolulu, HI 96822
808-956-4715
Sorensen@hsfl.hawaii.edu
Bruce Yost
NASA Ames Research Center
Mail Stop 202-3
Moffett Field, CA 94035
650-604-0681
bruce.d.yost@nasa.gov
Joan Differding
NASA Ames Research Center
Mail Stop 269-3
Moffett Field, CA 94035
650-604-2005
joan.differding@nasa.gov
Eric Pilger
Hawaii Space Flight Laboratory
University of Hawaii at Manoa
2820 East-West Rd., POST 501
Honolulu, HI 96822
808-956-6321
Eric.Pilger@hsfl.hawaii.edu
Miguel Nunes
Hawaii Space Flight Laboratory
University of Hawaii at Manoa
1680 East West Rd. POST 501
Honolulu, HI 96822
808-956-0441
Miguel.Nunes@hsfl.hawaii.edu
Abstract—Ongoing and planned smallsat programs within
NASA, the DoD, and academia have indicated a need to be able
to routinely and efficiently operate multiple small spacecraft in
support of science and technology missions. However, as the
number of these missions is expected to grow rapidly, the
associated costs to develop and operate unique ground control
stations, tools, and networks may become prohibitive to the
sponsoring organizations or universities. In order to inform
and raise the awareness of the smallsat space operations
community, the University of Hawai’i, NASA Ames Research
Center, San Jose State University (SJSU) and American
Institure of Aeronautics and Astronautics (AIAA) held a
workshop entitled Plug ‘n’ Play Mission Operations (PPMO)
which held May 16-17, 2011 at the SJSU campus in San Jose,
California. The purpose of the workshop was to foster
collaboration and leveraging of existing and developing
capabilities that may be collectively utilized by the smallsat
community for space operations. Although the emphasis of the
workshop was on small satellites, many of the techniques
discussed would be applicable to large spacecraft mission
operations as well. The workshop explored the adoption of
standards and existing capabilities as well as the creation of
new technologies that will enable space mission developers to
plan, design, and operate their spacecraft using a common
architecture in order to reduce cost and overall mission risk.
The PPMO workshop investigated the various needs of the
smallsat communities (military, civil and educational space)
and also touched on existing systems and capabilities (such as
GSFC’s GMSEC, JPL’s AMMOS, and NRL’s CGA used in
the MC3 program) and those under development (such as
HSFL’s COSMOS and ESA’s GENSO). The workshop also
held facilitated discussions organized into categories along the
lines of Approaches (programmatic and related issues),
Implementation (technical solutions and architectures), and
Applications (concept of operations, mission types and users).
This paper presents the results of this workshop and the path
forward.
TABLE OF CONTENTS
1. INTRODUCTION ................................................. 1
2. IMPORTANCE OF PPMO .................................. 2
3. APPROACHES TRACK........................................ 3
4. IMPLEMENTATION TRACK ............................... 4
5. APPLICATIONS TRACK ..................................... 6
6. FUTURE OF SMALL SAT OPS - COSMOS ........ 7
7. SUMMARY ....................................................... 10
REFERENCES ....................................................... 11
GLOSSARY OF ACRONYMS ................................. 11
BIOGRAPHY ........................................................ 12
1. INTRODUCTION
Miniaturization of electronics and increases in computing
power have resulted in a huge increase in the number and
importance of small satellites in recent years. CubeSats,
nanosats, and even picosats are being built by dozens of
companies, agencies, and universities world-wide.
Although building and even deploying small satellites has
become affordable, operating them, especially in large
numbers, is still a challenge. The existence of almost as
many solutions as developers of small satellites has resulted
in unnecessary “reinventing of the wheel.” This has
prompted several organizations to consider ways to easily
re-use effective software applications for new satellite
missions in a way that can done with minimum cost and
effort, especially for university-class satellites.
One solution is being developed by the Hawaii Space Flight
Laboratory (HSFL) at the University of Hawaii at Manoa.
HSFL won a 3-year NASA EPSCoR grant in 2010 entitled
“Development of an Open-architecture Mission Operations
System to Support Multiple Small Spacecraft Missions”
with NASA Ames Research Center (ARC) as the
collaborative agency. The end-product of this grant is the
Comprehensive Open-architecture Space Mission
Operations System (COSMOS). COSMOS is designed to be
easily adapted to new satellites and mission operation
centers, such as at HSFL and ARC. COSMOS is also being
designed to accept external software applications as “Plug-
and-Play” modules. A similar solution is also being worked
at other organizations through the country.
2
HSFL and ARC decided to hold a workshop to help identify
and unify the community interested in this topic so that their
efforts can be mutually supportive. The San Francisco
Section of the American Institute of Aeronautics and
Astronautics (AIAA) and San Jose State University (SJSU)
later joined in hosting the “Plug-and-Play” Mission
Operations (PPMO) workshop, which was held on the
campus of SJSU in San Jose, California on May 16-17,
2011. [1]
The purposes and goals of the workshop were:
(1) To identify the organizations that are interested in
responsive and effective operations of spacecraft,
especially multiple small spacecraft, using ground
systems that are designed especially for porting to new
mission operations centers (MOCs) and for modifying
for new spacecraft.
(2) Determine the current state of the art in such mission
operations systems (which are most likely to be Plug-
and-Play architectures), with identification of such
existing systems.
(3) Look at systems that are currently in development
which may meet this need.
(4) Identify issues (interfaces, protocols, proprietary and
security issues, etc.) that will be faced by such systems
and possible first order solutions to be investigated.
(5) Identify and characterize possible future applications
for such systems.
(6) Networking between the players in this field and the
possible establishment of collaborations that will
benefit the participants and the industry as a whole
(7) Improve the usefulness and applicability of COSMOS.
(8) Produce an AIAA white or conference paper on the
results of the workshop.
There were approximately 50 participants from various
NASA centers, DoD, industry, and universities. On the first
day there was a common session where the purposes of the
workshop were presented along with the perspectives of the
major stakeholders in successfully being able to operate
multiple small satellites: NASA, National Reconnaissance
Office (NRO), Department of Defense/Space Test Program
(DoD/STP), and universities. This was followed by future
objectives (near-term efforts underway) including an
overview of the COSMOS Project, as well as other
university efforts and the problem of frequency allocation
when multitudes of small satellites are being proposed.
Following this common session involving all the workshop
participants, the workshop was split into three concurrent
tracks that addressed different perspectives of the PPMO
problem:
(1) Approaches – especially suited for managers and
planners and covered the following topics:
Standardization: Pros and Cons
Ground Data System Approaches
Architectures and Standard SW Packages
Leveraging Infrastructure: Ground Stations, Networks,
Ops Facilities
Automation: Costs and Benefits
Current & Future Solutions
(2) Implementation – especially suited for software and
hardware engineers and covered the following topics:
Environments
Protocols/Interfaces
Support Functions
Tools
Standards
(3) Applications – especially suited for users and operators
and covered the following topics:
User requirements
Fleet control
Simulation and modeling
Enhanced ground segment
Enhanced communications
This paper presents a summary of the results of the PPMO
Workshop and briefly looks at the path forward in an
attempt to build on the benefits obtained from the workshop.
2. IMPORTANCE OF PPMO
We are currently witnessing a universal trend rolling
through space segment architectures that can be easily
visualized by the steady reduction of satellite size and mass
coupled with a constant increase in space systems
capabilities. This unique dynamic is due to a confluence of
technological factors similar to and including Moore’s Law
(“The number of transistors per square inch on integrated
circuits doubles every 18 months since the integrated circuit
was invented”). Smaller spacecraft can process more data,
perform more observations, and downlink more information
due to continual, almost exponential advancements in
computational power, solar cell efficiencies and energy
storage technologies, advanced software applications, and
3
the ability to inexpensively launch small spacecraft as
secondary (or even tertiary) spacecraft on otherwise large,
expensive launch vehicles.
In addition to the proliferation of these smaller, cheaper
spacecraft, innovative space architectures are now also
being seriously considered and even tested in space. These
new architectures include cooperative, multi-spacecraft
swarms or constellations that are theoretically capable of
executing missions or collecting measurements and
observations that are well outside of the traditional, single
large spacecraft architecture and performance realms.
However, these exciting developments within the space
segment are not without challenges. While the ability to
reduce the size, weight and power of a spacecraft does
indeed have direct cost implications, which are primarily
manifested in the reduced cost of access to space, the space
operations community must be prepared to support and
operate these constellations or swarms of large numbers of
small spacecraft in an equivalent low cost fashion. Simply
scaling the traditional methods currently in use by many
government or even commercial agencies would be
prohibitively costly and would severely dilute the benefit of
the low cost, small spacecraft platform. Therefore, similar
revolutions invoking standard interfaces, high levels of
automation, and other related technologies must be brought
to bear on the ground segment part of the equation to fully
realize the next generation of low cost, robotic spacecraft.
A fertile concept developed to stimulate this transformation
is a philosophy loosely named Plug-and-Play Mission
Operations where custom software and extensive testing can
be significantly reduced or even eliminated, thus shortening
development schedules, reducing overall mission risk and
minimizing costs associated with the deployment and
utilization of potentially many, many small spacecraft
performing many diverse functions.
3. APPROACHES TRACK
This track was led by Joan Differding of the NASA Ames
Research Center and was targeted at project leaders and
mission managers who are looking for the over-all designs
and methods that will lead to successful missions.
Suggested discussion points going in to the workshop
included the pros and cons of standardization, best practices
in data system architectures, how to leverage existing
infrastructure, and the costs and benefits of automation. The
focus for the discussion was less on the specific features of
various approaches and more on the trade space: What
decisions lead to choosing a particular approach, what costs
and benefits resulted from that choice, and what were the
lessons learned. The track attendees heard four
presentations, each of which touched on subsets of these
topics.
Kevin Lynaugh from Vulcan Technologies talked about
communications architectures: the challenges inherent
in meeting diverse communications requirements and
solutions that have been developed by Vulcan. He
described a TDRS-MA transponder developed by
Vulcan for use in CubeSats.
Connor Lange and Justin Foley from Cal Poly San Luis
Obispo presented their work on automating the
operation of Cal Poly’s three satellites using LabVIEW
and increasing data return using ESA’s GENSO.
Chris Webster from Ames Research Center presented
the Mission Control Technologies service-oriented
platform for developing end-user applications and
displays for use in ground data systems.
Darren Garber and Kenny Haag from Millennium
Space Systems discussed a common sense approach to
mission design.
Choosing an Approach
Functional architecture is key. An important point to
remember in designing a mission is to start with the
functional architecture. The physical architecture must
always support the functional architecture. An example of a
physical architecture not supporting the functional
architecture is a spacecraft that can collect a lot of data on
board, but can only downlink a small subset of that data
over the available communications links. Keeping the
functional architecture at the forefront can prevent this sort
of disconnect. The real trades are between all the resources
on the table and the over-all risk, instead of performance,
cost, and schedule.
Communications and operations should be included up front
when designing a mission. Communications and operations
experts need to be included in development of the concept
of operations and in the design of the spacecraft. Operations
engineers/planners should be engaged early in the concept
development and preparing of proposals. Operations
engineers are needed to keep the spacecraft and system
engineers on track. It is critical to spend the time on concept
of operations and design reference missions. The desire to
save initial cost of the spacecraft can cause expensive
operations work-arounds down the line. For example,
leaving a sensor off of the spacecraft to save money can
result in later high operations costs to calculate the
measurements or to operate without the information.
Communications is a bottleneck. Communications in space
is not the same as in the laboratory because of such factors
as the electro-magnetic environment, relative velocity, and
distance. It is important to understand all the data handling
tasks that need to take place and how those are commanded
and communicated. The end-to-end data path needs to be
carefully calculated.
Think outside the box - remember that you are designing for
space and consider space-specific needs. Cost constraints
often push the use of commercial off-the-shelf (COTS)
components. However, applying earth-based solutions to
space only goes so far. Remember to address the space-
4
unique problems with communications, since these will
often need specific solutions, rather than COTS re-use.
Challenge the assumptions of what is possible in space. For
example, low Earth orbit (LEO) to ground might not be the
only communication path. LEO to geostationary orbit
(GEO), e.g., TDRS, paths are also possible, if affordable.
Costs and Benefits
Automation—Automation can save costs, but there are often
strong drivers against it. There are a lot of automation
solutions already in place, but there is still major inertia in
the area of requiring humans in the loop. There is an
expectation that people have to personally provide care and
feeding for the spacecraft. Big teams may be needed for
complex operations (commissioning, anomalies, etc.) but
automation can be used effectively in many simple
scenarios. Justin Foley was able to double downlink
capability of the Cal Poly satellites by automating the
repetitive process that was required for communicating with
the satellites.
Re-use—Common barriers to re-use include old-style
monolithic solutions where the whole system must be used
to derive of the benefit of any one part and financial
incentives for developers to create new applications in their
entirety. As a result, displays are being re-designed and re-
implemented over and over, and databases designed fresh
every time. Or in contrast, projects are being forced to use
legacy systems that no longer meet their requirements
because the cost of building a new system is too high.
Solutions can be found in platforms on which people can
easily develop what they need. Facebook is a good example
of such a platform. Chris Webster described Mission
Control Technologies, which is a platform for developing
re-useable displays in mission operations environments.
Collective Benefits—Be cautious with solutions that require
buy-in to achieve benefit, such as group and collective
systems (e.g. GENSO) and standards (e.g., CCSDS). For
these approaches to be beneficial, they require that barriers
to adoption are minimized. For example, GENSO provides
its greatest benefit to members if it has many member
ground stations. However, GENSO has had low profile
because it is ESA and not open source. It is targeted at a
limited set of hardware. As result, the GENSO community
is still small. If it were open source, if it applied network-
based redundancy and if it employed a wider range of
hardware drivers, it could attract more members. If GENSO
were in widespread use so that more antennas are involved,
then wider coverage would be available. CCSDS is an
international standards body that seeks widespread adoption
of their standards in a wide range of areas. However, some
of the “standards” provide too much flexibility in how they
are applied, so the resulting usage is not really standard and
doesn’t support interoperability. In other cases the standard
is more like guidelines or best practices, so the end product
still has to be created new for each use. In these cases,
application of the standard does not end up saving time or
money, and these costs become barriers to adoption. The
benefit of adopting the standard must be apparent to the
adoptees. Simply being good will not be enough.
4. IMPLEMENTATION TRACK
This track was led by Eric Pilger of HSFL and dealt with
actual solutions to the problems seen in developing a Plug-
and-Play architecture. Hardware and software solutions,
both implemented and in development, and any issues that
which would need resolution, were discussed.
Topics of Interest
After some discussion among the attendees, it was decided
that the following topics merited discussion.
Work Environments—The cornerstone of Open
Implementations is the vast array of solutions already
available for a variety of operating and development
environments. However, the small sat environment presents
a unique challenge in terms of available hardware,
environmental constraints and system requirements. What
are these constraints, and how do they impact our choice of
environments? What environments are already available,
and which would we like to see made available? This topic
covered both development and operations.
Standards—An important element of Open
Implementations is adherence to easily implemented, widely
available standards. To what sort of standards should we be
adhering? What standards do we need to support? What
standards do we need to invent?
Tools—Well developed software tools greatly speed the
implementation of any solution. What software tools are
available, or being developed, that meet the unique needs of
Plug and Play Operations? To what extent do we adapt tools
that already exist? What do we need to develop from
scratch?
Support—Open Implementations are built on a foundation
of support elements, both in hardware and software. What
building blocks do we already have for constructing the
complex systems we need to develop and operate Plug and
Play missions? What do we need to create?
Communications—This topic, clearly one of the most
important of any mission, is also the one most beset with
problems for the small sat community. Current solutions all
suffer from some or all of; too little data, at too high a cost,
with too much red tape. The solutions that are currently used
are not going to scale to the 100’s (or 1000’s) of small sat
launches. Whatever will we do?
Speakers
Eight attendees presented one or more solutions to some of
the issues above that they either already have, or are
working on. A short summary of each is presented below, in
alphabetical order.
5
(1) William Clancy – NASA Ames Research Center – The
OCA Management System: OCAMS is a system for
automating the routine data transfers that happen between
the ISS and Ground. It has developed a standard language
and set of procedures for commanding transfers to occur. It
is implemented with a set of software Agents and GUI’s,
using XML and XHTML, over standard network protocols.
(2) Bob Feretich – RAF Research, San Jose – Inertial
Navigation System: Bob has been working with students at
SJSU to develop an INS that will fit in a high powered
rocket. His design leverages simple OTS components to
provide the necessary Inertial Measurement Unit. His
presentation emphasized the use of the Xenomai Real-Time
co-kernel to provide true real time performance in concert
with a regular Linux kernel (Angstrom).
(3) Kevin Lynaugh – Vulcan Wireless – Software Defined
Radios (SDRs): This is an area in which dramatic
development is occurring. Kevin spoke of Vulcan’s
contributions to this effort and displayed the transceiver that
is around the size of a deck of cards. These devices are
tunable through a wide range of frequencies completely
through software control. They also implement any required
encoding or decoding and can be designed to appear as
simply a network adapter to the Onboard Computer.
(4) Miguel Nunes – Hawai‘i Space Flight Laboratory –
COSMOS Operations Test Bed: One element of the HSFL
COSMOS EPSCoR project is the design of an open-sourced
hardware and software test bed to support all aspects of
satellite design and operations. Miguel presented his design
ideas for this project and the progress to date. Two aspects
of this project would affect the community as a whole. First,
the COSMOS team plans to create a suite of open-source
software and hardware that would then be affordable by
even high school groups wishing to put together their own
satellite facilities. Secondly, they hope to create a simulation
environment that could be used remotely with interaction by
the satellite development community to test algorithms and
designs.
(5) Eric Pilger – Hawai‘i Space Flight Laboratory –
COSMOS Software Project: The COSMOS EPSCoR
project has as its primary goal the creation of an Open
Software and Hardware environment for the design,
development and operation of small satellites. On the
software side the initial three year project plans to establish
a framework of Support Libraries and Protocols, a suite of
basic Programs and Agents, and a few GUI based Tools. In
hardware, the goal will be to create a basic test platform
with simulated versions of all the actual hardware that
would go on a satellite.
(6) John Ploschnitznig – Riverside Research – Automated
Collection Planning Tool (ACPT): Available free of charge
to governmental agencies, ACPT is an integrated tool for
automatically combining many aspects of AGI’s Satellite
Tool Kit (STK). An extensive list of requests can be entered
and then the optimal collection strategy calculated.
(7) Chris Webster - NASA Ames Research Center –
Mission Control Technologies (MCT): MCT is a Java based
tool kit for putting together display interfaces based on a
large database of multiple telemetry streams. Streams can be
easily viewed in different ways by being directed to
different “views” (textual, graphical, property). Different
views can then be easily arranged in to interfaces.
Additionally, the development kit allows the invention of
new views, thereby allowing users to extend the capabilities
of MCT.
(8) Mark Wood - Hawai‘i Space Flight Laboratory –
COSMOS Mission Operations Support Tool (MOST):
MOST, the first Tool developed by the COSMOS project,
has as its primary function the display of telemetry data
from a satellite or its simulator. It owes its heritage to the
LUNOPS program used for the Clementine mission. [3]
Developed with the QT graphical development
environment, it is designed to be easily configurable to
different satellites through a combination of a JSON based
satellite description and an XML interface description.
Track Conclusions
Each of the areas of interest were addressed during the
track, and the conclusions in each area are summarized
below.
Work Environments—The state-of-the-art is fairly
satisfactory. You can choose from a variety of operating
systems on almost any processor you want, and you can
even get a mix of Real Time and normal Linux using
something like Xenomai. Languages are not as fully
supported yet because some of the important things you
need, like the JPL ephemeris, are not available in Java.
However, the community is getting closer, and you can
always do the work yourself if it is absolutely necessary.
Standards—A large body of existing standards work just
fine. However, some of the evolving standards for space are
still problematic. Unlike TCP/IP, no generally available
software support exists for CCSDS. Similarly, no readily
available inexpensive hardware exits for Spacewire.
Tools—A growing array of software tools are becoming
available.
Support—A growing body of support packages are
becoming available as well.
Communications—Despite the good news provided by
SDR’s like Vulcans’, this is still our most troublesome area.
The current licensing procedure is problematic at best, and
will never work for future “swarms” of satellites. Likewise,
it is not clear how operators will deal with the logistics of
“swarms” passing overhead. Additionally, even as the size
of satellites continues to shrink, the amount of data they can
produce is growing. The current crop of 3U CubeSats are
growing beyond UHF, and probably even S-Band. The
6
operations and communication engineers are going to have
to start thinking completely out of the box on this one.
In this vein of thinking out of the box a suggestion was
made by John Ploschitznig that the possibility of using the
existing cell networks be investigated. Additional antennas
could be placed on each cell tower, only directed upward. It
was not clear to the assembled group if this was in any way
workable, but it demonstrates the extent to which we will
have to change our thinking in order to solve the looming
communications problem.
5. APPLICATIONS TRACK
The Applications track was led by Sam Myers Sims from
The Aerospace Corporation. Sims is part of the Space Test
Program (STP) and Mission Design Support (MDS) for
access to space programs. The focus of this track was the
identification of user requirements and thoughts regarding
operations planning in terms of the following areas:
Fleet control
Simulations and modeling
Enhanced ground segment
Enhanced communications
Concepts
While the technological landscape of small, multiple
spacecraft operated in a coordinated manner is still in
development, a number of near- and long-term applications
have been described and discussed to serve as guideposts for
the development of PPMO architectures and concepts. A
selection of those discussed during the PPMO Workshop
summarized in the following paragraphs.
Cheaper Space Operations with Nanosatellites while
Keeping Operational Requirements—Capt. Peter Mastro
from the Air Force Space and Missile Systems Center
(SMC)/XR. The SMC is interested in solutions for mission
operations that satisfy cost optimization and the following
requirements for Operational Mission Operations:
Compatible with information assurance and encryption
requirements,
Communication frequencies that support higher data
rates (like UHF, VHF), and compatible with existing
operation architectures,
Lower man-hours required for operations, expecting
large number of spacecraft in a specific constellation,
Accept short spacecraft acquisition times as a
successful contact with the spacecraft, for low altitude
constellation missions.
The SMC is also developing 2-3U CubeSats with the
primary objective to understand the operation of NanoSats
and as a secondary objective as a space-weather mission.
Low Cost, Mobile, Instant Ground Station Systems (MC3)
—Dr. Jim Newman from the Naval Post Graduate School
and Naval Research Laboratory (NRL) introduced the
Mobile CubeSat Command and Control (MC3). It is a low
cost, mobile, instant ground station system that can be easily
networked over the Interned to increase the operations array.
The MC3 will also support academic applications.
The MC3 interfaces with top-level architectures for satellite
operations using dual antennas in a portable unit that can be
installed anywhere as needed. It includes appropriate levels
of security and can be controlled remotely or locally, where
locally the operator will have priority. It is connected via a
Virtual Private Server (VPS) to a central node in Blossom
Point.
NRL has developed the Common Ground Architecture
(CGA) to support all aspects of the satellite development
lifecycle from box level testing through operations and also
the MC3. CGA is based on databases and scripts and allows
for automated ground operations. This automates the ground
station support by loading mission plans and where only
engineers have to work, lowering the operations cost. The
MC3 also includes the drivers for different radios and
motors and different configurations envisioned (e.g. MC3
colony II bus).
“The Soldier is the Ground Terminal” – Satellite Control is
Distributed to the End User—Mr. Nick Chando from the
Army Space and Missile Defense Command (SMDC)
presented the interest in the-field support of the disarmed
soldier. The goal is to give as much capability to the soldier
(the end user) in the ground when they are left with a low
power radio and by using small spacecraft. A Vulcan SDR
is being developed for a 3U and 6U CubeSat and a future
project is in development for a constellation of 16 CubeSats
in a near equatorial orbit to be used as relays and with the
objective of increasing autonomy with little ground work.
A Small, Low Cost, Technology (Non-Operationally
Focused) Ground Segment—Rick Murphy from the DoD
Space Test Program (STP) talked about how STP is taking
proactive measures to standardize spacecraft design and
construction and is also looking for the future standards
being adopted like the Evolved Expendable Launch Vehicle
(EELV) Secondary Payload Adapter, also known as ESPA.
Understanding that CubeSats will not go away soon and that
different payloads are being developed for use in CubeSats,
the Army is dedicating more and more resources into the
development of such satellites. The STP is looking for lower
cost operations and development that are still compatible
with different small spacecraft and technology development
missions by being flexible and extensible.
7
Amateur Band Frequencies—Mr. Jared Clements from the
AFRL University Nanosats Program presented the Nanosats
Program and showed how it is working with 25 universities
and leveraging CubeSat development and technologies.
Eleven different proposals are selected each year for
development and are put on the Space Experiments Review
Board (SERB) to fly. The proposals and the students get
$110k for 2 years. The program also has the ability to
network and cooperate with other universities, including
international universities. The main requirement to be
selected is that the missions are to be military relevant.
There is a strong emphasis on promoting the usage of
Amateur radio band frequencies because it is easy to obtain
compared to other licenses. No license is required for the
900MHz or 2.4GHz when operating below a certain power
level. This means low cost but also low bandwidth.
Meteorology Band – 460-470 MHz—Dr. Chuck Swenson
from the Utah State University Space Dynamics Laboratory
is proposing the usage of the Meteorology band (460 to 470
MHz) for CubeSats. There are various problems with the
frequencies allocation in the more frequently used bands
(especially the S-band). Just the frequency allocations can
also a problem because the CubeSat orbit can easily change
according to the launch.
There is available 8.1MHz of spectrum inside the specified
band that is very valuable as long as the density spectrum is
kept. The meteorology band allows for decent downlink
rates and today many dishes are compatible with this
band/frequency. The idea of standardizing the Nanosatellites
communications into this band was suggested, as a step
forward to make this happen as soon as possible, so the
design of the spacecraft would be done accordingly. This
reduces and eliminates the licensing issues for small groups
like universities.
Nanosatellites and the Ability to Operate a Swarm of
CubeSats Simultaneously—Mr. John Hines is the manager
of the Nanosats and Edison Small Spacecraft Demonstration
Program at NASA Ames. These programs have defined a
3U CubeSat standard bus, the GeneSat that was used on
other missions.
Some of the issues encountered in the small satellite
operations are thermally related but more critically with the
communications bandwidth because there is more and more
data that needs to be transmitted. The software-defined
radios are being used and will be more common for small
satellites. New Nanosat missions are being developed at
NASA Ames like the Collapsible Dobson Space Telescope
and the PhoneSat that envisions putting an Android phone
in space.
The space technology game-changing challenges and the
search for the new ways to do space technology can be
motivated by initiatives like the Edison small satellite
Demonstration Mission Program. Candidate mission
capability demonstrations for Nanosatellites can be
deformable aperture for remote observations, distributed
apertures, fractional satellites, small telescopes and more
importantly the ability to operate a large swarm of CubeSats
simultaneously. All these initiatives are being seriously
considered. In all cases distributed and networked ground
systems are of major importance for mission operations
support.
Final Comments about the Applications Track
Another dimension considered during the Applications track
is the repurposing of existing ground assets to be compatible
with advanced technologies as they come into operation.
This could result in a major push if in fact universities
and/or others could be provided access to inactive or
obsolete government assets.
Finally, it was suggested that the various end users identify
areas of overlap, and then cooperate on certain systems
development activities in order to accelerate the realization
of a capable, scalable, set of standards for ground
architectures that will support the numerous applications
that are currently envisioned, while attempting to anticipate
the future applications that are yet unknown.
6. FUTURE OF SMALL SAT OPS - COSMOS
The HSFL at the University of Hawaii at Manoa, in
collaboration with NASA Ames Research Center, is
developing COSMOS, a set of software tools and hardware
that is designed to primarily support the development and
operations of one or more small spacecraft. [2] COSMOS
will be particularly suited for organizations with limited
development and operations budget, such as universities.
COSMOS is a suite of software and hardware tools that
enables the operations team to interface with the spacecraft,
ground control network, payload and other customers in
order to perform mission operations functions. COSMOS is
being designed to easily be adapted for new spacecraft or
installation in new mission operations centers (MOCs).
Some of the basic elements of COSMOS have been
developed at least to the prototype stage, while other
elements are still in the conceptual stage. Although all the
basic mission operations functions will be developed as part
of COSMOS, it is also being designed to accept external
modules (applications) as part of its “Plug-and-Play”
architecture.
The COSMOS system will initially be installed in the HSFL
and ARC MOCs and used in support of their small LEO
satellites. However, the versatility of COSMOS is
demonstrated in that it is being modified to support an
international lunar mission in a Phase 0 study. The primary
COSMOS mission monitoring and control tool, MOST, is
being used for monitoring and controlling the spacecraft,
lander, and lunar rover.
COSMOS Architecture and Design
The central pieces of this architecture are the visualization
8
tools, support tools, and underlying programs that produce
and manipulate the data needed by the rest of the tool sets. It
combines both the software and unique hardware needed to
support mission operations, including an operations test bed
(OTB) and simulators. The simulators are all software
applications, and the OTB combines simulators with
spacecraft hardware where possible to mimic as closely as
possible the reaction of the spacecraft to commands and
operational states.
The basic philosophy behind the construction of this
architecture is that its elements (tools and other programs)
will be easy to port to a new location and to modify for
operating with new satellites. This is enabled by being an
“open architecture.” This approach means not only that the
source code of its major elements and structure are
available, but also that it is designed to accept external
modules (which may not have source code available) as
plug-ins through standard, well-defined interfaces in order
to increase the overall capability of COSMOS for the
desired application. However, it is recognized that there
could be ITAR issues with COSMOS since it is designed to
help control satellites. Therefore, a more limited definition
of “open architecture” is used than the common one of
having the source code in the public domain. Distribution of
the COSMOS source code can be limited to only those
entities (US government agencies, companies, or
universities) which are allowable within ITAR restrictions.
However, for those entities, the COSMOS source code will
be available. Hopefully, in the future this restriction can be
relaxed as International Traffic in Arms Regulations (ITAR)
restrictions are redefined or COSMOS is determined to not
be an export-controlled product.
COSMOS is a suite of software and hardware tools that
enables the Mission Operations Team (MOT) to interface
with the spacecraft, ground control network, payload and
other customers in order to perform the mission operations
function. The basic COSMOS functional architecture is
shown in Figure 1. Within COSMOS the following major
functions are performed/supported: mission scheduling;
contact operations; data management, mission analysis;
simulations (including the OTB); ground network
monitoring and control; payload operations, flight dynamics
(including orbital and attitude); and support of system
management and quality assurance. The description given
here is for a full implementation of COSMOS to support
flight operations, but some of the features may not be
required by a particular MOC or mission.
A computer is typically placed at each mission ground
station to provide the interface between COSMOS and the
ground station for data management (both to and from the
ground station), and to monitor and possibly control the
operations of the ground station. The various tools of
COSMOS provide the graphical interface between the MOT
and the COSMOS functions. The MOT communicates with
spacecraft engineers to assist in state-of-health (SOH)
matters, such as anomaly resolution, and reports of the
condition of the spacecraft and receives in return any
Figure 1: COSMOS Functional Architecture
9
constraints or tasking that may be required. The MOT also
communicates with the various payload customers to
receive reports on the status of the instruments and mission
accomplishment goals, as well as to receive payload tasking
requests. COSMOS uses websites or other means to allow
the spacecraft engineers and customers to monitor the status
of the mission directly without having to go through the
MOT.
The functional flow block diagram of COSMOS is shown in
Figure 2. There are four major processes in mission
operations that are supported by COSMOS:
(1) Mission Planning and Analysis which also includes
command sequencing and the simulators and operations
testbed;
(2) Contact Operations which includes pre-contact
operations, real-time contact operations, and post-contact
operations both in the MOC and the ground network;
(3) Data Management which includes transfer of all data
throughout COSMOS and between COSMOS external
locations; data processing, such as engineering units
conversion and Level 0 data processing; and data archiving;
(4) Mission Analysis which includes support by the MOT to
analyze and trend spacecraft and ground network SOH data,
orbital and trajectory data, and mission accomplishment
data to help determine the mission success Measures of
Effectiveness (MOEs). The results of the Mission Analysis
process are fed back to the mission planners, spacecraft
engineers (especially for resolving spacecraft anomalies),
mission management, and customers.
COSMOS Tools Overview
The tools of COSMOS are the software applications with
which the human operators interact to control COSMOS and
the mission operations processes. Each of the tools is
described below.
COSMOS EXECUTIVE—There needs to be a way to
monitor and control the operation of the entire COSMOS
system and possible to launch or terminate various
COSMOS tools. The COSMOS EXECUTIVE (CE) fulfills
this function. It shows which elements of COSMOS are
running, which mission/spacecraft they are controlling, their
current status and level of activity. From the CE you can
start up any of the COSMOS tools and transfer into that tool
if desired as a new computer session, which will put the CE
into background mode, possibly within a separate window if
desired. The CE also provides another function – it is the
way to monitor multiple satellites and ground stations
simultaneously from a single tool.
Mission Planning and Scheduling Tool (MPST)—The
MPST converts mission status and tasking inputs into
executable command loads or sequences, schedules, and
timelines. The MPST provides a top-level interface to the
mission planner (human) and consists of the following
major tools: Scheduler (produces the long- and short-term
plans and schedules), Timeliner (produces the timeline), and
Command Script Generator (produces the command script
or sequence that is uploaded to the spacecraft). An example
of the application of the “Plug-and-Play” paradigm in
COSMOS is the inclusion of the independent mission
Figure 2: COSMOS Functional Flow Block Diagram
Figure 2. COSMOS Functional Flow Block Diagram
10
planning module developed by Riverside Research called
the Automated Collection Planning Tool (ACPT). This tool
is built on AGI’s STK engine and is being used for the
DoD’s Multispectral Thermal Imaging (MTI), TACSAT-3,
and other missions. This optional module provides a
powerful addition to the MPST to help plan remote sensing
missions while considering constraints, criteria, priorities,
and resource utilization.
Operations Test Bed and Simulators—The COSMOS
Operations Test-Bed uses an open-source system
architecture that integrates hardware and software
components and tools to operate a low cost Satellite System
Simulator (e.g. FlatSat) which can be integrated into the
MOC setup for command scripting testing, personnel
training, mission rehearsals and anomaly resolution. The
OTB has tools for satellite technology integration and
development that allows for cheaper satellite subsystem
integration and testing. The OTB tools are based on COTS
that are affordable to universities while some tools are being
developed under the COSMOS project using proven
standards and made available to the small sat community.
The OTB is part of the four major processes in mission
operations that are supported by COSMOS, namely the
Mission Planning and Scheduling, Real-time contact
operations, mission analysis, and anomaly resolution.
Mission Operations Support Tool (MOST)—This is the
primary element of COSMOS and is the visualization tool
designed specifically for supporting real-time operations. [4]
However, MOST can also be used for supporting the
following major operations functions: (1) spacecraft &
payload monitor & control; (2) mission planning; (3)
simulations & rehearsals; (4) trending & analysis; and (5)
anomaly resolution. MOST is based on the LUNOPS
program that was developed to support both LEO and lunar
operations for the Clementine mission in 1994.[3] Features
of LUNOPS were incorporated into the design of some JPL
mission operations software.
Ground Segment Control Tool (GSCT)—This is a graphical
interface for monitoring and controlling the ground network.
GSCT includes all the pertinent information of each ground
station, such as location, antenna type, contact information
as well as a status for the ground station. The GSCT
displays the ground station configuration for an upcoming
contact (e.g., which files are waiting for upload, frequency
setting, ephemeris file used for open-loop tracking). It also
allows monitoring of the ground station status during a
contact, displaying the antenna pointing angles, actual
versus predicted antenna pointing, carrier signal detection
and lock status, signal strength and data rate, etc. GSCT also
allows the user in the MOC to send commands to the
ground station as required. The GSCT is designed to view
the ground segment/network data in a manner that allows
the user to understand the information quickly and easily. It
is possible to view all of the ground stations on a map with
their statuses easily discernable. The input to GSCT comes
from users, MOST and the customers. The output goes to
the customers and the Data Management System (DMS).
Data Management Tool (DMT) —Files are the primary
method of data flow between elements of COSMOS.
Central storage and dissemination of the files is through a
Data Management System (DMS) whose function is to:
Accept files for delivery to other parts of the system
Store files for long term access
Provide access to stored files
Forward files to other parts of the system
The DMS will be able to manage multiple spacecraft,
distinguishing between them by spacecraft designator. It
stores both informational data, and longitudinal data, such
as payload data and telemetry. Longitudinal data are
accessible by date of creation. The DMS is split between a
Data Management Agent (DMA), and a Data Management
Tool (DMT). The DMA stores files in a simple directory
structure, receiving them via standard file transfer protocols.
These files are available either through the local file system,
in the case of the MOC, or through standard file transfer
protocols. Control of the DMA is through a GUI-based
control program, the DMT. The DMT allows monitoring
and control of the DMA, as well as adding additional
features for analyzing data storage and flow.
7. SUMMARY
The PPMO Workshop held at San Jose State University on
May 16-17, 2011 successfully accomplished its objectives
to the extent that was expected. However, the objectives
defined before the workshop have not been completed – this
workshop is considered to be just a first step to addressing
the problem of performance- and cost-effective mission
operations to support the burgeoning small satellite
business.
Some of the major stakeholders in small satellites and their
operation such as NASA, NRO, and the DoD addressed the
workshop. Many organizations were identified that are
interested in responsive and effective operations of
spacecraft, especially multiple small spacecraft, using
ground systems that are designed especially for porting to
new MOCs and for modifying for new spacecraft. The
current state of the art was explored in such mission
operations systems (which are most likely to be Plug-and-
Play architectures), with identification of some existing
systems, such as JPL’s AMMOS, GSFC’s GMSEC, NRL’s
MC3, and ARC’s MCT. Systems are that currently in
development that may meet this need were examined, such
as HSFL’s COSMOS and ESA’s GENSO.
During the workshop issues (interfaces, protocols,
proprietary and security issues, etc.) were identified that will
be faced by such systems and possible first order solutions
11
to be investigated. The workshop also identified and
characterized possible future applications for such systems,
such as for fleet (constellation) control, simulations and
testing, and enhancements to the ground segment and
communications.
Two major issues that were identified and discussed were
standardization and communications, especially frequency
allocation. Both of these in particular need considerably
more attention in the future.
The workshop was very successful in networking between
the players in this field and possible establishment of
collaborations that will benefit the participants and the
industry as a whole.
This paper is evidence of successfully accomplishing the
objective to produce a white or conference paper on the
results of the workshop.
As stated earlier, the workshop did not conclude the
objectives, but took a promising start in accomplishing
them. This was a necessary start, but much more dialogue
and collaboration is needed before the problems of “plug
and play” mission operations are solved. The way forward
includes additional workshops, some of which will be
specialized instead of general as was the one in 2011. It is
intended to also generate additional papers both on the
results of the workshops and especially to report on the
implementation of the methods identified by the
workshops..
REFERENCES
[1] PPMO Workshop Web site: http://ppmo.arc.nasa.gov/
[2] Sorensen, T.C., E.J. Pilger, M.S. Wood, M.A. Nunes,
“Development of a Comprehensive Mission Operations
System Designed to Operate Multiple Small Satellites,”
SSC11-IX-3, 25
th
Annual AIAA/USU Conference on
Small Satellites, Logan, UT, 8-11 August, 2011.
[3] Sorensen, T.C., et al, “Effective Science Mission
Planning and Operations - The Clementine Approach,”
Paper RAL.GS.31, 1st Annual Reducing the Cost of
Space Ground Systems and Operations Symposium,
Rutherford-Appleton Laboratories, UK, June 1995.
[4] Sorensen, T.C., E.J. Pilger, M.S. Wood, E.D. Gregory,
M.A. Nunes, “Development of the Mission Operations
Support Tool (MOST),” AIAA 2010-2230, SpaceOps
2010 Conference, Huntsville, AL, 25-30 April, 2010.
GLOSSARY OF ACRONYMS
ACPT
Automated Collection Planning Tool
AFRL
Air Force Research Laboratory
AIAA
American Institute of Aeronautics and
Astronautics
AMMOS
Advanced Multi-Mission Operations System
ARC
Ames Research Center
CCSDS
Consultative Committee for Space Data
Systems
CE
COSMOS Executive
CGA
Command Ground Architecture
COSMOS
Comperhensive Open-architecture Mission
Operations System
COTS
Commercial Off The Shelf
DMA
Data Management Agent
DMS
Data Management System
DMT
Data Management Tool
DoD
Department of Defense
EELV
Evolved Expendable Launch Vehicle
EPSCoR
Experimental Program to Stimulate
Competitive Research
ESA
European Space Agency
ESPA
EELV Secondary Payload Adapter
GENSO
Global Educational Network for Satellite
Operations
GEO
Geostationary Earth Orbit
GMSEC
Goddard Mission Services Evolution Center
program
GSCT
Ground Segment Control Tool
GSFC
Goddard Space Flight Center
GUI
Graphical User's Interface
HSFL
Hawai‘i Space Flight Laboratory
INS
Inertial Navigation System
ITAR
International Traffic in Arms Regulations
JPL
Jet Propulsion Laboratory
JSON
Java Script Object Notation
LEO
Low Earth Orbit
MC3
Mobile CubeSat Command and Control
MCT
Mission Control Technologies
MDS
Mission Design Support
MOC
Mission Operations Center
MOE
Measure of Effectivness
MOST
Mission Operations Support Tool
MOT
Mission Operations Team
MPST
Mission Planning and Executive Tool
MTI
Multispectral Thermal Imaging
NASA
National Aeronautics and Space
Administration
NRL
Naval Research Laboratory
NRO
National Reconnaissance Office
OCAMS
Orbital Communications Adapter Monitoring
System
OTB
Operations Test Bed
PPMO
Plug and Play Mission Operations
12
SDR
Software Defined Radio
SERB
Space Experiments Review Board
SJSU
San Jose State University
SMC
Space and Missile Systems Center
SMDC
Army Space and Missile Defense Command
SOH
State-Of-Health
STK
Satellite Tool Kit
STP
Space Test Program
SW
Software
TCP/IP
Transmission Control Protocol/Internet
Protocol
TDRS
Tracking and Data Relay Satellite
UHF
Ultra High Frequency
VPS
Virtual Private Server
XML
Extensible Markup Language
BIOGRAPHIES
Originally from Australia, Dr.
Sorensen received a D.E. degree in
Aerospace Engineering from
University of Kansas in 1979. His
doctoral project was on Pioneer
Venus at NASA Ames. At NASA JSC
he was a Space Shuttle guidance and
control engineer, worked in Mission
Control as assistant Flight Director,
and finally was a software engineering manager
supporting Shuttle missions. In 1990 he joined Bendix
Field Engineering in Alexandria, Virginia, as
Observations Manager of the DoD’s LACE satellite. In
1994, he was the Lunar Mission Manager for the
DoD/NASA Clementine lunar mission for which he
received the NASA Medal for Exceptional Scientific
Achievement. He was the program manager for the NRL
Space Systems R&D contract under which the USAF
MSTI-3 satellite was operated. He was then technical
architect and for development of Honeywell’s global
satellite ground network, DataLynx. From 2000-2007 he
was on the faculty of the KU Aerospace Engineering
Department. In 2007 he joined the University of Hawaii
as a Specialist and project manager in the Hawaii Space
Flight Laboratory. He is a Fellow of the American
Astronautical Society, a Fellow of AIAA, and is the
Director of the AIAA Space and Missiles Group.
Mr. Bruce Yost is the acting
Program Manager for the Edison
Small Spacecraft Flight
Demonstration Program within the
Office of the Chief Technologist at
NASA. He began his career at the
Kennedy Space Center working in
payload processing on the Space
Shuttle and has also worked at NASA
HQs. After moving to Ames
Research Center, he has worked on International Space
Station (ISS) payloads and, recently has served as a
project and mission manager in the Nanosatellite
Missions Office where he held mission management
responsibilities for NASA’s cubesat spacecraft dating
back to Genesat.
Joan Differding received her B.A.
in Physics from Swarthmore
College in 1985 and an M.S. in
Medical Information Sciences
from Stanford University in 1988.
She is the Director of the Multi-
Mission Operations Center
(MMOC) at the NASA Ames
Research Center in Moffett Field,
California. The MMOC supports
operations of Ames space missions such as LCROSS,
Kepler, SOFIA, LADEE and IRIS. She has been at Ames
for 17 years and has lead software development teams
and information standardization efforts on the
Constellation Program, the Mars Exploration Rovers
mission and Ames wind tunnel operations projects.
Eric Pilger received a B.A. in
Astrophysics from Williams College
in 1982 and an M.S. in Astronomy
from The University of Hawai‘i
Manoa in 1986. He was with the
NASA Infrared Telescope Facility
for 8 years where he developed
software for instrumentation and
telescope control. He then moved to
the Hawai‘i Institute of Geophysics
and Planetology as a Software Engineer where he has
developed numerous applications for remote data
acquisition, analysis and visualization. For the last 3
years, he has also served the role of Lead Software
Engineer for the Hawai‘i Space Flight Laboratory.
13
Miguel Nunes received his B.S. in
Aerospace Engineering from the
Instituto Superior Técnico (IST)
from the Technical University of
Lisbon, Portugal and his M.S. in
Mechanical Engineering from the
University of Hawai’i at Manoa
(UHM), USA. He is currently
enrolled in the doctoral program
in the Mechanical Engineering
department at UHM. Since 2009, Miguel has worked as a
Research Assistant at the Hawai’i Space Flight
Laboratory in the development of the HawaiiSat-1 as the
lead Thermal Engineer, Space Mission Analyst and
Software developer. More recently he started the
development of the Operations Test Bed for the COSMOS
project.
