SSC11-IX-3

Development of a Comprehensive Mission Operations System Designed to Operate

Multiple Small Satellites
Trevor C. Sorensen, Eric J. Pilger, Mark S. Wood, Miguel A. Nunes
Hawaii Space Flight Laboratory
University of Hawaii, 1680 East-West Rd. POST 501, Honolulu, HI 96822; 808-956-4715
Sorensen@[Link]

Bruce D. Yost
NASA Ames Research Center
Nanosat Missions Office, Engineering Directorate, Moffett Field CA 94035; 650-604-0681
[Link]@[Link]

ABSTRACT
The Hawaii Space Flight Laboratory (HSFL) at the University of Hawaii at Manoa, in collaboration with NASA
Ames Research Center (ARC), is developing COSMOS (Comprehensive Open-architecture Space Mission
Operations System), a set of software tools and hardware that is designed to primarily support the development and
operations of one or more small spacecraft. 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
(including external modules) that enables the operations team to interface with the spacecraft, ground control
network, payload and other customers in order to perform the mission operations functions including mission
planning and scheduling; contact operations; data management and analysis; simulations (including the operational
testbed); ground network control; payload operations; flight dynamics; and system management. 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. The COSMOS tools will initially be installed in the HSFL and ARC MOCs and used in
support of three of their small satellites.

INTRODUCTION space architectures are being considered using small

spacecraft that were not even feasible using monolithic
For many years following the first spacecraft launches
space platforms.
by the original space faring nations, spacecraft size and
complexity increased as more and more functionality The ongoing evolution of small and very small
was driven into each satellite and robotic explorer. We spacecraft, typified by the university-developed
assume that this early trend was fueled at least partly by Cubesat platform, is leading the charge for the
the fact that larger and larger launch vehicles could be transformation of the space technology and the
constructed and launched to orbit and nations were aerospace industries. Cubesats, and small spacecraft
willing and able to build these rockets.. The budgets platforms that can be accommodated on launch vehicles
and political environments of this era allowed, and possessing excess launch performance margin as a
possibly even encouraged this trend. secondary payload, embody a number of attractive
features, the biggest of which is low development cost.
Today however, we are witnessing a counter-trend with
Similarly, with the creation of adapters and mechanisms
regards to spacecraft size. Resources required to
such as the Poly Picosat Orbital Deployer (P-POD),
develop and then lift large spacecraft on exceedingly
developed by California Polytechnic University, San
costly launch vehicles are becoming increasingly
Luis Obispo,1 for the deployment of Cubesats, and
constrained. But perhaps even more important, large
other devices such as the motorized Light Band from
spacecraft are no longer the only platforms available to
Planetary Systems Corporation,2 the integration
execute scientific, technological, or defense missions.
complexity and launch related aspects for small
Partly driven by the ever-increasing capabilities of the
satellites accommodations are becoming relatively
shrinking integrated circuit and related technologies,
small spacecraft can now be seriously considered to routine. However, as more and more small and very
small spacecraft are being utilized by military and civil
perform many of the missions that were traditionally
space, as well as educational institutions, there is a
the sole domain of large spacecraft. Further, novel

Sorensen 1 25th Annual AIAA/USU

Conference on Small Satellites
growing need for a low-cost, yet flexible method to COSMOS functions are available, they come at a high
operate these small spacecraft, potentially buy-in and maintenance costs. A second common flaw
simultaneously as a constellation. Since the same cost of many existing tools is that they are of limited scope.
constraints and pressures are at work, and expensive Often two different tools that perform greatly similar
operations solution coupled with a low-cost functions will be required at different phases of the
development and launch capability does not make process. This serves not only to exacerbate the cost
sense. Therefore, we need to apply the same innovative problem, but also leads to problems with integration,
forces and techniques to the ground segment portion of and with training. Finally, some areas, especially in
the architecture that we have successfully implemented mission support, are covered only by proprietary
for the space segment. We anticipate that these solutions, or not at all.
innovative forces will take the form of novel
development tools and environments, automation and Although many universities operate their own small
smart systems and flight software, flexible ground satellites, the operations systems are usually patched
networks and equipment, and universally accepted together using available general COTS applications,
standards and approaches in order to enable low cost, such as MATLAB®, LabView®, and MS Excel®, and
widely accessible ground operations capabilities that are designed to be only sufficient to meet their
are consistent with and build upon the momentum and immediate needs. COSMOS provides a solution that is
value of the small spacecraft revolution being optimized from the beginning for mission
operations and to add new and different types of
The Hawaii Space Flight Laboratory of the University satellites with minimum effort.
of Hawaii at Manoa is currently developing a
comprehensive open set of software tools with Other systems similar to COSMOS exist, such as
supporting hardware that is designed to primarily ESA‟s European Ground Operation System
support the operations of one or more small spacecraft, (EGOS)/Spacecraft Control Operation System (SCOS);
but can also perform an important role in the design, JPL‟s Advanced Multi-Mission Operations System
development, and testing phases of spacecraft missions. (AMMOS); and GSFC‟s General Mission Analysis
This set of mission operations tools operate within the Tool (GMAT). However, each of these has a problem
architecture named COSMOS (Comprehensive Open- for use with small satellite (university class) missions,
architecture Space Mission Operations System). such as restricted use, or unavailability of source code
COSMOS is being developed by HSFL in collaboration with requirement to have the system customized by
with NASA Ames Research Center (ARC) under a provider. ESA‟s Global Educational Network for
three-year NASA EPSCoR grant beginning in Satellite Operations (GENSO) is a university class
September, 2010. network currently being developed by several
universities, but has some usage and operations
COSMOS will be particularly suited for small limitations that are being addressed by COSMOS.
organizations with a very limited development and
operations budget, such as universities. However, it is COSMOS ARCHITECTURE AND DESIGN
not just restricted to universities or educational The central pieces of this architecture are the
activities. The COSMOS tools will initially be installed visualization tools, support tools, and underlying
in two mission operation centers (MOCs) at HSFL and programs that produce and manipulate the data needed
NASA ARC, and used in support of several small by the rest of the tool sets. It combines both the
satellites from both organizations. software and unique hardware needed to support
mission operations, including an operational test bed
Spacecraft design and construction and subsequent (OTB) and simulators. The simulators are all software
mission support are all dependent on a number of applications, and the OTB combines simulators with
unique protocols and technologies generally not found spacecraft hardware where possible to mimic as closely
in Commercial-Off-The-Shelf (COTS) software. At the as possible the reaction of the spacecraft to commands
same time, although there is some significant overlap and operational states.
between the needs of all these activities, similar
technologies are often used in markedly different ways, The basic philosophy behind the construction of this
making tools incompatible at different phases, and architecture is that its elements (tools and other
leading to duplication of effort. As a result, tools for programs) will be easy to port to a new location and to
spacecraft design and mission support suffer from a modify for operating with new satellites. This is
number of flaws from the point of view of small enabled by being an “open architecture.” This approach
missions developers. First among these is cost. While means not only that the source code of its major
commercial packages capable of performing the elements and structure are available, but also that it is

Sorensen 2 25th Annual AIAA/USU

