James Webb Telescope Issue - 15

Commanding the James Webb Space Telescope: OSS and Event-Driven Operations
Feature
sampling and remove cosmic rays and bad pixels from
the raw images to obtain clean-looking photos that best
represent the science target. The exposures are often
done in parallel, where possible, for efficiency.
* Engineering: Occasionally, the ground system will need
to perform various activities not part of a science program.
These include detector checkouts, mirror alignments,
tests specific to science instrument mechanisms such as
NIRSpec's Microshutter Array (MSA), tuning analyses for
all the near-infrared science instruments that use hybrid
HgCdTe detectors and require readout and control via a
System for Image Digitization, Enhancement, Control, and
Retrieval (SIDECAR) ASIC, and the routine momentum
unloading of the reaction wheels via thrusters. The OPE is
capable of initiating momentum unloads autonomously,
if necessary. Still, it is preferable to understand the
spacecraft's momentum profile well enough to plan
momentum unloads well before the OPE considers
initiating one.
* Calibrations: Calibration visits typically involve internal
lamp exposures to characterize pixel-to-pixel responsivities,
dark exposures to characterize detector dark current and
electronic bias, and optical focus adjustments.
* Real-Time Handoff: There are specific activities that are
not supported by OSS and must be handed off to and
conducted from the ground. One example is a stationkeeping
maneuver that uses the thrusters to keep JWST in
its halo orbit about L2.
Some activities, particularly exposures and calibrations
between more than one science instrument, are often
performed in parallel (i.e., frequently, one device will
be doing an external exposure while another is taking a
dark exposure). Depending on the specific nature of the
activities, these parallel visits may be deemed " coordinated "
or " pure, " whereby the former requires that there are no
issues with both instruments working in parallel. The latter
allows the primary instrument to continue with the rest of
its activities in the visit if the secondary instrument(s) suffer
a non-critical failure (and otherwise allows the secondary
instruments to finish the activity currently executing if the
primary non-critically fails) [5].
A. Embedded Logic
OSS can make many sophisticated decisions because it
is a collection of onboard scripts that accept input from
the visit files and query telemetry. One such example of
efficiency involves the guide star acquisition process. At
the beginning of most science visits, OSS commands a
slew to the guide star identification attitude, followed by
the acquisition of that guide star to establish closed-loop
fine guidance control with the Attitude Control Subsystem
(ACS) in support of pointing stability [6]. This process
involves commanding the FGS to perform several
functions. Still, OSS can skip the most time-consuming
tasks if it can assess that the slew to the target will be
sufficiently small through a series of matrix calculations.
Another example of significant embedded logic is target
acquisition, where extremely fine pointing is achieved
(beyond that of guide star acquisition and tracking) via
onboard data reduction and centroiding. Some science
activities, such as coronagraphy which involves pointing
the telescope so that the star falls behind a fixed mask,
require extremely fine pointing stability. This is achieved
by taking a pre-science exposure with the instrument
of interest so that the target can first be located with
sub-pixel accuracy. The exposure, however, entails the
presence of various sources of noise, cosmic ray hits,
and bad pixels - therefore, to ensure that the target is
centroided, as opposed to something brighter such as
a hot pixel, it is necessary to clean up that image with a
series of algorithms that includes cosmic ray removal, flat
field correction, background reduction, and sometimes
the merging of dithered images [7].
B. Fault Management
Since OSS can query telemetry at any time in its
operations, it can support a fault management hierarchy.
Every time OSS sends a command, it can check whether
that command succeeded within a specific time period
or failed, timed out, or was rejected by the commanded
subsystem. If the command response were off-nominal,
then OSS would be able to respond appropriately in a
manner that considers both JWST health and safety as
well as efficiency. For example, if guide star acquisition
were to fail on every guide star candidate early in a
visit, then the OPE would see this failure, skip the rest
of the visit, and move on to the subsequent visit in
the observation plan. However, if OSS encountered
something more serious, such as a hardware failure,
then, depending on the severity of the error, OSS
may mark the associated instrument/subsystem as
unavailable for commanding by OSS and skip the rest
of the visit. This allows some of the remaining visits in
the observation plan to run, skipping those involving the
instrument marked unavailable. If the event were yet
more severe, such as another subsystem communicating
to OSS in a completely unexpected way, OSS would
respond by throwing an exception, which brings down
the OPE and puts the entire ISIM into a safe haven
mode. While marking a subsystem as available for OSS
commanding is not a lengthy process, recovering from
ISIM safe haven is a meticulous and slow process. Still, it
is in this way that OSS balances the efficiency gained by
this event-driven commanding and the health and safety
of JWST [3].
HKN.ORG
15
https://hkn.ieee.org/
James Webb Telescope Issue

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