The Citizen Explorer Design and

Operations Planning System

+-----------------------+-----------------------+-----------------------+
| Jason Willis[^1]      | Gregg Rabideau        | Colette Wilklow       |
|                       |                       |                       |
| Jet Propulsion        | Jet Propulsion        | Colorado Space Grant  |
| Laboratory            | Laboratory            | College               |
|                       |                       |                       |
| 4800 Oak Grove Dr.    | 4800 Oak Grove Dr.    | Campus Box 520        |
|                       |                       |                       |
| Pasadena, CA 91109    | Pasadena, CA 91109    | Boulder, C0 80309     |
|                       |                       |                       |
| 818-393-0765          | 818-393-5364          | 303-492-4383          |
|                       |                       |                       |
| willisj@jpl.nasa.gov  | Gregg.R.              | wilklow@colorado.edu  |
|                       | Rabideau@jpl.nasa.gov |                       |
+-----------------------+-----------------------+-----------------------+

*Abstract---*The Citizen Explorer Design and Operations Planning System
(CXDOPS) was developed by the Colorado Space Grant College as a
comprehensive mission design, systems modeling and mission operations
tool. This system provides visibility into how changes in mission
architecture affect system performance throughout all phases of the
project. Additionally it will provide manual and automated scheduling
capabilities for satellite commanding over the course of mission
operations.

[Table of Contents]{.smallcaps}

[1. Introduction]{.smallcaps}

[2. The Citizen Explorer Mission]{.smallcaps}

3.  [System History]{.smallcaps}

4.  [CXDOPS Implementation]{.smallcaps}

[5. Design Visualization]{.smallcaps}

[6. Mission Operations]{.smallcaps}

7.  [Summary]{.smallcaps}

1\. Introduction

This paper will describe the design and mission operations planning
system that will be used in support of the Citizen Explorer satellite
when it is launched in October of 1999. Citizen Explorer - I (CX - I )
is the first in a series of satellites being designed and built by
students at the Colorado Space Grant College. CX-I is designed as a
Delta II secondary payload and is currently manifested with the Earth
Orbiter-1 (EO-1) and SAC-C missions. The mission concept is that the
satellite will take data relating to ozone and downlink that data
directly to amateur users (primarily schools) on the ground where they
will be able to analyze the data themselves and compare the results with
measurements from other regions of the world.

An additional objective is to demonstrate advanced mission operations
technologies for use by future spacecraft. Specifically CX-I will be
exploring autonomous command and control software running on the
satellite and the ground systems and automated planning and scheduling
running on the ground system.

The CXDOPS was conceived as a way to merge system design analysis with
the analysis and planning needs of the mission operations subsystem.
During the mission and system design it was used to visualize power
profiles as well as to determine the optimal solar array configuration
for CX-I's planned orbit and how this was affected by changes in the
orbit. During mission operations it will be integrated into the
End-to-End Mission Operations System (EEMOS) and will generate the
schedule for the spacecraft autonomously. Once verified by the user, the
schedule will be sent to the ground command and control system for
uplink to the spacecraft.

2\. The Citizen Explorer Mission

The Colorado Space Grant Consortium (CSGC) is developing a series of
Earth orbiting science satellites dedicated for use by K-12 students and
teachers. This series of satellites will make up the Citizen Explorer
Program, whose mission is to provide environmental and space education
for K-12 students; significant experimentation for the scientific
community; and real-world experience for undergraduate and graduate
student engineers and scientists.

The Citizen Explorer -- I (CX -- I) satellite will be the first in this
series of satellites. CX--I is designed for a sun -- synchronous
circular polar orbit with a 10:15AM/10:15PM equator crossing and an
altitude of 705 km. The spacecraft has two science instruments including
a spectrophotometer (Speck) which will measure UV-B and a photometer
that measures visible reflectance. Additionally, there are two ground
instruments including an UV-B detector and an aerosol meter. Data from
these four instruments will complement each other to provide information
about ozone levels in the stratosphere.

