Event-Driven James Webb Space Telescope Operations

SpaceOps 2006 Conference AIAA 2006-5747
Event-driven James Webb Space Telescope Operations
Dr. Vicki Balzano* and John C. Isaacs†

Space Telescope Science Institute, Baltimore, Maryland, 21218
The James Webb Space Telescope (JWST) will use an event-driven system architecture
to provide efficient and flexible operations with a simplified, high-level ground command
interface. In this paper we describe the use of an on-board COTS JavaScript engine, hosted
within the flight software, to provide the event-driven operations for JWST. This on-board
autonomy and high-level ground to flight interface will greatly simplify the JWST ground
software systems and operations. We will also discuss our development approach for the on-
board operational scripts that is based upon the process successfully used at Space Telescope
Science Institute to implement the stored command sequences for the last six Hubble Space
Telescope science instruments. Our iterative script implementation process addresses how to
Downloaded by 95.208.248.19 on January 2, 2022 | http://arc.aiaa.org | DOI: 10.2514/6.2006-5747
gather operational requirements from a geographically dispersed team, and then how to
design, build, and test the script software to accommodate the changes that are inevitable as
flight hardware is built and tested. The involvement of operations staff with the flight
hardware and flight software providers from the beginning of the development phase
enables operational factors to be considered as the Observatory subsystems are being
designed and built. The concurrent development of the operational scripts and the flight
software also enables early and frequent “test-as-you-will-fly” verification, thus reducing the
risk of on-orbit operational difficulties
Nomenclature
JWST = James Webb Space Telescope
COTS = Commercial off-the-shelf
IR = Infrared
I. Introduction
G UIDED by the recommendations of the Astronomy and Astrophysics in the New Millennium Study1, the James
Webb Space Telescope (JWST) will be a large 6-meter infrared space observatory capable of detecting light
from the first stars, tracing galaxy evolution from formation to the present day, and observing distant planetary
systems. The design and operation concepts that have resulted to support these primary science themes will also
enable international scientists to investigate a wide range of fundamental astrophysical questions using the infrared
(0.7 to 27 micrometers) image and spectral data from the JWST science instrument suite. Contributions from
American, European, and Canadian organizations will provide the science instrument hardware and flight software.
To provide the necessary cold environment for observing with the required sensitivity at infrared wavelengths,
JWST will be placed in an orbit around the second Sun-Earth Lagrange Point, L2, approximately 1.5 million
kilometers from Earth. The observatory’s location and the expectation that most science programs will not have tight
astronomically driven time requirements provide for relatively constraint-free operations.
To take advantage of the opportunity offered by the JWST environment to increase science efficiency and to
decrease the ground system development cost, an event-driven operations concept was considered early in the
mission definition phase and then integrated into mission level requirements and design. The event-driven
operations concept prescribes the use of real-time command execution status to determine when to execute the next
command in a sequence. The JWST ground system does not calculate or assign absolute command execution times,
thereby eliminating observatory subsystem history keeping and the application of conservative timing estimates.
*
JWST commanding group lead, Engineering and Software Services, STScI, 3700 San Martin Drive Baltimore MD
21218, non-AIAA member
†
Lead systems engineer, JWST Mission Office, STScI, 3700 San Martin Drive Baltimore MD 21218, non-AIAA
member
1
American Institute of Aeronautics and Astronautics
Copyright © 2006 by the American Institute of Aeronautics and Astronautics, Inc.

The U.S. Government has a royalty-free license to exercise all rights under the copyright claimed herein for Governmental purposes.
All other rights are reserved by the copyright owner.
Commands execute one after another based upon the prior command’s execution status as opposed to a ground-
calculated execution time, thus improving execution efficiency. There is also the capability to skip commands when
the required resource is not available or when a prerequisite event does not take place. For example, when a science
instrument goes off-line due to hardware problems, all commands for the affected science instrument are skipped
until ground intervention can address the situation. When a guide star acquisition needed to accurately point JWST
does not complete successfully, all commands at that pointing are skipped. This feature increases the science
efficiency as no time is spent trying to execute commands that will not succeed. Although the event-driven concept
does allow for skipping planned operations, it does not include autonomous on-board reordering of the planned
sequence. The execution order is determined by the ground system.
The JWST ground-to-flight interface for event-driven operations consists of higher-level constructs than
commands. The event-driven operations concept provides for the on-board generation of commands from high-level
constructs provided by the ground system. The JWST ground system assigns a time window to each high-level
construct primarily based upon sun avoidance and observer specified timing/orientation constraints. High precision
observatory subsystem modeling within the ground system is not required, thus reducing the ground system size and
complexity. The ground-to-flight interface consists primarily of text files with no translation into binary command
structures and thus event-driven operations eliminates the typical command generation task in the ground system.
II. Preparing for JWST Event-Driven Operations