Conference on Small Satellites
designed to accept external modules (which may not stage and require extensive trade studies and design
have source code available) as plug-ins through before development can begin.
standard, well-defined interfaces in order to increase the
overall capability of COSMOS for the desired COSMOS is a suite of software and hardware tools that
application. However, it is recognized that there could enables the Mission Operations Team (MOT) to
be ITAR issues with COSMOS since it is designed to interface with the spacecraft, ground control network,
help control satellites. Therefore, we use a more limited payload and other customers in order to perform the
definition of “open architecture” than the common one mission operations function. The basic COSMOS
of having the source code in the public domain. We functional architecture is shown in Figure 1. Within
intend to provide COSMOS to only those entities (US COSMOS the following major functions are
government agencies, companies, or universities) which performed/supported: mission planning and scheduling;
are allowable within ITAR restrictions. However, for contact operations; data management, mission analysis;
those entities, the COSMOS source code will be simulations (including the operational testbed); ground
available. Hopefully, in the future this restriction can be network monitoring and control; payload operations,
relaxed as ITAR restrictions are redefined. flight dynamics (including orbital and attitude); and
support of system management and quality assurance.
As a fully functional COSMOS is an ambitious project, The description given here is for a full implementation
we have planned an evolutionary approach, where the of COSMOS to support flight operations, but some of
software framework and primary tools needed to the features may not be required by a particular MOC
support a spacecraft missions are developed first, with or mission.

Figure 1: COSMOS Functional Architecture

additional tools and features added later as needed and A computer will be in place at each mission ground
resources allow. To date some of the basic elements of station to provide the interface between COSMOS and
COSMOS have been developed at least to the prototype the ground station for data management (both to and
stage, while other elements are still in the conceptual from the ground station), and to monitor and possibly

Sorensen 3 25th Annual AIAA/USU

Conference on Small Satellites
control the operations of the ground station. The 3. Data Management which includes transfer of all
various tools of COSMOS provide the graphical data throughout COSMOS and between COSMOS
interface between the MOT and the COSMOS external locations; data processing, such as
functions. The MOT communicates with spacecraft engineering units conversion and Level 0 data
engineers to assist in state-of-health (SOH) matters, processing; and data archiving;
such as anomaly resolution, and reports of the condition 4. Mission Analysis which includes support by the

Ground
Segment
Control Tool
GSCT

Figure 2: COSMOS Functional Block Diagram

of the spacecraft and receives in return any constraints MOT to analyze and trend spacecraft and ground
or tasking that may be required. The MOT also network state-of-health (SOH) data, orbital and
communicates with the various payload customers to trajectory data, and mission accomplishment data to
receive reports on the status of the instruments and help determine the mission success Measures of
mission accomplishment goals, as well as to receive Effectiveness (MOEs). The results of the Mission
payload tasking requests. COSMOS will have websites Analysis process are fed back to the mission
or other means to allow the spacecraft engineers and planners, spacecraft engineers (especially for
customers to monitor the status of the mission directly resolving spacecraft anomalies), mission
without having to go through the MOT. management, and customers.

The functional flow block diagram of COSMOS is Figure 2 also shows the primary tools that COSMOS
shown in Figure 2. There are four major processes in provides for interfacing with the MOT to control these
mission operations that are supported by COSMOS: operations processes. The rest of COSMOS provides
1. Mission Planning and Analysis which also includes the underlying processes and engines that move,
command sequencing and the simulators and generate, and process the data used by COSMOS and
operations testbed (OTB); the MOT. Each of the major software tools and
2. Contact Operations which includes pre-contact programs that make up COSMOS will be described in
operations, real-time contact operations, and post- the following sections along with our approach to
contact operations both in the MOC and the ground developing them. The various tools, major
network; agents/engines, and other software of the COSMOS

Sorensen 4 25th Annual AIAA/USU

Conference on Small Satellites
system are shown in Figure 3 and will be explained number of support routines upon which the higher
later in this paper. layers can be built. These routines provide the basic
functionality as detailed below. The next two layers,
Tools Programs and Agents, are roughly parallel. Both build
MPST
Mission Planning
MOST
Mission Operations
GSCT
Ground Segment
DMT
Data Management Analysis Tools Misc. Tools on the Foundation layer to provide more advanced
& Scheduling Tool Support Tool Control Tool Tool
functionality. The main difference is that Programs are
SCHEDULER Orbit
Generate Plan
and Schedules TBCT
Testbed
SC SOH
Ephemerator one-shot deals that perform their function and exit,
TIMELINER
Generates Single
Control Tool
COSMOS
Mission
Quality
Assurance
while Agents are persistent, communicating with the
Orbit Timeline

ACPT
EXEC
Orbit
Report rest of the world to receive their orders. The fourth
Automated Collection Generation
Planning Tool
layer is Tools. Tools will incorporate both Foundation
Ground Segment COSMOS Editor
CSG
Command Script
Generator
layer functions, the launching of Programs, and
Agents communications with Agents to perform complex
Data
Manager
Simulators OTB Engine
Space Dynamics
Engine
Ground Segment
Manager
functions in direct interaction with humans.
Other Software
Libraries Devices Misc.
OTBPrograms
Engine
… … Function
The COSMOS software will have to provide a large
Figure 3: COSMOS Elements amount of functionality, some of which is not yet fully
defined. However, the COSMOS development team has
initially identified certain key areas of function that will
SOFTWARE DESIGN be absolutely necessary. Those already identified are
The overall goal of the COSMOS software design is to listed below:
create a unified set of software elements that fulfills the  Higher level mathematics, especially in the area of
following roles: vector and matrix manipulation. Along with this is
 Provide the functionality required for the design the need to define data types that work with these
and operation of the majority of small satellites functions.
 Provide this functionality in a uniform manner  Conversions between different coordinate systems,
across the life cycle of satellite design, for both position and attitude. These also require
development and operation their own specific data types.
 Make the functionality readily accessible through  Conversion between different time systems.
the use of commonly available protocols and  Orbital calculations.
standards, and an open software approach.  Simulations, including orbital and attitude
 Support existing satellite software either through propagation, thermal, power, etc.
direct incorporation, or the creation of translating  Protocol support
interfaces.  Agent support

To achieve the above goals, the COSMOS development Protocols and Standards
team has both adopted, and defined a set of rules to COSMOS is first and foremost a Unix-based package.
govern the development process. The purpose of these In respect of this, and the desire to have as much
rules is to constrain development along relatively control over the software as possible, the Foundation
straightforward pathways, while retaining the flexibility layer and all Programs and Agents will be written in
needed to achieve the desired goals. For the purposes of POSIX compliant C. In order to support the various
this section, these rules will be divided into the three upper level elements that will require C++, all code will
broad categories of Type, Function, and Protocols and be compiled against the GNU G++ compiler. This will
Standards. Type will describe the various levels of not preclude the introduction of libraries written in
software development that will be provided within FORTRAN, where unavoidable. In addition, support
COSMOS. Function will describe the functionality for Java will be investigated in later phases.
addressed by each software element. Finally, Protocols
and Standards will list the protocols and standards we Although Unix will be the primary Operating System
plan to embrace as necessary to COSMOS. platform, we desire to support other platforms as well.
In particular, modifications will be made, where
Type necessary, to allow the Foundation code to compile and
The COSMOS software should be roughly envisioned operate on the latest version of Windows 7 and MacOS
as four levels of software, progressing from the 10. Programs and Agents will be supported in these
rudimentary to the most complex. At the most basic operating systems where possible. Tools are created in
level is the Foundation layer. This consists of a large the Nokia QT GUI environment 3 and therefore have the

Sorensen 5 25th Annual AIAA/USU

