PROCEEDINGS OF SPIE

SPIEDigitalLibrary.org/conference-proceedings-of-spie

Event-driven James Webb Space

Telescope operations using on-board
JavaScripts

V. Balzano, D. Zak

V. Balzano, D. Zak, "Event-driven James Webb Space Telescope operations

using on-board JavaScripts," Proc. SPIE 6274, Advanced Software and
Control for Astronomy, 62740A (27 June 2006); doi: 10.1117/12.671403

Event: SPIE Astronomical Telescopes + Instrumentation, 2006, Orlando,

Florida , United States

Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 9/18/2018 Terms of Use: https://www.spiedigitallibrary.org/terms-of-use

 Event-Driven James Webb Space Telescope Operations using
on-board JavaScripts
V. Balzanoa, D. Zak a
a
Space Telescope Science Institute, 3700 San Martin Drive, Baltimore, MD, USA 21218

ABSTRACT

The James Webb Space Telescope (JWST) will use an event-driven system architecture to provide efficient and flexible
operations as initiated by a simplified, high-level ground command interface. Event-driven operations is provided
through the use of an on-board COTS JavaScript engine hosted within the payload flight software. After presenting the
overall software architecture, we summarize the trade study that led to the selection of a commercial JavaScript
interpreter and review our experiences developing scripts over the past year. Our script development approach is based
upon the process successfully used at Space Telescope Science Institute for the last six Hubble Space Telescope science
instruments. The major characteristics of our process are 1) coordinated development of the operational scripts and the
flight software, 2) an incremental buildup of the operational requirements, and 3) recurring integrated testing. Our
iterative script implementation process addresses how to gather 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 concurrent development of the operational scripts and the flight software enables early and
frequent “test-as-you-will-fly” verification, thus reducing the risk of on-orbit software problems.
Keywords: Event-driven operations, Software development concepts, Space science operations

1. INTRODUCTION

Since the establishment of the James Webb Space Telescope’s (JWST) mission definition in the late 1990’s, it was
recognized that an event-driven command architecture could be employed to provide efficient and flexible science
operations. The observatory’s location around the second Sun-Earth Lagrange Point, L2, and the observatory’s hardware
design provide for a relatively constraint-free environment. Equally important is that the primary JWST science themes
to detect light from the first stars, to trace galaxy evolution from formation to the present day, and to observe distant
planetary systems, do not place tight astronomically driven time requirements on observatory operations. A suite of four
science instruments will examine the universe at infrared wavelengths with a near-infrared camera, a near-infrared multi-
object spectrograph, a mid-infrared imager, and a near-infrared tunable filter imager. Taking advantage of the given
mission architecture, the JWST event-driven command concept prescribes the use of real-time command execution
status for determining when to execute the next command in a sequence. The ground-to-flight interface consists
primarily of text files that outline the required operations using high-level constructs. Expansion of the ground-supplied
constructs into individual flight software commands takes place on-board within scripts that encode the operational rules
of the observatory subsystems. Commands execute one after another based upon the prior command’s execution status.
This increases observatory efficiency and decreases the overall ground system complexity. High precision observatory
subsystem modeling by the ground system is not required, nor will the use of conservative or worst-case time estimates
cause operational inefficiencies.
The JWST event-driven command architecture also provides the capability to skip commands when a required resource
is not available, or when a prerequisite event does not occur. For example, if a target acquisition needed to accurately
point JWST does not complete successfully, then all commanding at that spacecraft pointing will be skipped. This
capability increases efficiency as no time is spent trying to execute commands that will not result in useful science data.
Although the event-driven command concept does allow for skipping planned operations, it does not include
autonomous on-board reordering of the planned observations. The on-board scripts execute the uploaded files in the
order specified by the ground.

Advanced Software and Control for Astronomy, edited by Hilton Lewis, Alan Bridger,
Proceedings of SPIE Vol. 6274, 62740A, (2006) · 0277-786X/06/$15 · doi: 10.1117/12.671403

Proc. of SPIE Vol. 6274 62740A-1

Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 9/18/2018