The JWST scientific programs will be selected through a competitive peer review process carried out on a yearly
basis by the Science and Operations Center at the Space Telescope Science Institute. It is estimated that
approximately 200 science programs will be selected for execution per year. Each selected program will be
organized into one or more units known as visit descriptions. Each visit description contains a list of requested
actions for a single astronomical target with a duration typically ranging from 0.5 to 10 days. In addition, the JWST
scientific and technical staffs submit a yearly set of calibration and engineering programs using the same format as
the science programs. The calibration or engineering programs are organized into visit descriptions that list the
actions that must be executed as a unit.
From this science, calibration, and engineering visit description pool, the Science and Operations Center
constructs a long-range observing plan given the user-specified constraints and the characteristics of the pool. Each
visit is assigned a general feasibility timeframe. The short term scheduling process analyzes the visit candidates
recommended by long-range planning in approximately 10-day sections and assigns each selected visit description
an execution window (earliest start time, latest start time, and end time). Short term scheduling then constructs one
text visit file for each user-specified visit description and a text file of time-ordered visit file names and execution
windows. Figure 1 shows the data flow from user requests to event-driven input products. A typical science visit file
contains requests for (1) a vehicle reposition that results in the astronomical target being placed within the specific
detector’s field of view, (2) a guide star acquisition to refine the vehicle attitude, and (3) a set of exposures taken at
several offset positions to compensate for detector non-uniformities. Approximately once a week a new list, known
as an Observation Plan segment file, and its associated visit files are uploaded to JWST. A typical Observation Plan
segment file contains approximately 50 visit file names. For more information about JWST planning and
scheduling, please see SpaceOps2006 paper2 AIAA-2006-5774 by K. Long, et al.
}
Science Programs Science and
Yearly Weekly Observation Plan Segment File
Calibration Programs Operations
Submission Center Upload Visit Files
Engineering Programs
Figure 1. Generation of Event-Driven Operation Files
2
III. Observation Plan Processing
Upon upload, the Observation Plan segment file and the associated visit files are stored within a dedicated
operations file store within the JWST payload computer. A set of on-board scripts, known as the Observation Plan
Executive, processes these uploaded files. A COTS script interpreter imbedded inside the payload flight software
provides for the script execution. These Observation Plan Executive scripts are located within the same dedicated
file store as the uploaded files. The Observation Plan segment file can be appended to a currently executing on-
board Observation Plan (see fig. 2), or if the Observation Plan Executive is idle (as would be the case upon recovery
from a vehicle safing event), the file can become the new on-board Observation Plan. The supported management
actions that can be applied to the on-board plan are purposely kept simple: append to the end, delete off the end, start
processing, stop processing after visit x, and stop processing immediately.
The Observation Plan Executive reads the textual on-board Observation Plan to determine the next visit file to
execute. The visit files are executed one at a time in the order they appear in the plan. There are three time
parameters associated with each visit files: earliest start time, latest start time, and latest end time. When the visit
file’s associated start time window constraints are met, the Observation Plan Executive reads the textual visit file. If
the current time is later than the visit file’s start window, then the visit file is skipped (and removed from the plan).
If the current time is prior to the visit file’s start window, the Observation Plan Executive will wait. It is the
responsibility of the ground system planning procedure to minimize the wait time after an unsuccessful visit by
judiciously ordering the visit files so that their time windows overlap. After a visit file is processed, it will be
removed from the on-board plan and deleted whether it was successfully completed or was aborted due to a detected
error. The Observation Plan Executive then examines the next visit file’s time window. There are no capabilities to
re-enter or re-use a visit file once it has been opened.
Observation Plan Segment File On-board Observation Plan