Conference on Small Satellites
potential of running on any environment supported by interface to the mission planner (human) and consists of
QT. the following major functions: Scheduler, optional
operational plan optimizer (ACPT), Timeliner, and
Communications are through standard RS-232, USB Command Script Generator (CSG).
and Ethernet. More specifically, a SLIP protocol with a
16bit CRC appended to each packet is used for any Scheduler
Serial interactions. Standard IP protocols are used for The Scheduler takes various inputs and generates long-
all Ethernet interactions; only UDP based protocols are term and short-term schedules and the plan of which
used for Earth/Space communications. Specific tasks need to be done during upcoming orbits. Inputs
protocols will be adopted as appropriate. Protocols that include the overall Mission Plan, which defines what
have already been identified include: needs to be accomplished during various phases of the
 JSON (JavaScript Object Notation): a simple text mission; the status of the spacecraft and ground
based method to be used for storage of all network and any associated constraints or tasking that
information and data. are required; and task requests from customers,
 NORM (NACK Oriented Reliable Multicast): a engineers, etc. A draft schedule is built using orbital
UDP based file and message transfer protocol that event data generated by the Ephemerator. This
robust, and can function over even a simplex schedule along with the mission MOEs derived from
connection. This will be used for Earth/Space Mission Payload Data form a draft plan which may be
communications. passed to the optional optimizer tool, which checks
 LCM (Lightweight Communications and constraints, collection opportunities, and optimizes the
Marshalling): a UDP Multicast protocol for plan. The final optimized plan is then returned to the
signaling and transferring data blocks between Scheduler. If the optimizer tool is not used, the
processes. This is the primary means of inter Scheduler does basic deconfliction and constraint
process, and inter processor communication within checking. The schedules are sent to the MOT and the
a local network. orbital plan is sent to the Timeliner.

COSMOS TOOLS OVERVIEW Automated Collection Planning Tool

The tools of COSMOS are the software applications The Automated Collection Planning Tool (ACPT) is a
with which the human operators interact to control payload data collection planning tool developed by
COSMOS and the mission operations processes. Each Riverside Research Institue. It was originally developed
of the tools is described below. for the National Geospatial-Intelligence Agency
(NGA), supporting Research and Development effort
COSMOS EXECUTIVE for long term satellite mission collection and mission
trend analysis. Since then, it was modified to support
There needs to be a way to monitor and control the the Multispectral Thermal Imaging (MTI) satellite, the
operation of the entire COSMOS system and possible to USAF‟s TACSAT-3, and other NGA efforts. The
launch or terminate various COSMOS tools. The program is designed to provide collection feasibility
COSMOS EXECUTIVE (CE) fulfills this function. It analysis and collection planning, while optimizing
shows which elements of COSMOS are running, which satellite mission utility given satellite specific and
mission they are controlling, their current status and customer defined constraints. ACPT offers a user-
level of activity. From the CE you can start up any of friendly interface to support a customized approach to
the COSMOS tools and transfer into that tool if desired collection planning. It also offers a comprehensive
as a new computer session, which will put the CE into interface to adjust mission specific settings, and an
background mode, possibly within a separate window if open database interface supporting an open architecture
desired. The CE also provides another function – it is for external programs. ACPT currently supports LEO
the way to monitor multiple satellites and ground imaging missions, but its capabilities are expanding. It
stations simultaneously from a single tool. This feature accounts for satellite collection constraints (sensor field
will be discussed later in the paper. of view, resolution, memory, solar exclusion), customer
target collection requirements to include (temporal,
MISSION PLANNING AND SCHEDULING TOOL
azimuth, elevation, Ground Sample Distance, solar, and
The Mission Planning and Scheduling Tool (MPST) lunar, periodicity, weather), and offers an operator-
converts mission status and tasking inputs into defined customized collection strategy.
executable command loads or sequences, schedules,
In order to allow ACPT to support other missions
and timelines. The MPST functional block diagram is
within COSMOS, ACPT is being modified, especially
shown in Figure 4. The MPST provides a top-level

Sorensen 6 25th Annual AIAA/USU

Conference on Small Satellites
its interfaces and level of automation. ACPT continues provided by the Ephemerator. It then adds in the tasking
to be updated and will soon include a complex Power- events that were provided in the orbital plan from the

Figure 4: MPST Functional Block Diagram

Management Module. Current applications assume the Scheduler. The Mission Planner then makes any
collection constraints were intentionally restrained to adjustments that are necessary to fulfill the purposes of
ensure power availability and do not maximize satellite the time covered by the timeline. The Timeline has an
operational capability. Other ACPT customers are in-built error detection capability, which tests the
requesting a much more extensive capability to include timeline sequence for syntax or functional errors while
complex power management in order to maximize checking mission constraints.
satellite operational utility. Other areas of ACPT
modifications benefiting COSMOS include: enhanced Once the initial timeline is complete, it is passed to the
swath analysis, uplink/downlink data management, and Command Script Generator (CSG). Another version of
requirement/product management to support the the timeline is produced in a form that is readable by
customer monitoring from data request to data delivery. MOST. The CSG converts the timeline into a command
Integration of updated versions of ACPT will be sequence or script that is readable by the flight software
handled through the COSMOS Configuration on the spacecraft and in the simulators/OTB. This
Management process. command script can then be run on the software
simulators, the results of which are passed back to the
Timeliner and Command Script Generator Mission Planner through the MPST. If adjustments
need to be made, then they can be done in the
The Timeliner generates a human-readable form of the
Timeliner. Once the command script has been verified
events and commands to be performed by the spacecraft
through the simulators, and high fidelity verification
during an upcoming time period, usually either for an
can then be done using the OTB. Once the OTB has
orbit or a day, depending on the length of the orbital
verified the commands make the spacecraft perform as
period and requirements of the mission. The Timeliner
expected, the command script/sequence is passed to the
first populates the timeline with the orbital events

Sorensen 7 25th Annual AIAA/USU

Conference on Small Satellites
Data Management System (DMS) where it is combined MOC System Simulator is MOST, which is one of the
with other files needed to be uploaded to the spacecraft two interface tools between the OTB and the end user.
(called flat files) to form a command load. This
command load is passed to the Ground Network, while
the timeline itself for this period is sent to the MOT.

OPERATIONS TEST BED AND SIMULATORS

The COSMOS Operations Test-Bed (OTB) 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
Figure 5: OTB Functional Block Diagram
and testing. The OTB tools are based on COTS that are
affordable to university labs while some tools are being MOST is connected to the second main component of
developed under the COSMOS project using proven the OTB – the Ground Station Simulator (GSS). The
standards and made available to the small sat GSS receives simulated or real telemetry from the
community. The OTB is part of the four major satellite system that is at remote location. The
processes in mission operations that are supported by communication link for the test bed is based on
COSMOS, namely the Mission Planning and Ethernet layers supported on concurrent
Scheduling, Real-time contact operations, mission communications software to allow real time and high
analysis, and anomaly resolution. performance communication services with standardized
procedures and portability between different OS
The OTB will be initially used within the Hawaii Space platforms. Open source frameworks for network
Flight Laboratory small sat development program and communications are considered as primary resources
after a successful implementation and usage it is for the development of the OTB. Serious options being
expected to be installed in other facilities, like other considered and partially used in the OTB are the
universities, within the COSMOS project umbrella. Adaptive Communication Environment, also known as
ACE and the Lightweight Communications and
One important aspect of the OTB is that it makes Marshaling, or LCM, which is targeted to be used in
possible to provide an interface with different satellite real-time systems where low latency are critical and
hardware and simulators that are needed to make the high bandwidth are important. The communication link
global testing procedure for different missions. This may also use the actual Telecommunications subsystem
platform also allows the mission segment functional of the satellite by interfacing with standard software
simulation and mission rehearsals from the command and hardware protocol layers for reliable
sequence to the software and hardware performance. communication.