The focus of the CX--I project is education. Students (K-12) across the
state of Colorado, the United States and eventually throughout the world
will participate in this project. Participating schools will be equipped
with a ground station (EduStation) which consists of an antenna, a
personal computer and a receiver. Using the EduStation, each school will
receive and process satellite data. This satellite data will be sent to
the University of Colorado, Boulder via the Internet for further data
processing. Using this data, various data products will be made
available to the schools. The schools will also make use of the ground
instruments described above to make complementary measurements. In
addition, schools will receive spacecraft health and status data,
including beacon data, which will alert the schools to the state of the
spacecraft as it is overhead. This allows the schools to serve as
mini-mission control centers that can alert the CU Mission Operations
team if the spacecraft is experiencing any problems.

![](media/image1.wmf){width="6.804166666666666in"
height="4.052777777777778in"}

The CX-I satellite and the Citizen Explorer Program is currently being
designed and built by undergraduate and graduate students at the
University of Colorado, Boulder with the help of other university
students in the Colorado Space Grant Consortium and around the world.
The CX team is composed of several subsystem teams responsible for all
aspects of the program from flight and ground hardware and software,
holding workshops for K-12 educators and actually operating the
spacecraft during flight.

3\. System History

CXDOPS is a continuation of a highly successful program called the
DATA-CHASER Automated Planning and Scheduling System (DCAPS). DCAPS was
developed by JPL's Artificial Intelligence (AI) group to demonstrate the
feasibility of automated planning and scheduling for space based
payloads. This experiment was very successful in reducing operator time
involved in producing schedules for the DATA-CHASER Hitchhiker payload
that was built by CSGC and flew in August 1997 on STS-85. During the
flight DCAPS demonstrated the ability to reduce the time to produce a
12-hour schedule by a factor of ten and actually increased science data
return from the mission by up 100% per viewing opportunity.

Given the payload model and an initial schedule for each operations
cycle, DCAPS used AI algorithms to automatically complete and repair the
schedule. The model was created in advance (pre-flight) and consisted of
the inherent activity types, resources and constraints on the payload.
The initial schedule originated from NASA attitude and event files
specifying shuttle activities over the next 8-hour period. These files
were parsed to extract those activities relevant to the payload, such as
shuttle maneuvers and waste venting. The attitude determined what types
of payload observations could be scheduled, while certain payload
preparations were required during shuttle venting. Once the initial
schedule was loaded, the DCAPS user generated a payload schedule using a
set of predefined scheduling functions. For example, there was a
function that scheduled payload power switching activities in
appropriate places based on engineering parameters. Another function was
used to schedule as many science observations as possible without
violating any of the payload constraints. After generating the schedule,
the user would manually validate the command sequence, making minor
modifications as necessary. Finally, the validated sequence was
transmitted to the command and control system for execution during the
next cycle.

Given DCAPS success it was decided that a follow-on system was warranted
to look at further uses of emerging planning and scheduling
technologies. This follow on system was to be useful in all phases of
the mission not just the final operations phase. JPL's AI Group had
demonstrated this concept with the Design for X (DXF) project.

The idea behind DFX arose from the observation that often it is
difficult to determine how well a given spacecraft design will perform
without fleshing out approximate operations sequences for critical
phases of the mission (e.g., encounter). Automated planning and
scheduling technology is used to evaluate candidate spacecraft designs
from the standpoint of emergent design aspects such as science return
and operability. Basically, DFX allows mission designers to quickly do
many "what-if" scenarios while performing design trades. The different
designs are encoded as different models used by the scheduler. By
quickly generating a typical schedule for a given spacecraft model,
designers can qualitatively measure the impact of their design on the
science opportunities and resource margins. DFX helps ensure that
science and mission operations have a more informed influence on
spacecraft design.

4\. CXDOPS Implementation

For CXDOPS to be successful in its goal to provide useful design
analysis throughout all phases of the mission the required elements had
to be identified. Using DCAPS and DFX as baselines these elements were
identified as the following:

-   Orbital dynamics modeling environment to provide orbit analysis and
    orbits events (Terminator crossings, ground station access times,
    etc.)

-   A system modeling environment to provide system analysis and
    visualization.

-   A mission-planning environment to support scenario development, and
    interface to advanced planning functions.

-   A data analysis environment for detailed analysis.

-   Simple interface between each of the elements and to the CX-I EEMOS.

Several requirements were placed on the CXDOPS architecture based on
past experience with the DCAPS project. First, each of the elements had
to be easy to interface to. Second user interfaces must be simple and
easy to understand. Finally the system had to be able to perform all
analysis required by the user upon receipt of a single command.

![](media/image2.wmf)

**Figure 2 CXDOPS Architecture**

Figure 2 shows the architecture that has been implemented for CXDOPS.
ASPEN (Automated Scheduling and Planning Environment) is the modeling
and planning environment that was selected to provide system design and
mission planning visualization. The Satellite Tool Kit (STK) provides
the required orbital modeling and visualization for mission design. The
Interactive Data Language (IDL) was chosen as the primary data analysis
tool for CXDOPS. Finally the CX-1 EEMOS team has selected the Spacecraft
Command Language as the command and control system for both the
satellite and ground systems. Each of these components is interfaced to
the CX Scheduling (CXSch) program by either a file or socket interface.
CXSch is the primary user interface for CXDOPS.

Mission Design/ Orbital Analysis

CXDOPS had to have an environment to input orbit data, and to reduce
that data into products that the user and systems modeling and mission
planning environments could interpret. In the case of DCAPS this was
provided in the form of attitude files from NASA Shuttle operations.
Since CX-I is a free flying satellite this would not be available.

The Satellite Tool Kit (STK) Commercial Off-The-Self (COTS) tool was
developed and donated to CSGC by Analytical Graphics Incorporated (AGI).
STK along with its analysis modules is a powerful mission design tool.
STK has a GUI-based interface in which users can specify satellites and
their orbits, planetary objects, and ground stations. The analysis
package allows users to generate reports on everything from solar beta
angle to ground station access times for a satellite. STK also features
a socket interface, which can be used for another program to control
STK's modeling and receive the analysis data.

In CXDOPS STK contains a model of the satellite, the CSGC ground station
and all of the EduStations in use. During CXDOPS operations STK provides
reduced orbit information such as ground station access times,
terminator crossing times and solar beta angles to each of the 4 solar
panels on CX-I. It also provides orbit visualization by animating the
orbit for the selected period.

System Modeling![](media/image3.jpeg){width="6.847222222222222in"
height="3.9972222222222222in"}

ASPEN (Automated Scheduling and Planning Environment) fulfills the
system design visualization and mission planning requirements for the
CXDOPS system. ASPEN is a reusable software framework for a wide variety
of planning and scheduling applications. After an initial adaptation to
a given application, ASPEN automatically generates command sequences
from a set of high-level science and engineering goals. The initial
adaptation includes developing a model of system activities, resources,
state variables and constraints. Goals are given as incomplete
activities with unresolved requirements. ASPEN includes a set of
algorithms for developing a valid schedule of activities from the given
goals.

ASPEN also provides a GUI for visualizing and manually editing the
schedule. Conflicts (i.e. violated or unresolved constraints) are
continually monitored throughout the schedule. An additional set of
algorithms can be used for automatically repairing conflicts in a given
schedule. These algorithms use a predefined set of generic repair
methods that might be helpful in resolving various types of conflicts.
Repair methods include moving, adding and deleting activities. The
repair algorithms search through the different ways of applying the
methods in order to find a conflict-free schedule.

ASPEN's schedule visualization functions have been used by the systems
designers as a way to visualize system interactions during the design
processes. This has the added benefit of reducing the total modeling
effort for the project as the initial model used in the design phase can
be used by the mission operations teams as the basis for their model
used for schedule generation and planning.

Data Analysis