Visit File name + time window Currently
Visit File name + time window Visit File name + time window executing
Visit File name + time window upload Visit File name + time window
Visit File name + time window Visit File name + time window
Visit File name + time window Visit File name + time window
Visit File name + time window
Figure 2. Observation Plan Segment File contents are appended to the executing on-board Observation Plan
Each visit file contains a structured list of activity statements with their associated parameter/value list. A
structured list is used, as opposed to just a sequential list, to support parallel operations. It is possible to calibrate one
science instrument while another is collecting science data or to calibrate a science instrument during a vehicle
maneuver. As each activity statement is encountered, the Observation Plan Executive activates the appropriate on-
board script, known as an Activity Description script, to accomplish the requested activity passing along the
parameter/value list specified in the visit file. If a parallel activity is specified, the Observation Plan Executive will
simultaneously activate another Activity Description script to handle the particular execution of the parallel.
A typical science visit file will consist of the following activities: a vehicle maneuver activity, a guide star
acquisition activity, a target acquisition activity, and a series of science activities with different filter and/or grating
selections taken at slightly different vehicle offsets. The Observation Plan Executive manages the flow of the
activity execution. There is a communication path from the Activity Description scripts to the Observation Plan
Executive scripts for relaying the execution success or failure. If the guide star or target acquisition is unsuccessful,
then the rest of the visit file activities are skipped and processing of the current visit file is aborted because the
JWST attitude will not be as required to obtain useful science data. If the science instrument utilized by the activity
has a hardware problem, then the activity is skipped because successful data collection cannot be achieved. A
successful visit execution is shown below in fig. 3, whereas fig. 4 illustrates an aborted visit execution. To record the
visit file processing results, the Observation Plan Executive will create time-stamped event message telemetry. The
Activity Description scripts and the science computer flight software also create time-stamped event message
telemetry to record processing status and to send notification of specific failure ile conditions. Upon receipt by the
ground system, the event message telemetry packets will be combined into a time-ordered log so that the operation
3
history can be examined to learn when each planned activity took place and whether any visit file failures occurred
while out of contact.
Science Visit File Visit start event

message telemetry
activate
Activity Statement for Vehicle maneuver Vehicle Maneuver
With specific pointing parameters On-board Script
success
activate
Activity Statement for Guide Star Acquisition Guide Star Acq
With specific guide star parameters On-board Script
success
Activity Statement for near-IR imaging exposure activate

Near-IR Observing
With specific exposure parameters

On-board Script
and vehicle offset values success
Activity Statement for near-IR imaging exposure activate

With specific exposure parameters Near-IR Observing
and vehicle offset values On-board Script
success
Visit end event

message telemetry
Figure 3. Observation Plan Executive successfully processes a typical science visit file, as each activity
statement is encounter, the specified Activity Description script is activated. The Observation Plan Executive
waits for completion status before processing the next activity statement.
Science Visit File Visit start event

message telemetry
activate
Activity Statement for Vehicle maneuver Vehicle Maneuver
With specific pointing parameters On-board Script
success
activate
Activity Statement for Guide Star Acquisition Guide Star Acq
With specific guide star parameters On-board Script
failure
Activity Statement for near-IR imaging exposure EXIT Error event message
telemetry
and vehicle offset values
Activity Statement for near-IR imaging exposure

and vehicle offset values
Figure 4. Observation Plan Executive aborts a science visit file. The Observation Plan Executive receives
status from the Activity Description script that the requested guide star acquisition attempt was unsuccessful,
and aborts processing of the current visit file.
4
IV. Activity Description Processing
As described above, the Observation Plan Executive scripts control the operations flow and provide for efficient
operations through their ability to skip activities when failures occur or when constraints are not met. The
Observation Plan Executive scripts activate another class of scripts, known as the Activity Description scripts, to
control the sequence of flight software commands that are needed for proper activity execution. These scripts
encode the operational rules of the science instruments and the spacecraft. They generate flight software commands,
and monitor telemetry items. Event-driven operations is provided at this level through the ability to make command
decisions based upon observatory telemetry. Every flight software command request is made based upon the
execution status of the previous command. A command will not execute unless a success telemetry response is
received for the previous command. If an error is encountered, the Activity Description script will construct a timed-
stamped event message telemetry packet, and either exit by sending a status message back to the Observation Plan
Executive or perform a retry of the previous command if the operational rules dictate.
The Activity Description scripts process the parameters passed by the Observation Plan Executive scripts and
generate the appropriate series of commands and telemetry requests to execute the specified observatory function,
such as a guide star acquisition, or a near-infrared image or a mid-infrared lamp calibration. To create a modular
implementation and to facilitate script maintenance, each high-level Activity Description script will invoke other
“lower-level” scripts. In this way the generic low-level scripts can be used for all science instrument operations thus
eliminating code replication.
V. Payload Flight Software