To completely operate the OTB its setup must integrate The Satellite System and Subsystem Simulator platform
six main constituents: (1) The actual Mission integrates all the satellite subsystems to be operated
Operations Center (MOC) control tool, or MOST; (2) (e.g. ADCS, TCS, EPS, Telecom, etc.). These can be
the Ground Station Simulator (GSS); (3) the Satellite either fully operational with the engineering model
System and Subsystem Simulator (SSS); (4) the Test hardware components or else software simulated if the
Bed engine (TBE); (5) The test bed controller tool hardware components are not readily available. This
(TBCT); and (6) the Test bed controller user interface. platform receives data from a simulated Telecom
This segmentation is expressed in Figure 5. subsystem or the On Board Computer Subsystem
(OBCS) engineering model. The OBCS will change
The MOC System Simulator allows the end user to accordingly to each mission that utilizes the OTB as
conduct the near real-time spacecraft system and well the other satellite subsystems, but each has
subsystems testing and operational activities, including standardized software and hardware features. The
mission planning; assessment and maintenance; satellite system will then provide the data commands
instrument health monitoring; and communications, and any data relevant to the surrounding system. Based
command and control function. The integral part of the on the Test Bed Engine, it supports full propagation of
the test satellite‟s conditions, in both real and faster

Sorensen 8 25th Annual AIAA/USU

Conference on Small Satellites
than real time. Figure 6 shows a subsystem of the OTB physical models like the atmospheric models, the
being tested for development of the On Board magnetic field model and others. The dynamical engine
Computer System for the HawaiiSat-1 microsatellite. also controls the different hardware and software
Figure 7 shows the HawaiiSat-1 full-scale mockup configurations in the satellite system simulator and
being used to test a reaction wheel on the OTB by using allows the tuning and mixing of signals and interrupts,
MOST to connect through a GSS to the mockup. adding noise and possible failure modes. All this is
done either controlled by the controller user interface or
a scripting sequence.

The Test Bed Control Tool (TBCT) is an application to

support the experimental set up for the OTB
architecture. The TBCT interfaces with the GSS, the
satellite system, the Test Bed Engine and the end user.
It allows initializing and controlling the satellite system
platform and the Test Bed Engine according to the user
decisions or scripting.

The user interface control tool is software like MOST

to operate and change the OTB parameters and testing
sequences.

The COSMOS OTB can incorporate different hardware

parts that are made available for testing and
experimentation. These components can include
common sensors, actuators and other hardware systems
that are common for satellite integration. Table 1 has an
overview of these components.

Table 1: OTB Hardware Components

Figure 6: HawaiiSat-1 OBCS in OTB Sensors IMUs, Magnetometers, Accelerometers,

Gyros, Sun Sensors, Star Sensors,
Horizon Sensors, Thermal Sensors, GPS,
Cameras

Actuators Magnetic Torquers, Reaction Wheels,

Momentum Wheels, Thrusters, Motors for
reaction systems, Control Momentum
Gyros

Test tools Air Bearing Platform, Sun Simulator,

Thermal Vacuum Chamber, Testing
Software

Support Hardware development platforms, Micro

Tools Controllers development boards

Figure 7: HawaiiSat-1Mockup Used in OTB Other Battery Systems, Telecom Systems,

Systems Motor controllers, Electronic components,
The Test Bed Dynamics Engine provides a software Helmholtz Chamber, Sun Panels, PC 104
simulated space environment to the OTB to allow a boards, Solar Panels,
more realistic operation of the whole platform. It has a
Space Dynamics Engine for orbital data generation and
a Space Environment Simulator that integrates different

Sorensen 9 25th Annual AIAA/USU

Conference on Small Satellites
Finally, the OTB is designed to have the following setup to help in their satellite development or mission
operation features: operations.

 Calibration and testing of hardware components

 Integrate Software tools for hardware simulation MISSION OPERATIONS SUPPORT TOOL
 Subsystem validation & monitoring The Mission Operations Support Tool (MOST) is the
 Subsystems interaction & dynamics monitoring primary element of COSMOS and is the visualization
 Pseudo-environment input (available up to a tool designed specifically for supporting real-time
certain degree) operations. However, MOST can also be used for
 Anomaly resolution support supporting the following major operations functions:
 Measurable performance: like pointing, timing, (1) spacecraft & payload monitor & control; (2) mission
speed, fast, power, etc. planning; (3) simulations & rehearsals; (4) trending &
 Remote control of the OTB using scripts analysis; and (5) anomaly resolution.
 Near real time testing and simulations
 Mission Training and rehearsals MOST is based on the LUNOPS program that was
 Trending and analysis developed to support both LEO and lunar operations for
the Clementine mission in 1994.4 Features of LUNOPS
 System operation rehearsals and simulations with
were incorporated into the design of some JPL mission
statistical analysis (e.g. Monte Carlo)
operations software. LUNOPS was designed by the
 Operability with different standard software
COSMOS project manager, who is also the designer of
development tools and languages: MATLAB,
MOST.5
LabView, Phyton, C/C++, and/or other
engineering COTS software utility tools. MOST Architecture
 Support the development and operational test for
different satellites The MOST overview screen (Figure 8) has five basic
functions. (1) Displays a timeline with past and future
One important aspect to note is that the OTB is being events, including loaded commands. (2) Displays
designed so that it may be remotely operated, allowing subsystem and payload status. (3) Provides a
people from different remote locations use this same visual/graphical display of the satellite orbit and

Figure 8: MOST Overview Screen Design Used to Develop MOST (actual screen varies slightly)

Sorensen 10 25th Annual AIAA/USU

