Assimilating some of VLT terminology, we might implement flexible scheduling using observing blocks which are specified by the observer. The observing blocks can be scheduled dynamically, interactively, or in a fixed queue. Generally an observing block should be self contained, and be able to be calibrated independently, although it might use system calibrations such as J/K scales or bandpass. To accommodate level 2 dynamic scheduling, the parameters such as calibration intervals in an observing block could be variables. Even the calibrators might be selected in real time. A versatile scripting language is needed so that observers can control the system to a greater or lesser degree according to their expertise and wishes.
ALMA will be able to measure the phase coherence across the array and find the best calibrator and integration times to use on-the-fly. Such observing parameters, determined in real time, can be used in a dynamically determined schedule. Thus the description of the observations and post-processing of the data must allow for calibrations and observing parameters which are determined at the time of the observations. This implies that the exact amounts of time spent calibrating will not be known until run time, requiring a stastistical approach in long term time allocation and scheduling.
Most observing scripts are described in terms of various calibration cycles, mosaics, source switching, frequency switching, etc. A table driven observation is more flexible. The table could specify the 'state' of the instrument for a basic integration cycle. The state includes the source(name, coordinates, velocity etc), polarization, frequency, pointing position, correlator configuration, integration time etc. These state parameters describe the instrument from the point of view of the observer and do not include system parameters such as delay centers etc.
The observer controls the instrument interactively by requesting a particular state, or can build a script which steps or loops through various tables. The tables should be ascii files which the user can build with more or less help from friendly 'expert' programs which know how to sequence observations. Standard tables can be used for many observations, rather like subroutines (or macros). The tables can be read and edited, and archived as a record of the observations.
An expert dynamic scheduling program (level 2) will probably become the default mode of observing, unless an expert observer wants to take interactive control of the array.
Dynamic scheduling can be implemented by allowing the system to select some of the 'state' parameters. E.g. instead of specifying the source name for a phase calibrator, the observer could specify cal=phase RMS 5deg, or some such thing, as the requirement for a phase calibrator, and allow the system to select the best calibrator dynamically. The users retain control of which parameters are set by the system and which they specify directly. A close analogy is taking photographs with a camera which allows either manual or automatic setting for each of its controls. For interactive observations, the human observer can search for the best calibrator, integration times, etc, and then use them. If the observation is running from a script (remote observing in some people's terminology), then the observations can still be optimized and scheduled dynamically with feedback from the data and the weather if desired.