Terms of Use: https://www.spiedigitallibrary.org/terms-of-use
 Balzano and Rehm presented the preliminary software concept at the 2002 SPIE Astronomical Telescopes and
Instrumentation Conference1. They described a three-tiered command architecture comprised of ground system software
that provides the operations planning, on-board scripts that sequence and construct the commands, and flight software
that supplies the hardware communications interface. Although the observatory’s name has changed since the
publication of that paper (from NGST to JWST), the overall event-driven command architecture survives. The
implementation of this event-driven architecture is described below.

2. EVENT-DRIVEN OPERATIONS USER INTERFACE

Approximately once a week a set of text files will be created by the JWST ground system for on-board execution. These
files, known as visit files, are selected by the JWST planning subsystem from a large pool of science, calibration, and
engineering programs solicited by the Science and Operations Center at Space Telescope Science Institute on a yearly
basis. Each science visit file contains an ordered-list of observatory activities for a single astronomical target, such as, a
vehicle reposition to place the astronomical target in a specific detector’s field of view, a guide star acquisition to refine
the vehicle attitude, and a set of exposures taken at several offset positions to compensate for detector non-uniformities.
Each calibration visit file contains an ordered-list of observatory activities for a specific calibration, such as detector flat
field measurements, while each engineering visit file is an ordered-list of observatory activities, such as for a momentum
unload or for a filter mechanism test. During the weekly planning process, one additional file, the Observation Plan
segment, is constructed that specifies the visit file execution order along with the execution time windows derived from
target visibility and user-specified constraints. A typical Observation Plan segment file will reference approximately 50
visit files and cover 10 days of operations. Weekly uploads result in an Observation Plan segment file and the associated
visit files being placed in a dedicated file store within the JWST payload computer. Figure 1 illustrates the input files
that will be processed by the on-board event-driven command system.

Observation Plan Segment File A Science Visit File

Activity statement for Vehicle maneuver

Visit File1 name + time window With specific pointing parameters
Visit File2 name + time window Activity statement for Guide Star Acquisition
Visit File3 name + time window With specific guide star parameters
Visit File4 name + time window Activity statement for mid-IR imaging exposure A
Visit File5 name + time window With specific exposure parameters
And vehicle offset values
Activity statement for mid-IR imaging exposure B
With specific exposure parameters
And vehicle offset values

Fig.1. Observation Plan segment file and science visit file specify the execution order and the activity sequences

3. OBSERVATION PLAN PROCESSING

On-board scripts, known collectively as the Observation Plan Executive (OPE), process the uploaded Observation Plan
segment file and the associated visit files. A COTS script interpreter embedded in the payload flight software provides
for script execution. Upon ground command, the Observation Plan segment file is incorporated into the on-board
Observation Plan. If the on-board plan is executing, then the Observation Plan segment is appended to the end of the on-
board Observation Plan. If the Observation Plan Executive is idle (as would be the case upon recovery from an
observatory anomaly), then the Observation Plan segment becomes the on-board Observation Plan. The Observation
Plan Executive will delete a visit entry from the on-board plan once the visit execution has completed, regardless of its
success, along with the deletion of the visit file itself. Once a visit file has been examined, it cannot be reused. This
simple file management scheme relieves the ground system personnel from performing continuous on-board file
removal, and is an important feature of the straightforward event-driven approach for JWST operations.

Proc. of SPIE Vol. 6274 62740A-2

Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 9/18/2018

Terms of Use: https://www.spiedigitallibrary.org/terms-of-use
 In addition to the append capability, the operational functions provided are (1) deletion of visit entries off the end of the