The JWST event-driven operations is provided by both the Observation Plan Executive scripts and the Activity
Description scripts. These scripts are uploaded as individual text files to the payload computer’s dedicated
operations file store after system startup. The on-board script suite supports all types of operations as required by
commissioning, science, and engineering programs. When modification or new functionality is identified through
in-flight experience, revised and/or new scripts will be implemented, certified, and uploaded to JWST, and any
obsolete script files will be deleted.
A. The Script Engine

Following a trade study3 of candidate scripting languages in 2003, NOMBAS ScriptEase, a COTS JavaScript
engine, was selected for JWST event-driven operations. This JavaScript version is compatibility with the payload
computer’s real-time operating system (VxWorks) and satisfies all the identified language requirements. This COTS
solution eliminates the development, test, and maintenance costs of a custom scripting language, and provides a
larger array of features than is usually included in a traditional custom language.
B. The Script Processor

The ScriptEase JavaScript engine is embedded within a dedicated payload flight software application, known as
the Script Processor. The engine is self-contained: a script error cannot cause a payload flight software crash. This
application accepts ground command directives to start the engine, stop the engine, activate a script, and stop a
script. Up to ten execution threads are supported so that the Observation Plan Executive and Activity Description
scripts for several different science instruments can execute in parallel along with script activation for real-time
tasks. Most importantly, the Script Processor provides an interface between the scripting engine, the scripts and the
rest of the JWST flight software by extending the JavaScript language. Utilizing the extended language directives,
the on-board scripts can request Script Processor services to send flight software commands, to receive flight
software telemetry, to manage parameters for cross thread communications, to activate a script in another execution
thread, to retrieve the spacecraft time, to wait a specified duration, to construct event message telemetry packets, and
to access on-board files.
C. Science Instrument Flight Software

When an Activity Description script makes a science instrument command request, the Script Processor will
forward it on to the appropriate science instrument application for execution. After command verification, the
science instrument flight software constructs and transmits the corresponding hardware directives, waits for a
hardware response, and then forwards command execution status back to the script through engineering telemetry.
5
The calling script waits for this unique command response telemetry, and generates the next command upon receipt
of a success status, or upon failure notification executes an error response. An error will cause the creation of time-
stamped event message telemetry by both the flight software and by the on-board scripts. The flight software
message will indicate the specific hardware/software problem encountered, and the on-board script message will
give the associated operations response. The on-board event-driven communication flow is illustrated in fig. 5. The
above scenario also holds true of spacecraft functions such vehicle maneuvers and vehicle offsets. An on-board
script requests the Script Processor to forward a command to the spacecraft computer and waits for the execution
status telemetry to be relayed back through the Script Processor.
Observation Plan
Executive Script
activates
status
Near-IR Imaging calls

Lower Level
Script Scripts
status
command telemetry
commands
Near-IR Near-IR
Flight Software Hardware
telemetry
Figure 5. On-board event-driven communications. Upon reading the visit file, the Observation Plan Executive
script activates the near-IR imaging JavaScript in a separate thread of execution that in turn, through the use
of lower-level JavaScripts, commands the near-IR flight software. One or more commands are sent to the
appropriate hardware. Following execution, the near-IR hardware returns status telemetry that the flight
software consolidates into script command response telemetry. As the lower-level scripts complete, status is
sent to the top-level near-IR script. Upon completion of all commanding, the near-IR script exits with a status
value sent back to the Observation Plan Executive.
VI. Script Development

