Previous: Control hierarchy
Up: Control hierarchy
Previous Page: Control hierarchy
Next Page: Software
Bearing these generalities in mind, it is now profitable to examine figs to , which represent the hardware of the control hierarchy of the UES-related installation.
The observers' terminal and MIMIC display are peripherals of a VAXstation, which communicates over Ethernet and NIU's with the TCS telescope control computer, with the UES/A&G 4MS, with the Autoguider processor (and its CCD controller), with the science-detector controller, and with the DMS and its link to the data reduction computer. Separate direct fast data links exist from detector controllers to the computers receiving the data (Autoguider and DMS). There is also a separate TV facility from the A&G (camera) to the observer in the control room (display), and a DECnet connection between the observers' VAXstation, the reduction VAX and the DMS processor. To add to the confusion, the VAXstation runs WINDOWS, allowing the observer to run several concurrent tasks in different computers from one terminal.
At the next level down, the following computers control more mundane details:
Each of these lower-level processors has its own repertoire of instructions; 2 sources generate most of these instructions:
Generally 1) is used during hierarchical control and responses are returned over Ethernet, while 2) is used for engineering tests. However, 2) has a command to simulate Ethernet messages and an experienced operator (support astronomer in some cases) can use the local terminal to save the day when connections fail (even in normal operation, telescope and autoguider control, and DMS operations are often done this way by preference; this is extremely confusing to the novice observer, but in practice it can be the most efficient way of coaxing results from the installation, given the presence of a highly-skilled support astronomer and/or telescope operator; it should never be the end-point of development, as it is far too failure-prone for comfort and is expensive in that it involves highly-skilled support staff rather than the observer himself).
At lower level still, BCRM, SMDM or SECU processors again have their repertoires of instructions and responses, but communicate over RS232 or similar lines with the controlling 4MS. They do not usually have an operator's terminal, but the controlling 4MS can be set to be transparent, so that the 4MS operator's terminal can perform this task.
Documentation exists for most of the processors mentioned. The observer should not need any of these, except when he gets involved in setting up new observing modes.
The more reliable the lower levels are, the higher the level of integration at which the installation can operate successfully. Hence commissioning always starts with simple functions at the very lowest level and includes the fidelity of error-reporting to the next level up. After careful verification at several levels, the observer can reliably control all elements of the system using ICL from his one terminal (that is, without using WINDOWS for transparent connections to other computers in the system, which would be cheating). Only then is it possible to set up sequences of commands in Control Files, to be processed by the observing system in `batch' mode, with the observer merely monitoring it all. Once this stage is reached, true remote observing can be contemplated for the more routine observing programmes; as indicated, we have not yet arrived at this point by a long way (and such observing will always depend heavily on preventive maintenance by site staff).