The Space Telescope Science Institute (STScI) developed the Spike planning and scheduling software in support of the Hubble Space Telescope as a general toolkit for planning and scheduling. It is our desire that this toolkit be used to promote scientific research through the effective and efficient use of ground- and space-based astronomical observatories. By providing the Spike system to other facilities, we hope to develop a community of users who use and enhance the Spike system. To the degree our resources allow, STScI will act as a clearinghouse for users, bug fixes, modifications, etc. This paper describes the Spike software and its application to HST and other astronomical scheduling problems.
1. Why Use Planning and Scheduling Tools?
Planning and scheduling is necessary to improve the quality and efficiency of science observations. Quality can be improved by planning observations under optimal conditions like minimal airmass and low background light. Planning and scheduling is also important to enforce observing constraints such as observing windows, phase requirements, and timing links between observations. Observing efficiency can be improved by maximizing the number of high quality observations made, minimizing time it takes to execute observations, minimizing wasted observations, and optimizing the use of limited resources. Scheduling tools also enhance the ability to effectively react to changes in observing conditions such as times of excellent seeing. Computer-based planning and scheduling tools can significantly improve the quality and efficiency of science observations (Johnston et al. 1993).
Automated scheduling has been common in space astronomy for years (Johnston & Miller 1994), but is relatively new to much of the ground-based community. Some of the non-traditional benefits of satellite scheduling that may be applied to other science observations are:
- interleaving observations, thus obtaining more science from the facility over a limited lifetime,
- having a facility to react quickly to changes in observing conditions or unforeseen events and generate a new observation plan if necessary,
- providing both long-term and short-term decision support tools for deciding what goes on the observing calendar.
2. What is Spike?
Spike is a general system for planning and scheduling. It was developed by STScI to support Hubble Space Telescope operations, under contract with NASA. Unlike some systems that are designed and implemented for a specific application, Spike was designed from the start to be extensible and adaptable to other application domains. Spike has a full set of features to support planning and scheduling (see Section 3). It is being used at several observatories, so there exists a community of users who can be counted on for some mutual support. STScI desires to provide Spike to other observatories to ease the task of planning and scheduling of observations, and consequently promote astronomical research.
3. Features of the Spike System
Constraints can be classified into three categories: scientific, operational, and resource constraints. Scientific constraints are specified by the observer, e.g., an observation might have a phase constraint determining when it may be executed or a spectrographic slit may require a certain orientation with respect to a galaxy. Operational constraints come into play from the limitations imposed by the way the telescope is operated, e.g., an HST observation requiring a communications link can be executed only when the communications satellite is visible. Resource constraints come into play when an observation makes use of one or more observatory resources and there are limitations on resource usage, e.g., some HST observations dump data to a tape-recorder and so there are data-rate and data-volume constraints. Spike provides a means to express these constraints and to calculate the total effect of constraints on the observations.
Spike can be used for both short-term and long-term scheduling as there is no intrinsic time granularity built into the software. Spike features a powerful and flexible scheduler which can be optimized for different scheduling problems. Schedules are never static---rescheduling is a constant task in observatory operations. Spike supports rescheduling by providing functions to lock observations in place, by the ability to specify conditional observations and by the scheduling algorithms.
4. Components of the Spike Toolkit
Spike consists of several components, including (Johnston & Miller 1994)
- a set of functions to reason with, and propagate the effects of scheduling constraints and preferences
- a scheduler based on Constraint Satisfaction Problems (CSP)
- a library of mathematical, time and astronomical utility functions.
5. HST Usage of Spike
Spike is used for the Hubble Space Telescope operations in several areas. As part of the Remote Proposal Submission System (RPS2, Bose et al. 1995), it is used by astronomers to specify observations with HST. RPS2 is a software tool which provides feedback on various aspects of a Hubble observing proposal as it is being prepared for submission to STScI. Spike is used within RPS2 to provide information on the schedulability of observations based on the implicit and explicit constraints that have been specified on the observations. Spike is also used for proposal implementation at the STScI. Spike is also used to create the long-term HST observing plan which assigns ``plan windows'' to observations.
6. Adapting Spike to a New Telescope
The main work in adapting Spike to a new telescope is in writing specialization methods for input/output, user interface, and observatory-specific constraints. Spike has already been adapted to schedule a variety of astronomical scheduling problems (see, for example, Chavan, Johnston, & Albrecht 1996). Of these, three are in or near flight operations (in addition to HST), while several others are in the prototype or planning phases. The experience of customizing for other types of problems has been actively sought during development: each case provided feedback on the approach, and led to improvements from one version to the next. Applications in which Spike was used are listed in Table 1.
The adaptation of Spike for these problems demonstrates the flexibility of the scheduling framework. As indicated above, Spike was designed so that new tasks and constraints can be defined without changing the basic framework. For some applications, Spike is operated in a hierarchical manner, with long-term scheduling first allocating observations to weeks much as they are for the HST problem (and with similar types of long-term constraints and preferences). Then each week is scheduled in detail, subject to the detailed minute-by-minute constraints of low earth orbit operation. The major changes required to implement short-term scheduling were:
- A new type of task that can have variable duration depending on when it is scheduled, and which can be interrupted and resumed when targets are occulted by the Earth or the satellite is in the radiation belt (i.e., task preemption).
- New classes of short-term scheduling constraints which more precisely model target occultation, star tracker occultation, ground station passes, entry into high radiation regions, maneuver and setup times between targets, etc.
- An interface between different hierarchical levels, by which a long-term schedule constrains times for short-term scheduling and conversely.
- A post-processor which examines short-term schedules for opportunities to extend task durations and thus utilize any remaining small gaps in the schedule to increase efficiency.