The JWST commanding team of the Science and Operations Center at the Space Telescope Science Institute is
responsible for the development, testing, and maintenance of the on-board scripts, while the payload flight software
team at Goddard Space Flight Center provides the on-board JavaScript environment. Each science team is
responsible for their flight software resident within the payload computer, and the JWST prime contractor provides
the spacecraft flight software for the spacecraft computer. With so many teams involved with developing the
software necessary for JWST operations, the coordination necessary for script requirement specification is a
challenging task. An iterative development approach based upon the Rational Unified Process and upon lessons-
learned from the development of the final six Hubble Space Telescope science instruments is being employed. The
important features of the script development process are (1) concurrent implementation of the scripts and associated
flight software, (2) test-as-you-will-fly verification, and (3) step-wise construction of requirements. The high-level
script requirements have been defined, and they delineate the basic functional categories for script support. For
example, science target acquisition, science imaging, science coronagraphic imaging, calibration darks, and
calibration lamp exposures are some of the identified functions for the near-IR imager. Each science instrument
team has defined about a dozen separate functions for script implementation.
Operations working groups, one group for each science instrument, define the lower-level detailed script
requirements in a step-wise progression by science instruction function. This iterative requirement specification
approach fits well with the reality of science instrument development. Operations strategies evolve over time during
the development phase of a mission. Each operations working group, chartered by the science instrument prime
investigator, is composed of representatives from the science team, the science instrument flight software team, the
payload flight software team, project systems engineers, and the commanding team. After prioritizing the science
instrument functions based upon overall scientific importance, hardware development schedules, and ground testing
6
needs, the working group refines the science instrument operations concept document, one function at a time, to
provide information for deriving the script requirements. The commanding team drafts the script requirements that
are then reviewed and approved for implementation by the operations working group. As the working group
members are dispersed geographically, most meetings are held by telecom at a frequency of once a month. Most of
the work, however, is done offline. The telecoms are used to review the operations concept document and script
requirement updates. Guest participants are also invited for discussions of particular hardware operations. For
example, when addressing IR detector operations, the hardware engineers are invited to present a hardware overview
and to discuss related operational topics. Being able to interface with knowledgeable flight hardware and software
experts at the time they are working on the JWST project is invaluable for script development and for future error-
free in-flight operations. It enables the operations concepts to be embraced by the larger science instrument
community, and to influence flight hardware and software design. Opportunities to simplify both ground and flight
systems can be facilitated.
Operations Concept for Function B
Script Requirements for Function B

Requirement Approval /Function B
Implement, Unit, Regression

Testing for Function B Operations Concept for Function C
Script Requirements for Function C
Requirement Approval /Function C

Testing for Function C
Integration Test for Build X
Operations Concept for Function D
Script Requirements for Function D
Requirement Approval /Function D
Implement, Unit, Regression Operations Concept for Function E

Testing for Function D
Script Requirements for Function E
Requirement Approval /Function E

Testing for Function E
Integration Test for Build Y
Scenario Testing on Flight

Hardware
Figure 6. Script Development Flow of two Script Builds with two iterations each. Unit and Regression testing
are done with each iteration. Integration Testing is done with each build. Scenario Testing is done at
Integration and Test with flight hardware. The grey boxes are operations working group actions and the blue
boxes are commanding team actions. Time flows down to page.
After the requirements for a particular function are approved, the commanding team designs, implements, and
tests the appropriate set of JavaScripts. The scripts are tested in the Space Telescope Science Institute Script
Development Lab, a COTS test environment consisting of a COTS payload computer, the current version of the
payload flight software, and software science instrument and spacecraft flight software simulators. In each
7
subsequent script iteration, liens and enhancements to previous implemented functions are also addressed and a
complete suite of regression tests is executed. Peer reviews are held for all design, scripts, test plans, and test results.
During the script development phase the commanding group also works with the flight software teams to define
the script-to-flight software interface, that is, the command and telemetry descriptions. Documentation of the
interface is done in the syntax compatible with the JWST Project Reference Database where all command and
telemetry items are officially stored.
A script build delivery consists of a number of script function iterations and occurs approximately once every
nine to twelve months during the development phase. The script builds are integration-tested and certified on the
best available flight software environment with a more flight-like computer, the current science instrument flight
software, and science instrument hardware simulators. After successful integration testing, the scripts are available
for flight-like scenario testing against real flight hardware. The script development schedule is consistent with
Project’s Integration and Test schedule. All scripts are certified against observatory simulators prior to the scenario
testing with flight hardware.
VII. Current Status