Conference on Small Satellites
attitude. (4) Detects anomalies and display warnings parameter, its value, and the limits value. The status
pertinent to satellite conditions. (5) Sends real-time lights stay this same color until the parameter value
commands to the satellite. passes another threshold value. When a C&W button is
pressed, the corresponding subsystem dialog box is
The MOST display consists of a timeline chart, several opened. Figure 9 shows a sample display for the
diagrams and text boxes, and two 3D windows. The Thermal Control Subsystem (TCS) which indicates the
timeline chart (Mission Events Display) shows the past locations and values of the various temperature sensors.
and future events, both orbit related and command
related. On the left side of this display are the orbit
events including passing into and out of umbra as well
as ground contact events (Acquisition or Loss of Signal
– AOS or LOS). Next are some vertical bars showing
the time period covered by these orbital events. These
event bars are generated by MOST. One or more
payload or satellite event bars can be added on the right
side. Next comes the time scale in UTC and then the list
of satellite commands (usually from the onboard
command sequence). On the far right are the Figure 9. Prototype MOST Display for the TCS
countdown (or countup) times for the various events,
which are calculated by MOST. The current time is MOST Concept of Operations
shown by a green horizontal bar (red in Figure 8). It is The architecture of MOST is shown in Figure 10.
possible to zoom in or out of this display to set the MOST has several different modes of operation, as
desired resolution, and to move forward or backwards shown on the right side of the figure. The modes are:
in time. At the top of the Orbit Events Display is a
window that displays the current satellite mode (state)  Real-Time (R/T) – which is really a “Near Real-
as defined by the flight software. Time” mode during which MOST displays
streaming data from a spacecraft during a contact
The diagrams and text boxes on the lower left quadrant with a ground station and passed through the
display the satellite subsystem and payload status ground network to the MOC. These data are the
(from telemetry data received from the satellite) and is real-time data and not the stored data being
defined by the user for the subsystems and data to be downlinked from the spacecraft. Once contact
displayed during the MOST setup and configuration. with the spacecraft is lost, the last values received
continue to be displayed, but MOST dulls the
On the lower right are two strip chart displays which visual output to indicate that the values are not
allow the user to select any two telemetry parameters to currently being updated. This mode is used to
be displayed as a time history strip chart. The time scale support real-time operations.
and parameter range of the strip chart are user-  Extrapolated – MOST has the ability to take the
definable. The user can also move backwards in time to latest real-time data and extrapolate them into the
view additional history. future so that the user can see probable conditions
of the spacecraft at some future time. MOST uses
The two 3D view windows show the satellite position
either simple extrapolation techniques for
with respect to Earth and its attitude with the values of
independent variables such as time, or uses the
the essential orbital and attitude parameters. The
models in the spacecraft simulator to calculate
attitude display shows vectors, such as the nadir,
values. Not all variables may be available in
velocity, and sun vectors. Both of these displays can be
Extrapolated mode – it depends on the
modified by the user to show different perspectives and
implementation and how comprehensive the
other viewing options.
simulation models are. This mode can be used to
A Caution and Warnings (C&W) Panel on the far right support mission planning, real-time operations or
contains colored push buttons which are indicators for for simulations, training, analysis, etc.
various subsystems. These status lights are based on  Simulated – This mode indicates that the data
the limits testing that MOST does on input telemetry. If being displayed by MOST are simulated data
all telemetry parameters are within nominal operating being received from the OTB/ simulators. In all
range, then the status lights are green. If a parameter is other ways (depending on the MOST settings)
detected in the telemetry that has just exceeded the MOST behaves as if these are real-time data. This
caution (yellow) or warning (red) limits set for it, then a mode is used when testing command scripts as
warning window is displayed which shows the part of the mission planning process, and is also

Sorensen 11 25th Annual AIAA/USU

Conference on Small Satellites
 used for training, rehearsals, and looking at MOST displays the data by providing its own internal
hypothetical cases during anomaly resolution. clock that can be set to real time, or any desired time.
 Archival – In this mode MOST reads in stored The clock speed can be sped up, slowed down, or
spacecraft data rather than real-time data. MOST stopped. In R/T mode, the MOST clock is set to real
allows a user to scan back through archived data, current time. Data that are either presently being
and present the data at a speed that the user acquired from the satellite or calculated if the satellite is
chooses. This mode is most important for not in contact with a ground station are read from the
supporting analysis and trending of SOH or DMS and displayed on the MOST GUI on a real-time
payload data, anomaly resolution, and may also be basis. In simulated mode, archival mode, or
helpful in certain circumstances for mission extrapolated mode, the MOST clock is set to a time
planning. specified by the user, and the speed at which to show
the data can be selected. MOST then shows (or
“plays”) the images and data for the user.

MOST has several types of input data coming from the

DMS. Archival telemetry data are stored by the DMS
in a repository of files accessible by MOST. The files
use a standard JSON format. Timeline data are also
supplied to MOST from files accessible by MOST.
Real time telemetry and beacon data are sent to MOST
from the DMS using a network interface.

MOST performs some calculations, but is primarily a

display tool. It depends on the DMS to calculate, or to
be an interface to, all the data it displays. MOST has its
own internal clock which is used to determine what
Figure 10. MOST Architecture data are to be displayed. Depending on its own clock
time, it shows the data that matches that time, whether
The MOST Functional Block Diagram is shown in
it is from the archives, or real-time data.
Figure 11. The real-time telemetry is streamed directly
into MOST through the Data Management System MOST immediately reads real-time data as soon as the
(DMS). Stored telemetry data also come from the data are available. It receives the latest timeline data as
spacecraft through the Ground Network and DMS. they are supplied and/or modified by the DMS. It also
Archival data are telemetry data that have been stored reads in archival data as requested by the user. MOST
in the mission archive of the DMS and can also be puts these data into an array of structures, where each
displayed by MOST. Simulated data come from the element of the structure array contains the full set of
simulators or OTB. If data extrapolated from actual parameters that MOST shows. Each structure element
telemetry data are desired, then the simulators can be is time tagged, and all data in that structure element
used to produce these data as well. reflect the satellite state at that specific time. As the
MOST clock changes, the state at that time is read from
the structure element, or interpolated from structure
times that are before and after the MOST clock time.
These data are displayed on the GUI, and as the MOST
clock progresses in time, so does the display. The
resolution of the MOST clock is one second.

Functional Design
One of the primary aims of the MOST development is
to enable MOTs to have all the necessary information
for a single Flight Controller to conduct monitoring and
control operations of a spacecraft with a single tool on a
single console. This requires all the information
required to be presented in a clear and logical fashion
tailored to the needs of the mission. The overall status
of the spacecraft is available, but with a single click, the
Figure 11. MOST Functional Block Diagram
Flight Controller can access detailed information about

Sorensen 12 25th Annual AIAA/USU

Conference on Small Satellites
the spacecraft and mission. This enables a small times, and countdown timers are printed onto this
operations team to control relatively complex spacecraft “map” in the proper columns (depending on the type of
with a minimum of labor and cost. data) at the proper “time” location.

MOST uses a configuration file to tailor it to the needs A slide bar and zoom buttons at the right side of the
of a specific spacecraft. The configuration file is read MED allow the user to change the time space they are
in by MOST at startup, and gives MOST specific viewing. When the program is started, MOST reads in
parameters that it uses to configure itself for a given the last eight hours worth of data, and uses this to allow
spacecraft. These parameters tell MOST which the MED to show a span of eight hours (ending at the
information diagrams, text boxes, timelines, graphics present time). MOST continues to update and show the
windows, and subsystem dialog boxes will be present, last eight hours of data on the Command Timeline. If
and where they will be placed on the MOST graphical the user decides to zoom out, this causes the MED to
user interface (GUI). To make modification of this show more than eight hours of data, and MOST reads
configuration file easier, a design tool program the additional data from the archive files. If the user
(COSMOS Editor) will eventually be developed to slides the slide bar into the past (away from “present”
allow a user to visually click and drop the items onto a time), MOST reads in the archival data as needed. In
GUI form. Several templates will be available for a this case, MOST changes its internal clock time to the
designer to use as a starting point (or as a ready made time specified by the user, and runs at the user specified
design). These templates will be based on display speed. The user has the option of speeding up, slowing
layouts developed by various operations teams, which down, or stopping the clock.
will then become part of an expanding library available
to new users in the COSMOS community. Modifying MOST for New Spacecraft
The goal of MOST development is to create a
Once MOST configures itself, it runs continuously, framework that is easily adapted and customized for a
performing the following functions at various rates: wide variety of spacecraft applications. MOST, in its
initial development, is being built for HSFL‟s
1. Load spacecraft data from requested time period
HawaiiSat-1 microsatellite, but wherever possible,
into viewing memory window.
customizable options are integrated to allow the
2. Load any new spacecraft data into real time structure to be changed to accommodate different
memory window. payloads and spacecraft containing more or fewer
subsystems.
3. Set pointer to appropriate time in either viewing
or real time window, based on current time flow. During the development of the spacecraft all the
subsystem and payload controllers provide input for
4. Perform any required calculations and display for what they would like to see in their subsystem window
current mode. and on in their panels on the main display. The MOST
implementer takes the input from all the controllers and
5. Perform any requested comparisons and customizes the standard MOST interface for use with
deliveries of alerts for background monitoring. the unique mission, spacecraft, or organization. MOST
can also be easily modified during mission operations
MOST gets its data for requested time periods in one of to accommodate unforeseen issues and operations. For
two ways. Past data are read from the data archive, example, if during operations there is a malfunction and
which is kept in a location specified by the MOST a certain aspect of the spacecraft requires close
configuration file. Future data can either be read from monitoring, these data can be moved to the main
an ephemeris, stored in the same location as the display or tracked with a strip chart.
archive, or generated internally. MOST acquires its new
data when the spacecraft is in contact with a ground MOST is a versatile tool that allows users to
station, at which point it reads live telemetry data over a accomplish all of their mission operations goals. The
network connection. modification process for MOST will continually be
developed to create an ever more intuitive environment
A major component of MOST is the Mission Events for modification with the least amount of interruption to
Display (MED), including the Command Timeline. The operations. Modification to the standard interface will
design of the MED uses a bitmapped space with a linear be simple and applicable at any point on the design and
timescale conceptually mapped into it. The time scale operation process as required.
runs vertically (from top to bottom), and is divided into
several columns for the different types of data. Events,

