STScI Newsletter
2022 / Volume 39 / Issue 01

About this Article

D. Strickland (dstrickland[at]


The Short-Term Scheduling Branch (STSB) of the Science Operations & Engineering division (SCOPE) at STScI develops and maintains science observation scheduling systems for Hubble, Webb, and Roman using modern software engineering practices. The applications and libraries we create are used across the full Implementation phase within the lifecycle of a proposal (see Fig. 1), primarily by the Science Mission Scheduling Branch (SMSB) and the Observation Planning Branch (OSB) within the Institute, but also indirectly by observers via the constraint libraries used by the Astronomer’s Proposal Tool (APT). Specifically, STSB develops the short-term scheduling software used for Hubble, Webb, and Roman; the mission scheduling and command loading software for HST; and constraint computation libraries used across the proposal implementation phase.

This graphic shows the function of the Short-Term Scheduling Branch’s Software Usage System within the context of the proposal lifecycle.
Figure 1: STSB software within the proposal life cycle.

Most observers know that scheduling telescope time is an optimization problem akin to the classic NP-hard traveling salesman problem, with the aims of maximizing observing efficiency while also meeting the observer's needs and the observatory's constraints. At STScI this problem is separated into two parts: observations (technically specific target exposures called visits) are first assigned to a long-range plan (LRP) that narrows when the visit might be observed to a one- to two-month time-span, followed later by short-term scheduling that creates schedules covering approximately a week, where the sequence of events can be planned down to the second. Short-term schedules are later converted to the commands uploaded to the telescope for execution. With a few exceptions, visits require guide stars and their associated reference stars to be selected from the Guide Star Catalog. Constraints on when a visit can be scheduled include satisfying the observatory's Field of Regard; optional observer-specified constraints on the orientation or time of a single visit, or between many visits; the presence of suitable guide stars; the duration of slews and instrumental overheads between targets; and management of resources, such as reaction wheel angular momentum or data recorder volume.

The tools that STSB provides answer many of the core questions that astronomers from every age have used tools to answer. For example:

  • Given a set of constraints such as observing location and time, what can I see in the sky and where is it?
  • At what times can I observe a particular set of targets?
  • What stars can I use to guide me (or my telescope) to ensure I remain on track?

Unlike the mechanical Antikythera Mechanism of the ancient Greeks, or the medieval Astrolabe,1 our tools are software. It is remarkable that we deal with many concepts that would have been recognizable to ancient, Arabic, and Medieval astronomers while writing software for the most advanced telescopes humanity has ever created. That the astronomy we deal with is solved, and not the matter of active research, makes it no less interesting to work on (to us, at least!).

The STSB is comprised of Scott Stallcup (Branch Manager), John Boia, Mike Boyer, Clif Darby, Mary Galloway (Consulting), Vicki Jones, John Lecourt (Consulting), Beverly Owens, Geraldine Preval, Greig Richmond, Tyler Schmitz, Dave Strickland, and Edwin Trejo.

Multi-mission Systems

The Guide Star System (GSS) software is responsible for the determination of usable guide stars for a visit from the latest versions of the Hubble Guide Star Catalog, with specific implementations of the algorithms tailored to each of the missions. It covers the finding of candidate guide stars and their associated time and roll windows prior to visit scheduling, the selection of up to three guide stars during scheduling, and tools for marking guide stars as bad after observations were attempted, if acquisition failed.

The Moving Object Support System (MOSS) generates target ephemeris and visibility window files for moving targets (i.e., Solar System planets, moons, asteroids, and comets) to support both Hubble and Webb observations. MOSS uses the NAIF SPICE software and Solar System ephemeris data from NASA/JPL. The visits used to obtain the spectacular Hubble images of Solar System planets, moons and comets you can see on HubbleSite  were carefully checked and fine-tuned by the Program Coordinators of the OPB using MOSS to ensure the observer's science needs were met.


Unlike Hubble, which uses absolute time commanding, Webb will debut event-driven operations. On JWST itself, the Observation Plan Executive (OPE) will choose which activities to perform and when, based on ground-generated visit files that specify Observation Plan (OP) Windows within which an activity could occur. This flexibility should allow Webb to maximize its observation efficiency, for example, by intelligently moving onto the best available visit if the currently planned one failed. Thus, JWST will not have to wait for intervention from the ground.

This flexibility comes at the cost of additional up-front complexity for the JWST short-term scheduling software, the Visit Scheduling System (VSS). OP Window calculation in the presence of observer-imposed links or constraints between visits is a particular challenge. Event-driven operations do not imply that visits can be randomly scheduled like names drawn from a hat. Instead, schedulers from SMSB use VSS to plan a nominal short-term schedule of visits, in a specific order that the OPE is likely to follow. In addition to calculating astronomical and spacecraft constraints, as well as observer-induced link constraints between visits, VSS models the time variation of onboard quantities, such as reaction wheel angular momentum. For Webb the duration of slews between visits depends on the current angular momentum state of the spacecraft, which in turn depends on the actual order and duration of the preceding completed visits. Modeling angular momentum also allows schedulers to anticipate time-consuming momentum unload maneuvers that the OPE can initiate on its own.

Under the hood, VSS uses the JWST Constraint Library (JCL) which is also developed by the STSB. Applications earlier in the proposal planning and scheduling pathway, such as APT and SPIKE, also use JCL for some of their calculations.

At the time of writing (March 2022), VSS is being used to schedule the Webb commissioning visits used for mirror alignment. After years of testing and refinement, it is an exciting time for the team to see VSS used for real scheduling.


Roman will also use event-driven operations. STSB develops RVSS (the Roman Visit Scheduling System) and RCL (Roman Constraint Library), which are the Roman-specific equivalents of VSS and JCL. These packages build off the work invested in VSS and JCL, while adapting the software to Roman's particular characteristics. RVSS and RCL are under active development at present.



 [1] The first technical document written in English was penned by Geoffrey Chaucer (of Canterbury Tales fame) as a guide to using the Astrolabe for a child, possibly his son.


This site is protected by reCAPTCHA and the Google

Contact our News Team 

Contact our Outreach Office