When the event-driven operations concept was originally proposed, we were aware that its implementation had
complexities that needed further exploration and analysis. To address this concern, a significant amount of work was
done to demonstrate that the concept for JWST event-driven operations is self-consistent and does not present major
implementation difficulties. A JWST command operations concept was documented4 along with the associated use
case scenarios in 2002 and 2003. Several preliminary flight software prototypes were completed to demonstrate the
feasibility of the event-driven command concept. Following the language selection of ScriptEase JavaScript, the
payload flight software requirements for the Script Processor were drafted by early 2004. A day-in-the life prototype
was run shortly afterwards which demonstrated six days of flight-like operations from program submission to flight
software execution.
In 2005 the Script Processor flight software was completed, and Activity Description script development was
begun in earnest. The four science instrument operations working groups have been active for more than a year with
one completed script build per science instrument as of March 2006. A total of twelve script iterations/functions
have been implemented. When the necessary test environment becomes available, the next set of science instrument
builds will undergo integration testing.
VIII. Conclusion
An event-driven command architecture is being developed for the James Webb Space Telescope mission. On-
board scripts generate commands and retrieve telemetry using an embedded COTS JavaScript interpreter. High-
level ground directives, periodically uploaded as textual files, specify the on-board event-driven operations flow.
The JWST ground system complexity is reduced while still providing efficient science operations. The iterative
script development process enables early and frequent “test-as-you-will-fly” verification and reduces the risk of in-
flight operational incompatibilities.
Acknowledgments
The authors would like to thank the Goddard Space Flight Center’s JWST payload flight software team for the
successful implementation of the Script Processor, the Goddard Space Flight Center’s Ground System team for
providing the script development test lab at Space Telescope Science Institute, the Space Telescope Science
Institute’s commanding team for a successful first year of script development, and Ken Rehm, lead JWST software
systems engineer, for many constructive conversations, encouragement, and support during the evolution of this
event-driven architecture.
References
1
Astronomy and Astrophysics Survey Committee, Astronomy and Astrophysics in the New Millennium, National Academy
Press, 2001, ISBN: 0-309-07031-7, pp. 33, 36.
2
K. Long, J. Isaacs, W. Kinzel, L. Petro, P. Stanley, and H. Stockman, “Scheduling James Webb Space Telescope
Observations at L2,” SpaceOps Confernce,AIAA-2006-5774, 2006.
3
Welter, G., Zak, D., Greville, E. and Balzano, V., “JWST On-board Activity Description Script Language Evaluation and
Selection,” Report for NASA GSFC Flight Software Branch/Code 582, 2003.
4
Stanley, P., “Mission Operations Concept Document,” JWST-OPS-2018B, prepared by Space Telescope Science Institute,
DRD# S&OC-Op-02, under contract/agreement: NAS5-03092, 2005.
8

Event-Driven James Webb Space Telescope Operations

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Event-Driven James Webb Space Telescope Operations

Uploaded by

Copyright:

Available Formats

SpaceOps 2006 Conference AIAA 2006-5747

Event-driven James Webb Space Telescope Operations

Dr. Vicki Balzano* and John C. Isaacs†

Copyright © 2006 by the American Institute of Aeronautics and Astronautics, Inc.

II. Preparing for JWST Event-Driven Operations

Figure 1. Generation of Event-Driven Operation Files

Observation Plan Segment File On-board Observation Plan

Science Visit File Visit start event

Activity Statement for near-IR imaging exposure activate

With specific exposure parameters

Activity Statement for near-IR imaging exposure activate

Visit end event

Science Visit File Visit start event

Activity Statement for near-IR imaging exposure

V. Payload Flight Software

A. The Script Engine

B. The Script Processor

C. Science Instrument Flight Software

Near-IR Imaging calls

VI. Script Development

Operations Concept for Function B

Script Requirements for Function B

Requirement Approval /Function B

Implement, Unit, Regression

Script Requirements for Function C

Requirement Approval /Function C

Implement, Unit, Regression

Operations Concept for Function D

Script Requirements for Function D

Requirement Approval /Function D

Implement, Unit, Regression Operations Concept for Function E

Requirement Approval /Function E

Implement, Unit, Regression

Scenario Testing on Flight

VII. Current Status

You might also like