Sorensen 13 25th Annual AIAA/USU

Conference on Small Satellites
MOST Editor portability between different operating systems, namely
Windows, Mac Os X and Linux. The modular Qt C++
The capability to modify MOST interfaces will be made
class library provides an extensive set of system
possible with the MOST Editor. This is a modular
applications that make possible the functionality needed
software tool that is capable of changing its own
to build cross-platform and advanced applications like
interface and internal configuration to operate the
MOST.
various necessary missions. Any user will be capable of
creating or adapting the standard configuration file and
The development of the software is made using Qt
user interface files provided with MOST to their own Creator, a cross-platform C++ integrated development
spacecraft mission specifications. environment that is part of the Qt Software
Development Kit (SDK). Using Qt Creator allows
The capability of dynamically changing the user
standard development procedures for the different
interface form dialog is also specified as run-time form
operative platforms and allows for a clear setup of the
processing, because the forms are processed at run-time
UI environment. It uses the C++ compiler from the
and produce the dynamically-generated interfaces based
GNU Compiler Collection on Linux and MinGW on
on the input provided. This dynamic process is made
Windows that has been successfully used in the
possible through the embedded classes (like QtUiTools)
software industry for many years.
and modules. These enable the form to be processed at
run-time by changing the user interface file (.ui) and To further support MOST in its goal of being a flexible
then load it into the run-time environment. The visualization tool for multiple spacecraft, it has to be
capability of creating a user interface is also available designed on a framework that is limited enough to be
using the Qt Designer platform that is the default user easily defined, while still being complete enough to
interface editor for Qt. Both tools (MOST Editor and Qt cover the desired characteristics of the spacecraft being
Designer) make it easy to develop any user interface represented. It is therefore very important to define a
with the Qt‟s signals and slots mechanism for type-safe basic set of building blocks, around which the Interface
communication between the graphic objects. can be built. These building blocks need to be complete
enough to represent all elements of the spacecraft in
The MOST Editor is structured using the Qt
which we are interested. At the same time they must
environment and it contains a series of default
remain simple enough to retain a direct relation to the
templates, as a visual interface library, for different
overlying GUI. Finally, the whole has to be designed
spacecraft missions. It also contains the corresponding
with flexibility in mind for future expansion.
subsystems allowing the user to easily put together the
necessary graphic interfaces and data variables for its To meet this goal, the software team is working on a
mission. The process of creating a new mission suite of four design components to support the lowest
environment will be standardized and guided with level of the software structure. These components
specific procedures. Tutorials will be created and added interact with each other to provide a solid framework
to the database of previous created mission from which the GUI derives its structure.
environments as open source and free to use. Typical
environments that will be part of the interface library The first component is a Structural Elements Definition
are: Main Dialog (showing the main subsystems and a (SED). The purpose of this definition is to define all
summarized description of their status); Electrical elements of the spacecraft that we might want to
Power Subsystem; Attitude and Determination Control represent to the GUI. This is not an attempt to represent
Subsystem; Communications Subsystem; Thermal every aspect of the spacecraft. Instead, it lists the
Control Subsystem; etc. The editor also allows the user common aspects of all the spacecraft that we would like
to create a new subsystem (normally a payload) making to represent in MOST. The SED includes, at a
it scalable and very flexible for any particular needs. minimum, key structures, such as panels, and
components, along with related values of shape and
Design Implementation position, mass, and power. It is complete enough to
To facilitate usage on multiple platforms, MOST is provide a template of all the pieces required to roughly
being written in Qt as a limited open source project. To model the behavior of a given spacecraft, and to
comply with ITAR regulations, MOST will be licensed represent its functioning in MOST.
with a Limited GNU Public License.
An example SED, as derived from a standard small
Qt is a cross-platform application and User Interface satellite, might consist of the following:
(UI) framework that is used to develop GUI interfaces
as well as non-GUI programs as servers and consoles.
Qt uses standard C++ class libraries. This allows

Sorensen 14 25th Annual AIAA/USU

Conference on Small Satellites
  Structural Panels how one of many structural panels would be
- Mass represented, while the second half shows the geodetic
- Corners (in body frame) location of the spacecraft.
- Thermal constants
- Temperature Table 2. Example Spacecraft Naming Scheme
- Interior/Exterior External (DNS) Internal Code Structure
 Structural Boxes
- Mass Spacecraft structural
- Corners (in body frame) panel
- Thermal constants panel_01_corner_01_x panel #1 of n: cornerl #1 of
- Temperature m : x value
 Solar Panels panel_01_corner_01_y panel #1 of n : cornerl #1 of
- Mass m : y value
- Corners panel_01_corner_01_z panel #1 of n : cornerl #1 of
- Thermal constants m : z value
- Temperature panel_01_corner_02_x panel #1 of n : cornerl #2 of
- Electrical characteristics m : x value
- Structural Panel panel_01_corner_02_y panel #1 of n : cornerl #2 of
 Electronic Devices m : y value
- Mass panel_01_corner_02_z panel #1 of n : cornerl #2 of
- Location m : z value
- Electrical characteristics
- State panel_01_thermal_c panel #1 of n : thermal
- Temperature conductivity
- Structural Box panel_01_thermal_s panel #1 of n : specific heat
panel_01_temp panel #1 of n : temperature
The full SED for MOST will have additional elements panel_01_position panel #1 of n :
as derived from the complete cross section of spacecraft external/internal
supported. With a well-defined SED, it is possible to Spacecraft geodetic
capture the entire state of the spacecraft being observed. location
However, for it to be displayed in MOST, it has to be geod_pos_x geodetic location : position :
tied to code. This is achieved through the additional x value
components described below. geod_pos_y geodetic location : position :
y value
The second component, a well-defined Data Name geod_pos_z geodetic location : position :
Space (DNS), is what allows the SED, as well as all z value
other aspects of the spacecraft state, to be mapped into geod_vel_x geodetic location : velocity :
software. This step involves both the creation of a x value
variable to represent each element, and the placement geod_vel_y geodetic location : velocity :
of each variable in a well-ordered structure. It also y value
involves the careful naming of each variable, for both geod_vel_z geodetic location : velocity :
internal representation, and listing in external data z value
streams and files. While the internal naming scheme geod_acc_x geodetic location :
can take advantage of hierarchical relationships to acceleration : x value
allow for reuse of names (such as x, y, z), the external geod_acc_y geodetic location :
scheme requires unique names for ease of acceleration : y value
representation in a simplified JavaScript Object geod_acc_z geodetic location :
Notation (JSON). It is important that both naming acceleration : z value
schemes be expandable, for representation of multiple
elements, and that they map to each other.
The two components listed above are sufficient to
Part of an example naming scheme, is shown in Table provide a static representation of the state of the
2. This demonstrates the mapping between the unique spacecraft. To really bring the display alive, operations
DNS names and the internal software representation of are needed. These are provided by the third component,
some spacecraft state variables. The first half shows functional libraries. To enhance the display of data