on-board plan, (2) initiation of on-board plan processing, (3) termination of on-board plan processing after a specified
visit, and (4) immediate termination of on-board plan processing. The capabilities to delete plan entries and to gracefully
stop processing enables schedule re-planning; that is, the on-board plan can be modified. This supports scheduling of a
target of opportunity and enables response to science instrument anomalies. Halting Observation Plan processing is only
done when the re-plan intercept point is too close to the top of the executing on-board plan. During normal operations,
the Observation Plan Executive will run continuously while the ground makes additions/deletions to the bottom of the
on-board plan during the daily communication contacts.
The Observation Plan Executive reads the textual on-board Observation Plan to determine when to process the next visit
file. The visit files are executed consecutively in the order they appear in the plan. If the current time is within the visit’s
time constraint windows, the Observation Plan Executive opens the textual visit file and begins processing. But if the
current time is later than the visit file’s start window, the visit is skipped (and removed from the plan). The Observation
Plan Executive will wait if the current time is prior to the visit file’s start window. It is the responsibility of the ground
system planning subsystem to judiciously order the visit files so their time windows overlap and no unnecessary waits
occur. After one visit file is processed, the Observation Plan Executive moves on to examine the next visit file’s time
window.
Once a visit has been accepted for execution, the Observation Plan Executive executes each activity statement in the
order given in the visit file. An activity statement consists of an on-board script name followed by an associated
parameter/value list. For example, a slew activity statement would supply the parameter values needed by the on-board
script for construction of the observatory commands that perform the specific vehicle attitude adjustment required by the
visit’s science observations. Parallel operations are also supported, such as performing a calibration with one science
instrument while collecting science data with another; therefore, the visit file syntax does allow for the construction of
parallel sequences of activity statements. The Observation Plan Executive manages the flow of activity execution as
specified by the structured list of activity statements in the visit file.

Visit start event

message telemetry
Science Visit
activate
Activity Statement for Vehicle maneuver Vehicle Maneuver activity start event
On-board Script message telemetry
With specific pointing parameters
success

activate
Activity Statement for Guide Star Acquisition Guide Star Acq activity start event
With specific guide star parameters On-board Script message telemetry
success

Activity Statement for mid-IR imaging exposure A activate

With specific exposure parameters Mid-IR Observing activity start event
and vehicle offset values On-board Script message telemetry
success
Activity Statement for mid-IR imaging exposure B activate
With specific exposure parameters Mid-IR Observing activity start event
and vehicle offset values On-board Script message telemetry
success

Visit end event

message telemetry

Fig. 2. A successful visit file execution by OPE and Activity Description scripts.
Activity statement execution consists of first checking the applicable operational constraints, constructing an event
message telemetry packet recording the activity start time, and then activating the specified on-board script passing
along the supplied parameter values. The on-board scripts activated by the Observation Plan Executive scripts are
known as Activity Description scripts. Execution status can be passed back from the Activity Description scripts to the

Proc. of SPIE Vol. 6274 62740A-3

Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 9/18/2018

Terms of Use: https://www.spiedigitallibrary.org/terms-of-use
 Observation Plan Executive scripts so that the processing flow can be modified according to operational rules. Figure 2
illustrates a successful visit execution and the interactions between the Activity Description scripts and the Observation
Plan Executive scripts.
If the Activity Description script encounters an anomaly, a failure status is sent to the Observation Plan Executive and an
event message telemetry packet is constructed to record the anomaly. In the case of an unsuccessful guide star
acquisition, the Observation Plan Executive will abort the visit file as meaningful science cannot be achieved. Figure 3
demonstrates this type of aborted visit. Upon ground receipt, the event message telemetry packets will be combined into
a time-ordered log so that the operational history can be examined to learn when each activity took place and whether
any visit file failures occurred while out of contact.
The Activity Description scripts process the parameters passed by the OPE scripts and generate the appropriate series of
flight software 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 internal lamp calibration. Every flight software command request
is made after interrogation of the previous command’s execution status. Event-driven operations is achieved through this
ability to make command execution decisions based upon observatory telemetry.

Visit start event

message telemetry
Science Visit
activate
Activity Statement for Vehicle maneuver Vehicle Maneuver activity start event
On-board Script message telemetry
With specific pointing parameters
success

activate
Activity Statement for Guide Star Acquisition Guide Star Acq activity start event
With specific guide star parameters On-board Script message telemetry
failure

Activity Statement for mid-IR imaging exposure A EXIT Error event message
With specific exposure parameters telemetry
and vehicle offset values