Once we had started using the system for design visualization it was
apparent that more detail was required to visualize some of the data. In
particular, the change in solar array power over time needed to be
displayed such that the effect of changing the orbit could be seen for
each of the panels. We decided to use IDL (Interactive Data Language) to
provide this capability. IDL is a language that has been tailored to
meet the data analysis needs of the science community.

One of the plots generated by IDL is shown in figure 6. This particular
graph shows the total power generated by each of the solar panels over
the course of several orbits. Other capabilities available include
graphing power generation over the course of a year, and a function that
calculates the total Watt-hours produced in a given orbit.

User Control

Once the tools that were needed were defined, a user-friendly interface
had to be developed. These interfaces had to facilitate communication
between each of the CXDOPS elements transparent to the user. These
requirements evolved into the CX Scheduling (CXSch) program developed by
CSGC.

At the core of CXSch are several Java classes that are responsible for
the interfaces between each of the elements of the system. Java was
chosen as the primary language because it lends itself well to
distributed computing. In addition, being object oriented will make it
easier for many of the routines written for CXSch to be used for similar
systems for other satellites and spacecraft.

CXSch provides the GUI through which the user controls the system by
input parameters that determine what analyses that the CXDOPS will
perform. This GUI allows the user to change over 20 design parameters
and select which of the 6 different analyses to perform. An example of
one of these interface panels can be seen in Figure 4.

This power interface panel allows the user to change the angles that the
solar panels are mounted to the satellite as the structure is modified
to optimize the power generated by the panels over an orbit day. In
addition the user can change the efficiency, and area of each of the
solar panels individually. The "Run Power Analysis" checkbox allows the
user to select whether or not to run the IDL power analysis program. The
"power interval" variable allows the user to select the time between
samplings of the power generated by the arrays. The "Initial Battery
State" variable is used by ASPEN to set the state of the battery at the
beginning of the modeling window.

To run the CXDOPS system the user runs the CXSch program and starts STK.
Once the CXSch GUI comes up the user sets the scheduling window (period
of time) that they want to look at, change the necessary design
parameters, and selects what analysis they want run and the files the
data should written to. With this data CXSch starts the process of
performing the required analysis.

The first step is to load the STK model and propagate the orbit for the
CX-1 satellite and the AM-Sat satellites (if requested) for the time
window specified. Once completed CXSch asks STK to perform the
orbit-related analysis asked for by the user, such as ground station
contact windows, link budgets, etc. The results for this analysis is
written to files specified by the user. Once this is complete CXSch will
perform the necessary translations so that the STK data can be used by
the other components of CXDOPS.

Once the translations are completed CXSch starts the power analysis
visualization in IDL if the user has requested that this be done. If the
user asks that ASPEN be run CXSch will start ASPEN automatically with
the data from STK and an initial schedule generated by CXDOPS for ASPEN
to repair and optimize.

During mission operations users will have the option of sending the
final schedule generated by ASPEN directly to the satellite command and
control system SCL. This is accomplished by CX1Sch reading in the ASPEN
generated command file and translating it to a SCL command format and
sending those commands to SCL via a socket interface.

5.  Design
    Visualization![](media/image4.jpeg){width="6.013888888888889in"
    height="3.1958333333333333in"}

CXDOPS has been used throughout the design process to analyze various
aspects of the CX-I design. CX-I is a highly constrained satellite.
First it is being designed and built by students who have limited
resources both monetarily and experience. Secondly being a secondary
payload the design is very tightly constrained in volume and mass. Add
to that the program requirements of downlinking to a large number of
very small ground stations and testing advanced mission operations
technologies and this design has become fairly complex.

As the requirements listed above have matured and have become better
understood by the design team the CX-1 design has been modified to meet
these requirements. These design changes had to be modeled in order to
visualize how they would effect the satellites performance. CXDOPS has
greatly reduced the time that it takes to perform these analyses. This
capability has allowed designers to use a "guess and check" approach at
times to build a more intuitive knowledge of how their subsystem
performs and what parameters of their design are the most sensitive to
changes in system design as well as their own.