Sorensen 15 25th Annual AIAA/USU

Conference on Small Satellites
from the spacecraft, software provides a library of status for the ground station. The GSCT displays the
function calls spanning a range of complexity. The ground station configuration for an upcoming contact
most basic supply conversions from one representation (e.g., which files are waiting for upload, frequency
to another, and comparisons to threshold levels. The setting, ephemeris file used for open-loop tracking). It
most complex propagate orbital position and attitude. also allows monitoring of the ground station status
These libraries will be developed as part of the larger during a contact, displaying the antenna pointing
COSMOS effort. angles, actual versus predicted antenna pointing, carrier
signal detection and lock status, signal strength and data
Finally, in order to meet the MOST goal of easy rate, etc. GSCT also allows the user in the MOC to send
representation of multiple spacecraft, there needs to be commands to the ground station as required.
some way to tie the various components together
without having to recompile the software. The fourth GSCT is designed to view the ground segment/network
design component is therefore a configuration scheme data in a manner that allows the user to understand the
that allows the DNS and SED to be mapped to specific information quickly and easily. It is possible to view
elements of a specific spacecraft. The configuration all of the ground stations on a map with their statuses
scheme includes, at a minimum, a spacecraft easily discernable. The input to GSCT comes from
configuration file, a user interface configuration file, users, MOST and the customers. The output goes to the
and various standard images for use in the interface. customers and the DMS.
The spacecraft configuration file is an ASCII file that
contains, at a minimum: DATA MANAGEMENT TOOL

 A one to one connection between parts of the Files are the primary method of data flow between
spacecraft and External Names as defined in the elements of COSMOS. Central storage and
DNS dissemination of the files is through a Data
 The location of each ground station expected to be Management System (DMS) whose function is to:
in use
 The names of any special image files that will be  Acept files for delivery to other parts of the system
loaded in to the interface  Store files for long term access
 The name of the user interface file  Provide access to stored files
 Forward files to other parts of the system
The user interface file is a standard Qt interface file.
This is either a stock file, created when the original The DMS will be able to manage multiple spacecraft,
spacecraft configuration was done, or the output of the distinguishing between them by spacecraft designator.
MOST Editor. Either way, it dictates the arrangement It stores both informational data, and longitudinal data,
of controls and displays, and the linking to specific such as payload data and telemetry. Longitudinal data
images and values, for the specified spacecraft. The are accessible by date of creation.
various images are for display of stock items such as
solar panels, thermal sensors, and devices. The DMS is split between a Data Management Agent
(DMA), and a Data Management Tool (DMT). The
These components, if well thought out, allow a single DMA stores files in a simple directory structure,
version of the MOST software to flexibly represent a receiving them via standard file transfer protocols.
wide range of behavior in multiple spacecraft. These files are available either through the local file
Furthermore, once the configuration for a given system, in the case of the MOC, or through standard file
spacecraft is complete, it is straightforward to either transfer protocols.
switch the interface from one spacecraft to another, or
to start a separate session of MOST. Finally, the Control of the DMA is through a GUI-based control
configuration for a spacecraft is well within the abilities program, the DMT. The DMT allows monitoring and
of anyone with reasonable computer knowledge. A control of the DMA, as well as adding additional
simple configuration requires nothing more than a text features for analyzing data storage and flow.
or MOST/Qt editor and a photo processing program.
ENGINES
GROUND SEGMENT CONTROL TOOL To fulfill all of the needs of COSMOS certain complex
The Ground Segment Control Tool is a graphical processes are provided by advanced functions called
interface to the ground network. GSCT includes all the Engines. The ones that have been decided upon so far
pertinent information of each ground station, such as are listed below.
location, antenna type, contact information as well as a

Sorensen 16 25th Annual AIAA/USU

Conference on Small Satellites
Ephemerator Supported position coordinate systems are:
 Earth Centered Inertial Cartesian (eci) – centered
The Ephemerator (ephemeris generator) Engine takes a on the Earth; aligned with the Equator and Equinox
current attitude and position state vector for a of JD 2451545.0
spacecraft, combined with physical information about  Solar Barycentric Cartesian (helioc) – centered on
the spacecraft, and propagates it forward in time. This the Sun; aligned with the Equator and Equinox of
ephemeris is used by several COSMOS elements JD 2451545.0
including the MPST, MOST, and OTB.  Geocentric Cartesian (geoc) - centered on the
Earth; aligned with the Equator and Prime
Simulator Meridian of Date. This is the International
All other aspects of the spacecraft will be simulated to Terrestrial Reference System (ITRS).
the extent possible. The Simulator takes the state and  Geocentric Spherical (geos) - centered on the
location of the spacecraft and returns thermal, power, Earth; aligned with the Equator and Prime
and other data. Meridian of Date
 Geodetic - centered on the Earth; aligned with the
Analysis and Reports Equator and Prime Meridian of Date; latitude based
on the WGS84 Spheroid
Engines will be created to analyze data streams from
satellite telemetry and look for trends and alert Supported attitude reference frames are:
conditions. Reports will then be automatically  Body – The Hawaiisat-1 body frame as defined in ?
generated. Statistics of COSMOS operations including  Local Vertical Local Horizontal (lvlh) – The
the occurrence of errors, will be generated and available positive Z axis is the Earth nadir direction. The
as feedback mechanism for quality assurance and positive Y axis is the vector cross product of the Z
process improvement. axis and the direction of travel. The positive X axis
is the vector cross product of the Y axis and the Z
Other Tools axis.
 ITRS (earth) – Aligned with the International
Other GUI-based tools will be developed as needed. Terrestrial Reference System
One important tool that has already been identified is
 J2000 (eci)
the COSMOS Editor. Tools based on Qt rely on text
based forms that define the outline of the user interface. Jsonlib
The COSMOS Editor will allow the user to modify
these forms, changing the look and feel of the interface Support for use of JavaScript Object Notation. JSON
to tailor it to a particular spacecraft. Using the Objects are represented as a JSON String. Using
COSMOS Editor, users will be able to change both the routines from this library, JSON Strings can be
placement of display fields, and the particular instances constructed and deconstructed through reference to a
of predefined variables that will be mapped to them. JSON Map. A JSON Map is a list of entries matching
pointers in memory space to COSMOS Names. Each
map entry consists of:
SUPPORT PROCESSES AND LIBRARIES  name – A valid name from the COSMOS Name
Space
Libraries
 type – A single character representing the type of
An extensive set of libraries are being developed as a data storage:
part of COSMOS to provide the various functionalities  i – 16 bit signed integer
required. The libraries planned so far are.  I – 32 bit signed integer
 f – 32 bit single precision floating point