Activity Statement for mid-IR imaging exposure B

With specific exposure parameters
and vehicle offset values

Fig. 3. OPE aborts a science visit file execution following an unsuccessful guide star acquisition attempt.

4. SCRIPT PROCESSING
The on-board script suite, the Observation Plan Executive and the Activity Descriptions, are uploaded as individual text
files (one script per file) into the JWST payload computer’s dedicated operations file store after system startup, and
support all types of operations required by commissioning, science, and engineering programs. New scripts can be
uploaded and obsolete scripts can be deleted when new or revised functionality is identified through in-flight experience.
A COTS script engine embedded within a payload flight software application executes the on-board scripts.

4.1 The Script Engine

An evaluation of candidate scripting languages2 was performed in 2003, so that an informed selection could be made for
the JWST mission. The functional requirements for the language were based on our Hubble Space Telescope (HST)
experience of stored command scripting for science operations. Although Hubble uses a traditional absolute-timed
command system with the script generation of flight software commands taking place on the ground, the functionality of
the JWST on-board scripts is quite similar even though it occurs on-board the observatory. In both cases, the scripts

Proc. of SPIE Vol. 6274 62740A-4

Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 9/18/2018

Terms of Use: https://www.spiedigitallibrary.org/terms-of-use
 encode the operational rules of the science instruments and the spacecraft. The functional requirements for the JWST
scripting language are summarized in table 1.
Table 1. Summary of script language functional requirements
Function Description
Data Types Integers, floating point, strings
Control Structures Conditional and logical operators
Looping Conditional repeats
Numeric and Logical Expressions For computation and comparison tests
Numeric Functions Basic math, modulo, trigonometric, ceiling, floor, rounding, square
root, absolute value, exponentiation, logarithmic
String Functions Length, sub-string, concatenation, replace, string-to-numeric
conversions
Exception Handling To isolate script errors from payload flight software processing
Comments To document script functionality
User-Friendly Syntax For implementation and maintenance ease

Like many other space missions, HST uses a dedicated scripting language created solely for the mission. For JWST, we
primarily examined COTS scripting languages, as many were available with the potential of meeting the required
functionality. Out of about a dozen initial candidates, four were selected for prototyping: TCL (open source), JavaScript
(ScriptEase 5.00e by Nombas), Python 1.5.2 (open source), and a custom-made “G-Script” language. Creating a full
prototype with flight software, on-board scripts, visit files, and on-board Observation Plans also demonstrated the
viability of the event-driven operations concept.
In addition to the functional requirements, each candidate was graded against the operational requirements listed in table
2. An attempt was made to port each scripting engine to the VxWorks real-time operating system on a flight-like Power
PC by embedding it into a payload flight software application. TCL was dropped from the study when it could not be
successfully ported to VxWorks. JavaScript, Python and G-script were successfully ported and a series of tests with
prototype flight software applications were run in order to rank them against the success criteria. G-script received the
lowest score due to its limited functionality, its awkward syntax, and the increased cost that would be needed for
development and maintenance of a custom scripting language.
Table 2. Summary of script language operational requirements
Requirement Description
Portable to payload operating VxWorks on PowerPC chip
system
Parallel threads of execution To support simultaneous OPE and Activity Description execution and
parallel science operations (10 threads)
Input Parameters To support script reusability
Same thread script invocation To support a modular implementation (at least 4 levels deep) for
maintenance ease
Thread termination To support fault management
Dedicated Memory Pool For isolation from payload flight software
Memory Usage Less than 2 MBytes
Infinite Loop Prevention For safe operations
Extensibility For customizations for event-driven interface to JWST flight software

JavaScript and Python both demonstrated full functionality: they were quite flexible and supported a very user-friendly
interface. JavaScript, however, showed a superior ability to meet the operational requirements. It was fully compatible
with VxWorks with extremely little modification and JavaScript could be embedded within the payload flight software
using a much simpler interface than Python required. The Python port also exhibited memory leaks, and already was
quite old. Whereas the ScriptEase JavaScript port to VxWorks is maintained, the Python Open Source community does
not provide this support. A labor-intensive custom port of the current Python version would have been required with no

