Control Command Language

In this mode the astronomer will be given direct real-time control on the instrument (or part of it), either by typing simple commands, or more frequently by running pre-edited scripts. Because the real-time system cannot be worked upon without stopping observing, it is imperative that it be as reliable as possible, and sufficiently flexible to accommodate the inevitable evolution of observing modes as the instrument becomes better understood.

Entities to be controlled are:

• the hardware, controlled through what we call the hard-real-time software, exercising detailed control of the antennas, receivers, local oscillators, correlators, ... etc.; this include commands to initiate antenna motion to the source and tracking at the requested speed, and actual requests for integration being sent to correlators.

• the quasi-real-time software, or software that must be run only when observing conditions (including time) are known, e.g. to compute source coordinates in the antenna system, prepare LO and IF filter settings according to the requested frequency and Doppler tracking parameters, ...etc. but also to reset some observing parameters, such as integration times, collimation and focus corrections according to the atmospheric data or to data pipeline products;

• the data pipeline itself, to which basic data must be passed such as which data reduction software/procedure should be used, and some input parameters which are not present in the data header information, and which cannot be guessed from the data records themselves.

The key to flexibility in the observing system is that the constructs that it deals with must be as close to the elementary hardware capabilities of the instrument as possible. This must be balanced with the need that the input to this system must be sufficiently simple to be read by experts. It is not a good use of instrument time to use it simply to test whether the output of the observer's preparation tool causes the instrument to do what the programmer expected; he should, in most cases, be able to determine that by looking at a script output by his tool.

For this reason we require that the commands should be expressed in a simple command language, for which keywords are as much as possible words in a commonly understood language (we may agree on English). The number of single-character control operators must be strictly minimal.

Desirable features in the language built-in functionalities include:

• non-ambiguous abbreviation of keywords should be accepted

• macros for abbreviation of frequently typed sequences

• procedures to which parameters may be passed

• definition of variables and arrays, with numeric or character content

• evaluation of expressions, including built-in functions

• conditional execution facilities

• loops

• error recovery facilities

• interruption facility in procedure execution

Several scripting languages with these functionalities are actually being used at various observatories. The actual choice will mostly be based on software design considerations.

Foreseen use of variables/built-in functions is the ability to react on environment data such as meteorological data, phase monitor data, sidereal time, hour angle, source elevation, but also on pipeline output such as pointing collimations, detected calibrator flux, noise, flux and snr in the output map, ...

The exact balance of functions between observer's interface, quasi-real-time system, real-time system, and data processing pipeline is in the end likely to be dictated by constraints first seen in the detailed design of the software systems. However, it is a useful planning tool to have a first guess at the capabilities of the real-time system available, not only for designing the real-time system but also for designing the preceding tools and the archive data formats. We provide this first guess in an Appendix (A), in the form of a scripting language which might control the array. Note that this language is not really intended for direct use by astronomers, nor does it provide functions necessary for the array operators to control the observing. However, as an interface in the middle of what might otherwise be regarded as a very large black box, it is hoped that it can provide a planning tool for some of the other critical elements of the software system.

A few of the more difficult decisions for this scripting language/interface may be briefly noted:

• First, the baseline design for the ALMA local oscillator system requires fairly sophisticated choices to be made about the lock points for first and second local oscillators. It is suggested that this choice be made in a tool not part of the hard real-time system. The implication of that is that, although one can make a continuum observe file that can be given to the real-time system at any time, any useful spectral line file must be prepared for a specific date by the observer's interface tool, which would then calculate the appropriate LO setup for that date. (Operators would run the observing tool for dynamically scheduled observations.) Second, the flexibility of the correlator hardware will be somewhat restricted because utilizing the full flexibility of the correlator would be technically difficult, and lead to more complication in the real-time system than desirable. Thus, we recommend that options to support different bandwidths or spectral windowing in the two halves of a baseband pair (usually used for opposite polarizations at the same frequency) not be supported.

• The suggested interface puts into the real-time system precession for J2000 to date. It is suggested that all reasonable corrections be put into the real-time system so that milliarcsecond level astrometry can be done differentially, rather than by backing out the real-time system model. It should include, eg, the latest IAU nutation, earth tides, general relativistic corrections and diurnal aberration. Interpolation of positions for solar system bodies would be supported, along with the phase correction for the first order parallax.

• Although most observing control will be done through the observer's tool, a couple of non-elementary concepts are supported by the proposed interface, in order to make the input scripts more readable for software debugging purposes by reducing the occurrence of repetitive text. These are first, macros, so that long descriptions of setups need not be repeated, and second, loops.

• Operating a subset of antennas as a subarray for calibration etc., as mentioned above is a clear necessity. It also seems useful to us to provide a second level of subarraying, permitting an observer to divide the antennas allocated to him into independent groups. Perhaps the most common use would be to detach three or four antennas to do tipping curves to evaluate the atmosphere, while the main body continues to make astronomical observations.