Figure 1: XTE OOP Scheduling/Command process
Figure 1: PS 101 Kb
Next: Portable Astronomical Scheduling Tools
Previous: The Changing Scene at NASA Headquarters
Table of Contents --- Search ---
PS reprint
E. Johnson
Hughes-STX, GSFC, NASA, Greenbelt, MD 20771
A. Antunes
Hughes-STX, GSFC, NASA, Greenbelt, MD 20771
The XTE planning system greatly automates the whole satellite commanding process. The system is capable of going from a set of proposals to a command load with little interaction. While not being a total black box (because many scheduling decisions must still be made by the operator), it is a linear system with several checkpoints that allow verification. The handling of proposals involves coordinates, scientific time constraints, and simple mnemonics for the literally millions of possible instrument modes. These are passed through the scheduling process (with orbital events and relative time constraints) into a final output product consisting of hex commands (a subset of the STOL vocabulary used in many operations) ready for incorporation into the satellite command buffer.
Inheriting many things from ASCA (including the Needle software and some improvements to Spike), the XTE procedure improves the current state of affairs in Mission Planning/Command Generation and operations. Feedback is being provided to the Spike developers in hopes of simplifying this one admittedly complex segment of the system. Information on the overall XTE Site Operations Facility (SOF) setup is available from the XTE home page.
Our setup is shown in Figure 1.
Figure 1: XTE OOP Scheduling/Command process
Figure 1: PS 101 Kb
The XTE Mission Planning system is designed to handle normal and TOO cases within one environment. In addition, targets may have specified alternate pointings that can be chosen by a single real-time operations command, with all of the required parameters already built into the existing schedule.
Each Guest Observer (GO) proposal can contain multiple targets, with multiple pointings to a single target (for monitoring campaigns). Instrument configurations are specified by the GO and alternative modes for target occultation phases can also be given. Finally, there are a host of GO-specified observation constraints that are automatically handled by the system, specified below.
The schedule creation process ingests NASA standard FDF (Flight Dynamics Facility) ephemeris products, and calculates normal orbital events such as SAA passages and occultation as well as Sun avoidance limits, Moon occultation, and configurable limits for Earth limb avoidance. Slew calculations based on great circle approximations were originally deemed satisfactory, but to improve the current Spike/MP setup, an eigenvector slew algorithm is being installed. In addition to such time events, the MP system also provides a telemetry summary to assist in data recorder management. In addition, the Spike subsystem contains a telemetry constraint model, to prevent created schedules from overflowing the pre-specified telemetry limits.
The system then allows full manual override of all of these constraints and limits (except for Sun avoidance limits, which can safe the satellite), to allow for special handling of borderline cases and unusual requests. The system still maintains an accurate history of the schedule and keeps tracks of all the objects in the system.
The final product of Mission Planning is a pair of script-type files that encapsulate all of the desired scheduling events. These, when paired with appropriate instrument configuration files built with software supplied by the instrument teams, allow creation of the Daily Activity Plans (DAPs) that do the actual commanding.
The system requires one dedicated SparcStation with enough memory to handle large Lisp images. The LTS uses a C++ wrapper for the neural-network derived Spike scheduling package (developed by STScI and used with ASCA and EUVE). In a similar fashion, the STS also uses a C++ wrapper with Spike, as well as the GUI named Needle and several additional tools to support the special commands for the ASM (All Sky Monitor). To control costs and increase the benefits of code reuse commercial and internal class libraries were used. The entire environment works as a stand-alone setup to create two files which encapsulate all of the time-line and commanding information required. Command generation (covered only superficially in this document) processes these two files into a single command load file.
Minton, S., Johnston, M., Philips, A., & Laird, P. 1990, Proc. 8th Nat. Conf. on AI, 17