Proc. of SPIE Vol. 6274 62740A-5

Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 9/18/2018

Terms of Use: https://www.spiedigitallibrary.org/terms-of-use
 guarantee of success. For these reasons, JavaScript was recommended by the evaluation team and was subsequently
accepted by the JWST Project for implementing the event-driven operations system.
4.2 The Script Processor
Following the selection of JavaScript, a full six days-in-the-life Observation Plan prototype using the Javascript engine
was executed in 2004 to illustrate science operations from program submission to flight software and on-board script
execution. The success of this prototype demonstrated that implementing event-driven operations with an on-board
scripting language could meet all mission operations requirements. After the conclusion of this prototype, the ScriptEase
JavaScript engine was embedded within a dedicated payload flight software application known as the Script Processor.
The JavaScript engine is isolated from the rest of the payload flight software; the Script Processor provides the only
communication path between the scripts and the rest of the JWST environment. The Script Processor accepts four
ground commands for script engine management. They are: (1) start the engine, (2) stop the engine, (3) activate a script,
and (4) stop a script. When activating a script from the ground, input parameter/value pairs are also included on the
command. The Script Processor passes the parameter/value list to the specified script upon activation. The script then
uses the parameter values to construct the appropriate series of commands and telemetry requests for execution of the
specified observatory function. Up to ten execution threads are supported so that the OPE and Activity Description
scripts can be processed in parallel.
In order for the on-board scripts to conduct event-driven operations, the Script Processor provides a set of support
functions. These custom features extend the JavaScript language and enable the on-board scripts to communicate with
each other and with the JWST flight software. Table 3 enumerates the JavaScript extensions currently supported by the
Script Processor application. The extensions can send flight software commands, receive flight software telemetry,
activate a script in another execution thread, communicate across threads of execution, record processing status and error
descriptions for ground analysis, and access on-board files. These extensions can be used within an on-board OPE and
Activity Description scripts similar to the manner that JavaScript functions are utilized.
Table 3. Script Processor support functions (JavaScript extensions)
Extension(s) Description
Set Command Parameter Value Construct one command parameter field
Send Command Deliver constructed command to router
Set Telemetry Parameter Identify one engineering telemetry item
Get Telemetry Retrieve up to 10 previously identified telemetry items
Set/Get/Delete Shared Parameter Support cross-execution thread communication
Process Script Activate specified script in a separate execution thread
Get Time Retrieve system time
Wait Pause script execution for specified duration
Send Completion Notice Deliver status information to calling thread
Issue Event Message Construct one textual event message telemetry packet
Open/Read/Close File Provide on-board file access
Delete File Remove specified file from on-board file store

The visit example shown in figure 2 can be used to illustrate how the JavaScript extensions enable event-driven
operations. An OPE script accesses the system time with the “get time” extension and compares the retrieved time with
the visit’s execution time window. When the system time is within the specified window, the OPE script opens the visit
file with the “open file” extension. The first activity statement is interrogated using the “read file” extension, and the
specified top-level Activity Description script is activated in a parallel thread with the “process script” extension. The
script activation time is recorded using the “issue event message” extension. The OPE script pauses its execution using
the “wait” extension and retrieves the Activity Description completion status with the “get shared parameter” extension.
Lower-level Activity Description scripts are implemented as JavaScript functions for easy access by the top-level
Activity Description script. Function return values are used to communicate status between script levels. The lower-level
Activity Description scripts construct and send flight software commands using the “set command parameter value” and
“send command” extensions and receive flight software engineering telemetry information using the “set telemetry
parameter” and “get telemetry” extensions. If any anomalies are encountered, then the “issue event message” extension

Proc. of SPIE Vol. 6274 62740A-6

Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 9/18/2018

Terms of Use: https://www.spiedigitallibrary.org/terms-of-use
 is used to record the error. Upon completion of all lower-level Activity Description scripts, the top-level script