Convertlib  F – 64 bit double precision floating point
Support for coordinate system conversions, both  u – 16 bit unsigned integer
position and attitude. The base frame of reference is  U – 32 bit unsigned integer
considered to be an Earth Centered Inertial J2000, for  s – character string (<= 80 characters)
both position and attitude. Attitude is always stated as  data – a void pointer to be cast into the data type
the rotation needed to bring a vector in the stated indicated above
coordinate frame in to the body frame.
The jsonlib routines provide support for creating JSON
Maps, creating JSON Strings (by referencing either

Sorensen 17 25th Annual AIAA/USU

Conference on Small Satellites
COSMOS Name or variable address), and parsing MOST, the GSCT, and the Data Management System.
JSON Strings. Routine contacts will be possible without any humans
present. If a problem is detected by COSMOS, then a
Mathlib message (text or Twitter) will be automatically sent to
Provides functions and data types to perform the operations supervisor who can determine the proper
quaternion, vector and matrix operations. Also supports response, either remotely or by populating the MOC.
automatic conversions between byte orders on different
The COSMOS Executive program is being designed to
platforms.
provide top-level status monitoring of dozens of
Orbitlib satellites at once, by collecting and filtering data from
the DMS or multiple sessions of MOST. If more
Routines specific to orbital propagation. These include detailed information or commanding capability is
the calculation of forces that would impact position and required for one of the fleet satellites, then COSMOS
attitude, as well as the integrators and propagators that Executive can launch a session of MOST associated
allow the forward propagation of position and attitude. with that satellite.
Sliplib The key to handling the data of many satellites using
Support for the Hawaiisat-1 project specific utilization common agents and tools, such as the Data Manager
of Serial Line IP encoding. and the DMT, is to have clear satellite identification
associated with each data file and to organize the data
Timelib accordingly. This is done using a spacecraft designator.
Support for time conversions. An even more difficult problem associated with a fleet
of satellites is the problem of mission planning and
Agentlib
scheduling, generating and testing the command loads
Support for the creation and use of Agents. Server for all the satellites, and coordinating them to work with
based functions help establish the Agent as a persistent each other and the ground segment assets. This is an
program and set up the listening aspects so that advanced feature of MPST that is beyond the scope of
programs can connect. Client based functions are used the current three-year EPSCoR grant, but will be
for other programs to contact the Agents. developed later, after the basic MPST is operational. It
is expected that this will be a topic suitable for a PhD
MUTIPLE SATELLITES candidate
One of the challenges of the near future for the use of
VERIFICATION AND UTILIZATION
small satellites is how to control dozens or even
hundreds of nanosats as elements in a single mission. The ultimate success of the COSMOS approach will be
The traditional methods of mission operations will not measured by its acceptance into the space community.
be adequate to monitor and control such constellations This will not be seen for a number of years and possibly
or fleets of satellites. well after the end of the EPSCoR funding period.
However, there are a number of key aspects that we
COSMOS is being designed to handle multiple will test along the way, the success of which will be
satellites on multiple missions. When the number crucial to the success of the whole concept.
involved are only a few (maybe less than a couple
dozen), COSMOS can handle multiple missions in a Openness
single MOC, with each satellite having its own session Maintenance of an open architecture, while restricting
of the major COSMOS tools, either on the same or access to a select group of people, is crucial to the
different consoles. If the facility resources permit, it project. We will evaluate the success of this approach
would be simpler and easier to dedicate one console per through collaboration with a select group of partners,
satellite, with another to host the GSCT, one for the initially through a successful development of the
DMT, and a top-level coordinating console running the mechanism and sharing of the software with NASA
COSMOS Executive program. ARC, and ultimately through the successful acquisition
of additional partners who also successfully share the
A key for being able to handle multiple satellites
software.
without a large number of satellite controllers is to have
a high level of automation. COSMOS is being designed
to allow “lights-out” operation for most of the processes
and tools, including real-time contact operations using

Sorensen 18 25th Annual AIAA/USU

Conference on Small Satellites
Accuracy and Reliability data needed by the rest of COSMOS. Our basic
philosophy is that its elements will be easy to port to a
It will be absolutely critical that the lowest level new location and to modify for operating with new
functions and algorithms perform as advertised. A satellites, even for students. This is enabled by being an
thorough program of testing is being developed for both “open architecture” which means not only that the
accuracy (tested against verified results for a number of source code of its major elements and structure are
key cases) and robustness. Each routine will be placed available, but also that it is designed to accept external
through a range of extreme range tests to verify failure modules as plug-ins through standard, well-defined
modes. We also profile the speed of operations of the interfaces.
more involved functions, like propagators.
The lynchpin tool of COSMOS is the MOST, which
Comparison with Legacy Systems can be used with several of the COSMOS functions.
Performance metrics for existing mission operations MOST has a heritage traced back to the LACE and
systems will be sought to provide benchmarks for Clementine missions, and is the COSMOS tool that is
comparing with the performance of COSMOS. thr most mature, working as a prototype at the time of
writing this paper (June, 2011) and being prepared to
DISSEMINATION AND THE FUTURE operate an actual nanosat mission planned for launch in
October 2011.
We intend to make COSMOS known to the operators of
small satellites and recruit some to join the COSMOS HSFL, in partnership with the ARC, will use COSMOS
development community. The first steps were taken at to create a functional mission operations test bed,
the Plug „n Play Mission Operations workshop held at capable of evaluating evolutionary techniques and
San Jose State University (SJSU) in May, 2011. This technologies. The modular nature of COSMOS allows
workshop was sponsored by HSFL, AIAA, NASA additional elements and functions to be rapidly
ARC, and SJSU. Many of the players in the small integrated, evaluated, and potentially incorporated into
satellite field were in attendance and learned about planning, scheduling, and control and command
COSMOS for the first time. An invitation was made for systems. Knowledge developed through
them to help in the COSMOS development, similar to experimentation using the COSMOS system can then
the schema being used in the developed of ESA‟s contribute to the development and operation of next
GENSO. generation mission operations systems and techniques.
However, code distribution is vital to the success of an It is anticipated that COSMOS will be packaged and
open approach like COSMOS. For it to be a success, an made available to universities, NASA, and other
open architecture needs to be built on freely accessible qualified users.
components, well documented, and available to the
widest possible audience. At the same time, though References
completely built on publicly available code and
1. [Link]
algorithms, a successful COSMOS might, by its very
success, be considered for ITAR restrictions. 2. [Link]
3. Qt Technical Overview Whitepaper -
Due to this unique nature of COSMOS, we are devising
[Link]
a method for dissemination that reaches the maximum
pg. 41).
number of interested developers, while limiting access
only to those groups with a demonstrated valid interest. 4. Sorensen, T.C., et al, “Effective Science Mission
We will also need to put in place an access scheme that Planning and Operations - The Clementine
guarantees access only to allowed individuals. One Approach,” Paper [Link].31, 1st Annual
possibility for this would be through a server with Reducing the Cost of Space Ground Systems and
certificate based access. Operations Symposium, Rutherford-Appleton
Laboratories, UK, June 1995.
CONCLUSION
5. Sorensen, T.C., E.J. Pilger, M.S. Wood, E.D.
The HSFL with the cooperation of NASA ARC is Gregory, M.A. Nunes, “Development of the
developing COSMOS, which will provide an Mission Operations Support Tool (MOST),”
inexpensive and comprehensive method to operate a AIAA 2010-2230, SpaceOps 2010 Conference,
variety or multitude of satellites. Major components of Huntsville, AL, 25-30 April, 2010.
COSMOS are the visualization tools, support tools, and
underlying programs that produce and manipulate the

Sorensen 19 25th Annual AIAA/USU

Conference on Small Satellites