James Webb Telescope Issue - 13

Commanding the James Webb Space Telescope: OSS and Event-Driven Operations
Feature
This design, called " Absolute Time Commanding, "
has been a standard in the industry for transforming
science programs into instructions carried out
by the onboard flight software. However, these
instructions, or " commands, " assume the worst-case
timing scenario (Figure 1). Imagine a filter wheel
commanded to rotate from Position A to Position B.
HST's planning and scheduling subsystem knows
how long this rotation should take to complete. Still,
because it cannot know precisely when it ends, it
adds pad time to the calculated motion time. This
timestamped approach introduces many instances
of overhead which, while individually small, add up to a
significant amount of time lost over the mission.
Unlike HST's case, where commands must wait until their
designated time for execution, JWST follows an eventdriven
operations paradigm. Under such operations, science
activities are specified within an onboard observation
plan which points to " visit " files that may be executed at
any time within an allowed timeframe. These visit files
describe exactly what JWST must do to meet specific
program requirements. The advantage here is that these
visit activities are carried out by onboard scripts written in
a C-extended variant of JavaScript, collectively referred to
as the Operations Scripts Subsystem (OSS). OSS breaks
these visit activities into a series of low-level flight software
commands. Because these scripts are onboard, they
offer the following advantages: they immediately check
whether the visits meet the time constraints specified in
the observation plan; ensure that the visits' exposures will
not lead to exceeding the solid-state recorder data volume
Figure 2: OSS Interface to the ISIM Flight Software [4]
then OSS can skip that visit and move on to the next one in
the observation plan without delay.
During normal operations, the ground system has real-time
contact with JWST for only eight hours daily, generally in
two four-hour chunks. Using this event-driven operations
architecture, the ground system can uplink any needed
changes to the onboard observation plan within this time
period. Such changes can include starting the plan, adding
more visits, and removing visits, as well as stopping the
plan immediately after a specified visit, or after a specific
section of a visit reaches completion. In this way, the
flow that starts from astronomers detailing their science
programs and ending with OSS executing their programs in
the form of visit files can proceed uninterrupted even with
occurrences of non-critical failures. Critical failures, such as
those concerning the health and safety of the hardware,
could still result in a safe-haven event that requires the
ground to intervene before bringing JWST back to an
operational state; however, some of these failures can be
contained to their source such that OSS will simply mark
that source unavailable for commanding and continue
along the observation plan while the ground works to
resolve the contained problem concurrently [2].
Figure 1: Absolute Time Commanding vs. Event-Driven Commanding.
This example shows how the non-critical guide star acquisition failure
causes HST to skip all its activities and wait for the absolute start time
of the subsequent visit, while JWST would skip all its activities and
immediately start the next visit (as long as both visit time windows
overlap) [1].
threshold; provide fault management responses to offnominal
flight software telemetry; and contain embedded
logic that takes advantage of access to that same real-time
telemetry. If the nature of any software fault is benign (e.g.,
time constraint not met, guide star acquisition failure, etc.),
III. OSS Commanding Architecture
All files required for event-driven operations reside in
filestores in the Integrated Science Instrument Module
(ISIM). The OSS scripts and several data files they require
are permanent but can be updated as needed. Files
associated with Observation Plan (OP) segments are
uploaded weekly and are deleted as observations are
completed. The scripts are run by a Script Processor (SP)
task and executed separately by a JavaScript engine task
that can support up to ten threads of execution. The
interface to the SP Task, and therefore the ISIM flight
software services via standard task interface ports, is
provided by a set of C language extensions to the JavaScript
language. The interface between the multiple threads of
execution is provided by similar extensions that can set and
retrieve the values of shared parameters.
OSS is categorized into three sets of scripts: the
Observation Plan Executive (OPE), the Activity Description
HKN.ORG
13
https://hkn.ieee.org/
James Webb Telescope Issue

Table of Contents for the Digital Edition of James Webb Telescope Issue