communicates its final status through the “send completion notice” extension. After all the Activity Descriptions
specified in the visit file have been executed, the OPE script will delete the visit file with the “delete file” extension and
remove its file name from the on-board Observation Plan. The OPE script then moves on to the examination of the next
visit file’s time window. Figure 4 illustrates the on-board event-driven communications flow as provided for event-
driven operations.

OPE Script

Process script Send completion notice

Function call
Mid-IR Lower-level
Imaging Script Scripts
Return value

Set Cmd Parm value Set Tlm Parm

Send Cmd Get Tlm

Command
Mid-IR Flight Mid-IR
Software Hardware
Telemetry

Figure 4. Event-driven communications on board JWST. Script Processor JavaScript extensions are italicized.

5. SCRIPT DEVELOPMENT PROCESS

Several JWST organizational teams are developing the on-board software components necessary for event-driven
operations, so gathering all the script requirements is an intricate task. The JWST commanding team at the Space
Telescope Science Institute is responsible for the development of the on-board scripts. The payload flight software team
at Goddard Space Flight Center is providing the on-board JavaScript environment, and each science team is responsible
for their flight software applications, whereas the prime contractor is implementing the spacecraft flight software.
An iterative development approach based upon lessons-learned from our Hubble experience creating the operational
scripts for the final six science instruments has been established and has been in use for the past year. The important
development features are (1) concurrent implementation of the operational scripts and the associated flight software, (2)
a step-wise compilation of requirements, and (3) test-as-you-will-fly verification. Implementation work on the Hubble
science instruments taught us the benefits of designing the flight software and operational scripts collectively as a unit.
A more efficient and effective system resulted from employing an end-to-end software view. The implementation was
organized into science instrument capability units (features), so a step-wise buildup of software could be done in a
prioritized manner. By working together, simple design trades could be done early in the development process to achieve
the best functional allocation of requirements, and the simultaneous implementation enabled consideration of a more
global solution when one group encountered an issue. The ground scripts and associated flight software were
periodically tested together at the science instrument’s test facility to validate the operational scenarios, which resulted in
no interface errors during the formal integration and test period and smooth, efficient on-orbit Hubble science
operations.
The JWST on-board script development approach adapts the Hubble script development process to suit the event-driven
paradigm. One operations working group for each major observatory system have been created to define the detailed on-
board script requirements in a step-wise manner. The science instrument working groups are chartered by the prime
investigators and consist of representatives from the science team, the science instrument and payload flight software
teams, project system engineers, and the commanding team. (See figure 5 for an illustration of a science instrument

Proc. of SPIE Vol. 6274 62740A-7

Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 9/18/2018

Terms of Use: https://www.spiedigitallibrary.org/terms-of-use
 operations working group.) Each working group performs independently although there are several members who
participate in all the working groups to ensure commonality. In addition to addressing the script requirements, these
working groups serve as a forum for operational issue discussions. Most of the groups meet once a month by
teleconference as the group members are dispersed geographically. The teleconferences are used to review the
operations concept for the current capability under discussion and to comment on the script requirement updates. Most
of the actual work is done offline. Guest participants are invited for discussions of particular hardware operations thus
enabling the operation concepts to be embraced by the larger science instrument community. This presents the
opportunity to influence flight hardware and software design. Frequent discussions with knowledgeable flight hardware
and software experts at the time they are working on the JWST project are invaluable for the script developers and for
future error-free in-flight operations. It also avoids the costly retrofitting of flight software or implementing complex
operational workarounds that frequently occur when flight software development is completed before operational
requirement issues are addressed.

SI
Science

Commanding SI
Flight
Software Operation
Operations Concepts
Working
Group
JWST Script
System STScI Periodically
Science Requirements
Engineers

Payload
Flight
Software

Figure 5. An Science Instrument (SI) Operations Working Group produces operation concepts and script requirements step-
wise by science instrument feature.