The power system of CX-1 was one of the major users of this system. This
was due to the program and system requirements placed on its design. The
power system was tasked with providing 24-26 W-hrs per orbit. This
requirement was driven by the C&DH system (high power computer to run
high power software), and the communications system (driven by link
budget to EduStations and high duty cycle (\>20%)). A further driving
requirement limited the power design team to only consider body mounted
solar arrays. This was done due to the need to reduce the number of
mechanisms, and hence the system complexity. The design was further
complicated due to the limited total volume constraint placed on the
design by the launch vehicle. ![](media/image5.jpeg){width="3.10625in"
height="2.484722222222222in"}![](media/image6.jpeg){width="3.10625in"
height="2.484722222222222in"}

![](media/image7.wmf){width="3.104861111111111in"
height="3.4993055555555554in"}

The design of the power system was where CXDOPS really proved its value
to the design team. By working with the CXDOPS several structural
configurations were analyzed quickly (each under 10 min.). Through this
analysis the configuration shown in Figure 5 was able to produce the
maximum power for the design orbit. The top and side panels were angled
so that over the course of an orbit the power generated by the panels
remains fairly consistent.

This configuration using Gallium Arsenide cells produces a minimum of 26
W-hrs per orbit during the first year of operations. In figure 6 the
power generated by each of the panels over the course of a couple of
orbits can be seen. For the current configuration the energy margin is
7% during the lowest power generation period of the year. In Figure 7
the power profile generated by a "box-like" design which was initially
analyzed can be seen.

While the solar array design has been optimized as much as possible
there are still scenarios in which the satellite has a negative energy
margin on an orbit to orbit basis. The systems model in ASPEN has been
very helpful in visualizing this situation and helping the systems and
mission operations teams find solutions that meet requirements.

One of these scenarios includes an orbit with a long pass over CSGC
followed by an orbit with several EduStation passes along the Pacific
Coast. These two orbits both have negative energy margins and the
batteries are used to make up to deficit. Using ASPEN it was seen that
this deficit is made up on the following orbits while the satellite is
over the Pacific Ocean. Other scenarios that have been analyzed include
night CSGC passes, a missed pass and it's effect on data storage, and
communications conflicts with other satellites with similar
communications frequencies (AM-SAT).

Several capabilities of CXDOPS were developed late in the design process
and were not utilized by the CX-I design team. CXDOPS has the ability to
generate link budget reports for the communications team. Interfaces for
use by the ADCS team, including the ability to load an external attitude
file into STK, and the ability to set a constant offset from the default
attitude.

6\. Mission Operations

One of primary objectives of the CX program is to demonstrate advanced
mission operations technologies. For the CX-I mission one of these is to
demonstrate advance mission planning technologies, including automated
plan generation and schedule conflict resolution. CXDOPS provides the
test bed in which these technologies can be demonstrated.

The ultimate mission operations goal of CXDOPS is to build upon the
success of the DCAPS program, by further demonstrating the use of
autonomy to minimize operator involvement in the day-to-day planning
operations of the satellite. This will reduce the amount of personnel
required to operate the satellite and hence lower the operations cost
over the course of the mission.

CXDOPS will also take advantage of the conflict resolution and plan
optimization capabilities of the selected mission planning tool ASPEN.
The conflict resolution capabilities will try to resolve the conflicts
that will arise due to the fact that CX-I is extremely power
constrained. Another potentially serious set of conflicts will be
between some of AM-SAT satellites that share our communications
frequencies. At the same time CXDOPS will strive to maximize science
return and the number of EduStations to which data is sent.

During mission operations once the user has adjusted the input
parameters for the scheduling window they are interested in CXDOPS will
perform the following functions:

-   Perform orbital prediction and analysis for CX-I orbit in the
    scheduling window specified

-   Insert and report access times to all requested schools

-   Perform power analysis.

-   Create initial goals and activities for the planning system.

-   Fix and optimize initial plan.

-   Ask user for permission to send optimized plan.

