Gary Curtis, Tom Donaldson, Rob Douglas, Andy Gerb, Mark Giuliano, Natalie Nigro (Space Telescope Science Institute)
An observation as specified by an observer needs to be configured so that it can be used by components of the ground system (e.g. schedulers, commanding, archiving). The configuration process is more than a simple translation. The process adds information to the input specification. For example, many required activities such as calibrations, data dumps, instrument configurations, and slews are not explicitly given by the observer. These activities need to be inserted into an observation plan in a way which optimizes the use of the telescope. In addition, an observation often specifies only ranges of values for input parameters. For example, an observer might specify three exposures each of which require from 10-12 minutes worth of exposing time. The choice of the actual exposing durations needs to optimize the use of the telescope. In general, the configuration process requires knowledge of the instrument and ground system and requires the ability to optimize multiple competing criteria.
As the use of service mode observing increases there will be an increased demand for flexible tools for configuring astronomical observations. The TRANS system has provided support for configuring HST observations since 1989. The system is being enhanced under the TransVERSE project. The resulting system will provide a flexible yet powerful tool for configuring astronomical observations. The TransVERSE architecture supports configuring observations through the following features:
I. The architecture separates I/O functionalities from the process of managing the structure of an observation. Structure management defines the semantics of the system. The I/O modules provide different views of the core semantics. This feature is useful if different down-stream systems require different views of the data.
II. The architecture provides an explicit search model which supports optimizing interacting criteria. Structure management is divided into two components. A search engine generates decisions about the structure (e.g. where to insert calibrations). An object model maintains the current state of an observation including the implications of search decisions.
III. The object model architecture partitions its knowledge into packages which reason about activities, physical objects, and activity schedules. Activities are entities which are scheduled on the observatory. The physical objects provide the ability to simulate themselves on a set of activities. The system re-uses the temporal constraint propagator, from the SPIKE planning and scheduling system, to reason about schedules of activities. IV. The architecture uses a constraint sequencing infrastructure to automatically track dependencies. On creation of an object, a set of constraints are executed. As the constraints execute, data dependencies are tracked and stored. Constraint enforcement code is automatically executed when a dependency is triggered. This infrastructure frees the developer from having to explicitly sequence the execution of constraints.