Observation Sequencer: Requirements
Alan Bridger, Gillian Wright and Frossie Economou
orac005-seqr Version: DRAFT Original: 17 November 1997 Modified: 17 November 1997
This document sets out a specification and list of requirements for the Observation Sequencer part of the Observatory Control System, part of the ORAC (Observatory Reduction and Acquisition Control) project.
1.0 Introduction
1.1 Purpose
This document is intended to outline the specification of the Observation Sequencer task in the UKIRT Observation Control System and provide a list of requirements. The requirements list will consist of both user requirements and software requirements. It is intended to be read by anyone with an interest in the UKIRT Observatory Control system, and in particular by the Michelle project.
1.2 Scope
The Observation Sequencer is intended to sequence and control various subsystems in order to take observational data with UKIRT instruments. In full use it will read Observation Definitions (created by the Observation Preparation System) from the Observation Database and use the Observation Sequence part of these in order to instruct subsystems in the actions required to obtained the desired data. It will also pass information (from the Observation Definitions) to these subsystems (as names, data structures or as atomic items) that allow the subsystems to configure themselves correctly for the observation.
1.3 Overview
The rest of this document will briefly describe the UKIRT Observation Sequencer and its relations ships to other systems. A comparison with previous similar systems will also be made. The system context will be described and a brief design presented.
Finally a list of specific user and software requirements will be given.
2.0 General Description
2.1 Relationship to Other Projects
The Observation Sequencer is part of the UKIRT Observatory Control System, which in turn is one part of the UKIRT Observatory Reduction and Acquisition Control (ORAC) project. Reference [O-1] gives an overview of this project and summarises the relationships.
2.2 Predecessors
This project will build on the experience gained with the existing AIM task. This task runs only on VMS systems running the ADAM system and serves two purposes - the configuring of an instrument (specifically CGS4 or IRCAM3) and the sequencing of the instrument and telescope in order to take data. The observation sequencer will replace the latter purpose only (the configuring of an instrument will be left to an instrument-specific task).
The existing AIM task uses observing sequences known as EXECs. EXECs have been very successful in allowing UKIRT to become semi-automatic and produce efficient observing. However, they have been so successful that some of their limitations have become apparent and the opportunity provided by the general move of the UKIRT control systems to Unix leads to the suggested replacement of the system.
2.3 Function and Purpose
In summary the main functions of the Observation Sequencer are:
- To sequence all the operations required to obtain data by initiating commands in the telescope, instrument and other systems.
- To provide a simple, but flexible, interface to the user, including feedback of the progress of the observing sequence.
- To be able to read the observing sequences from the Observation Definition.
2.4 Environmental Considerations
The system should be designed bearing in mind the fact that it should be able to control all present and planned UKIRT instruments (with the exception of CGS3), as well as the existing telescope control system and other ancillary instrumentation (IRPOL, FP). It will also be required for engineering observations as well as actual observing.
Though the system should be capable of driving the existing instruments the actual implementation of this does not form part of the ORAC project.
The system should be designed to run on the Solaris operating system, but also to be reasonably portable. If an "environment" is used that environment should be DRAMA unless good reasons for other choices can be provided.
2.5 Relationship to other systems
FIGURE 1. Observation Sequencer context diagram
Figure 1 shows a context diagram for the Observation Sequencer. In this diagram the external entities are:
Observer
This represents the Observer, issuing commands to the sequencer.
Telescope Control System
This is the existing UKIRT telescope control system.
Remote Observer
This represents a potential remote observer allowed to send commands to the sequencer. The commands sent and the status received may be a subset of the full range.
Instrument Control System
This is the system that has overall control of the instrument - it can configure it and instruct it to acquire data. The instrument includes any array controller and data acquisition system.
Data Reduction System
This is the new ORAC Data Reduction System (see [O-3]).
Observing Database
This is a database of Observation Definitions as prepared by the new Observation Preparation System.
Data Handling System
This represents the system responsible for storing data and also for performing other services for the instrument control system (quick-look, provision of bad pixel masks etc.). The latter services probably have no relevance to the sequencer.
The major data flows on Figure 1 are:
observing commands
This represents the commands to observe that come from the Observer or Scheduler. They are likely to be of the form "Load this Observation Definition", "Execute it". Commands to interact with the observation may also be allowed. There may be more complex engineering commands.
observing status
This is a flow of status information - responses to observing commands or displays of the observing status.
subset of commands
This is a subset of observing commands suitable for a remote observer.
subset of status
This is a subset of observing status suitable for a remote observer.
instrument configuration
This is how the component of an Observation Definition that represents an instrument configuration gets to the instrument system. This flow may be one of three things: A name of such a configuration; a data structure ("blob" of information) containing the configuration; or a set of atomic parameters designed to achieve the configuration.
instrument commands
This represents the commands sent to the instrument control system instructing it to configure itself or to acquire data or to perform some other function.
instrument status
This is a flow of status information - usually responses to instrument commands.
data reduction commands
These are commands sent to the data reduction system informing it of new data that will arrive, or of other salient changes - a new observer, new DR recipes etc.
DR recipe
This is the data reduction recipe associated with data to arrive at the data reduction system. Its exact format is TBD. Similar to instrument configuration this may be one of two things: A name of a DR recipe or a data structure ("blob" of information) containing the recipe.
Observation Definitions
This is the flow of Observation Definitions from the database, as created by the preparation system.
dhs commands
This is the flow of commands sent to the data handling system by the sequencer informing it of changes to the data storage situation, possibly including telling it to expect certain data frames.
dhs responses
A flow of responses to the dhs commands.
header information
This is header information known or acquired by the Sequencer being made available to the Data Handling System for storage along with the associated data set.
telescope commands
This represents the commands sent to the telescope control system instructing it to configure itself or to acquire a target or to perform some other function.
telescope status
This is a flow of status information - usually responses to telescope commands.
target description
This represents the target description component of an Observation Definition. As with an instrument configuration it may be one of three things: A name of such a description; a data structure ("blob" of information) containing the description; or a set of atomic parameters designed to achieve the description.
2.6 General Constraints
Some of these are set out in Section 2.4. In addition it is assumed that the developers will
develop in a standard programming language (Fortran, C, Java, allowed) and if a "scripting" language is necessary then if possible it should be the same as the scripting language used in other parts of the ORAC project. If not then reasons should be provided and such use agreed.
2.7 Model Description
The initial model for implementation is to use EXECs, similar to their use in the AIM task, to perform the sequencing of the operations required to take data. Some necessary and desirable enhancements to this approach are:
- Extend the EXEC dictionary to include a standardised description of how to perform the required action, e.g. technology to use (ADAM message, DRAMA message, EPICS channel access), target (task name, record name), and command, etc. This might require sections in the dictionary for each system controlled.
- Extend the EXEC dictionary to contain actions not currently included (e.g. commands to the TCS regarding guide star to be used, focus position, etc.) The new actions that are required here are still to be determined, in consultation with UKIRT operations.
- Extend the EXEC parser to allow token substitution in EXECs. This will allow some standard sequences that change occasionally (e.g. how far along a slit to offset) to be more fully standardised.
- Extend the EXEC interpretor to allow some sequence actions to be executed in parallel - implies either splitting some into initiation and wait for completion or providing knowledge (in the dictionary) of which commands may be parallalised and which may not.
- Allow for concurrently executing EXEC threads.
There is a potential problem if the Gemini Observing Tool is chosen as the basis for the UKIRT Preparation System. The Observing Tool does not treat observation definitions, and in particular EXECs and Instrument Configs, in quite the same way as the present UKIRT system, although the relationship is very close. The equivalents of configs and EXECs in the OT are submerged in the full definition of an observation, rather than being separate, named, entities. It is clear that sufficient information exists to convert from one to the other but the question to be answered is when should this be done (before observing or during observing) and whether or not it will cause problems. Is there a case for more fully adopting the Gemini approach?
3.0 Specific Requirements
3.1 FO - Functional Requirements
FO1. Must control current telescope system/allow access to full API of current TCS.
FO2. Must be able to control current and planned instruments. i.e. Michelle, UIST, UFTI, CGS4 and future instruments.
FO3. Sequencer must be able to drive each instrument stand-alone (i.e. without other systems such as the TCS).
FO4. Must read the output of the preparation system.
FO5. Must co-ordinate with UKIRTDR to ensure DR gets correct recipes.
FO6. Must be able to group[1] related observations in such a way that UKIRTDR can recognise the groups.
FO7. Should be able to run some of the sequence commands in parallel with others where this is possible (e.g. slewing the telescope and configuring an instrument).
FO8. Must be able to sequence multiple (concurrent?) observations on multiple sources. (NB Desire to do calibrations in parallel with other observing).
FO9. Observation sequence must be easily interruptible.
FO10. The premature ending of a group must be communicated to UKIRTDR in some way.
FO11. Must be clear what part of the observation sequence is currently executing.
FO12. Must be able to dynamically modify current observation sequence.
FO13. Must allow for easy and rapid instrument switching.
FO14. Must allow for separation of data for different observing programmes within a night and from one night to the next. (This implies close collaboration with the author of the data storage task.)
FO15. Must allow for re-use of observations to enable calibrations to be shared between observing programmes. (Collaboration with data storage again?)
FO16. Basic system to sequence and obtain data on a single source to be delivered with Michelle.
FO17. Aim to share philosophy and code with JCMT OCS system.
FO18. Changes to CGS4 and UFTI software after Michelle delivery
3.2 Documentation Requirements
This is a list of the documentation requirements for the system. Similar requirements are placed on other parts of the ORAC project, and the numbering is the same where they are duplicated.
DO1. A programmers guide is required both on paper and html.
DO2. A user guide is required on paper and html.
DO3. User guide to be accessed from "help" in GUI.
DO4. Link to instrument cookbook written by support scientist (e.g. CGS4 manual).
DO5. Must define and document an interface to each system that it controls. For instruments this will be an interface to which future instruments must comply.