-   Translate planner activities to SCL commands

-   Send commands to ground system run-time engine (RTE) for uplink to
    spacecraft.

At this time CXDOPS has the ability to generate the pointing control
file for the ground station. Use of this capability during operations is
currently under review.

A future capability currently under study is automated re-planning. This
would be accomplished by further integration between ASPEN and SCL.
Re-planning would occur at the beginning of a given CSGC communications
pass. The current state of CX-I would be relayed to ASPEN by SCL and the
schedule generated prior to the pass would be checked for conflicts, any
which show up would be resolved. After all conflicts are resolved the
user is asked permission to send the new schedule to SCL for uplink to
CX-I.

7\. Conclusion

CXDOPS has proven itself to be useful throughout all phases of the
design process. It has also shown that it is possible to use the same
spacecraft model for design verification and mission planning saving
both time and resources. During mission operations CXDOPS should show
that integrating an automated planning and scheduling system into the
end to end mission operations system will reduce operator involvement in
the planning operations of the satellite and hence reduce operations
cost.

References

\[1\] G. Rabideau, S. Chien, C. Eggemeyer, T. Mann, J. Willis, S.
Siewerts, P. Stone, "Automating Schedule Development for Shuttle Payload
Operations," *International Workshop on Planning and Scheduling for
Space Exploration and Science,* October 28-30, 1997

\[2\] R. Shepperd, J. Willis, E. Hansen, J. Faber, S. Siewert, G.
Rabideau, "DATA-CHASER a Demonstration of Advanced Mission Operations
Technologies," *IEEE Aerospace Conference Proceedings,* March, 1998

\[3\] J. Owens, "Designing for Mission Success: The System Architecture
of Citizen Explorer I," AIAA *Region V Student Paper Conference*, March,
1998

\[4\] R. Sherwood, S. Chien, G. Rabideau, T. Mann, "Design for X (DFX):
Operations Characteristics Spacecraft Design Analysis Tool,"
*International Workshop on Planning and Scheduling for Space Exploration
and Science,* October 28-30, 1997

***Jason Willis** is* *a Member of the Technical Staff in the Spacecraft
Systems Engineering Group at the Jet Propulsion Laboratory, California
Institute of Technology. Prior to JPL Jason worked at the Colorado Space
Grant College for 6 years. First as electrical integration team lead on
the ESCAPE II shuttle payload that flew on STS-66. Following that flight
he spent the following 3 years as the lead systems engineer for the
DATA-CHASER Hitchhiker payload which flew on STS-85. Since 1997 he has
worked on the Citizen Explorer project as power system lead, member of
the systems engineering team and is currently an advisor. Jason holds
both a B.S. and M.S. degree in Aerospace Engineering Science from the
University of Colorado at Boulder where he specialized in spacecraft
systems.*![](media/image8.emf){width="1.6055555555555556in"
height="2.8159722222222223in"}

***Gregg Rabideau** is a member of the Artificial Intelligence Group at
the Jet Propulsion Laboratory in Pasadena, California. Gregg earned his
B.S. and M.S. degrees in Computer Science at the University of Illinois
where he specialized in Artificial Intelligence. His main focus is in
research and development of planning and scheduling systems for
automated spacecraft and rover commanding. Gregg is currently working on
planning and scheduling for future Mars rover missions. Past projects
include the New Millennium Deep Space One mission and the DATA-CHASER
shuttle payload.*![](media/image9.png){width="1.25in"
height="1.48125in"}

***Colette Wilklow** is* *currently pursuing a Bachelors Degree in
Computer Science from the University of Colorado Boulder. She has worked
at the Colorado Space Grant College for the past 3 years. She worked on
the power and mission operations teams for the DATA-CHASER payload that
flew on STS-85 in August of 1997. She is currently working on the
Citizen Explorer small satellite as the leader of the mission operations
team.*

[^1]: This paper is based on work done while the author was employed at
    the Colorado Space Grant College at the University of Colorado at
    Boulder.