Each operations working group first defines the high-level script requirements to delineate the basic functional features
for on-board script support. For example, science imaging, science multi-object spectroscopy, target acquisition,
coronographic imaging, and calibration darks are among the identified features of the mid-infrared imager. Each science
instrument team has defined about a dozen features for implementation. Once the features have been prioritized based
upon overall scientific importance, hardware development schedules, and ground testing needs, the working group
discusses and documents the operations concepts for the first item. The commanding team then drafts the on-board
script requirements that are then reviewed and approved by the operations working group. After approval, the
commanding team designs, implements, and tests the associated set of JavaScript scripts while the operations working
group moves on to the next prioritized feature. Peer reviews are held for all design, script, test plan, and test results, and
the development artifacts for each iteration are archived. The iterative requirement specification approach fits well with
the reality of science instrument development as operational strategies evolve over time during the development phase of
a mission. There is an opportunity at every discussion to revisit previous implemented items to adjust for new
information derived from ground testing or from changes elsewhere on the observatory.

Proc. of SPIE Vol. 6274 62740A-8

Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 9/18/2018

Terms of Use: https://www.spiedigitallibrary.org/terms-of-use
 5.1 Script testing
The Script Development Lab at the Science Telescope Science Institute contains a COTS payload computer hosting the
current version of the payload flight software and a COTS ground system that allows us to send real-time commands and
to view flight software telemetry. The newly developed scripts can be loaded into the payload flight software’s
operations file store, and through the use of test-driver JavaScript scripts, also loaded in the same file store, can be
executed to verify syntax and functionality. This is known as unit testing. The event message telemetry packets created
by the on-board scripts can be monitored on the ground system’s telemetry display pages to confirm proper execution.
All requirements as well as all error paths are covered during every test period, thus continually verifying that a
consistent, fully functioning set of on-board scripts has been created. As there are no science instrument applications
available at present, simple science instrument simulators implemented as JavaScript on-board scripts are used to
provide close-loop execution. Due to the event-driven nature of the on-board scripts, they cannot execute without
receiving proper telemetry at flight-like rates.
The prioritized features list is grouped into script builds with one script build delivery occurring once every nine to
twelve months during the development phase. Successful unit testing of the on-board script suite at the Space Telescope
Science Institute must be completed prior to build delivery. The script build is then integration-tested and certified on the
best available flight software environment that has a more flight-like computer, the current flight software, and science
instrument hardware simulators. Following successful integration testing, the scripts will be made available for flight-
like scenario testing against real flight hardware. The script development schedule is kept synchronized with the
Project’s Integration and Test schedule to enable the maximum use of the flight on-board scripts for system testing.

6. CONCLUSION
An event-driven command architecture is being implemented by on-board scripts, written in JavaScript, that send the
appropriate series of commands and interrogate the associated observatory telemetry. After several flight software
prototypes were completed to demonstrate the feasibility of the event-driven command concept, ScriptEase JavaScript
was selected for the on-board scripting language. A full six days-in-the-life Observation Plan prototype was executed in
2004 to illustrate science operations from program submission to flight software execution by the JavaScript engine. The
flight version of the Script Processor payload application, which hosts the scripting engine, was completed in 2005, and
Activity Description script implementation was begun using an iterative development process. Four science instrument
operations working groups have been active for over a year resulting in three script builds as of March 2006. A total of
twelve science instrument script features have been completed thus far. The next set of script builds will be integration
tested when the necessary test environment becomes available. The use of the iterative script development process that
occurs simultaneously with flight software development will enable early and frequent “test-as-you-will-fly” verification
and will reduce the risk of post-launch operational incompatibilities.

7. ACKNOWLEDGEMENTS
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, Gary Welter for providing the flight software
prototypes, and Ken Rehm for many constructive conversations, encouragement, and support during the evolution of this
event-driven architecture.

REFERENCES

1. V. Balzano and K. Rehm, “Command system architecture for NGST,” SPIE, 2002.
2. G. Welter, D. Zak, E. Greville, and V. Balzano, “JWST On-board Activity Description Script Language Evaluation
and Selection,” Report for NASA GSFC Flight Software Branch/Code 582, 2003.

Proc. of SPIE Vol. 6274 62740A-9

Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 9/18/2018

Terms of Use: https://www.spiedigitallibrary.org/terms-of-use