Ygor and the Control of Access to the GBT

Mark H. Clark, Ronald J. Maddalena, Anthony H. Minter, Richard Prestage
March 16, 2001

This memorandum lists a set of facts which describe the current software capabilities that impact the arbitration of control access to the GBT.

The GBT monitor and control software is implemented using a generic control system called Ygor.

All controls to all telescope devices are through Ygor.

There are some exceptions; the laser rangefinders are not integrated into the ygor system; there are engineering hardware panels physically located on telescope devices and the antenna has emergency stops and a dedicated control computer (OCU). However, from the normal user's point of view, all control is arbitrated via Ygor's network protocol. Therefore, any access, whether remotely from off site, from the GBT control room, or from the servo room, must pass through Ygor, and is handled identically from the Ygor point of view.

Ygor's protocol for every telescope device consists of 1) a set of input values specific to each device for defining its behavior and 2) an activate command for initiating that behavior.

Setting a device's input values has no effect on the device's behavior until the activate command is given. This two-tiered method is necessary because control must pass through software before being loaded into the hardware. In Ygor this transition is made explicit via the distinct activate command. This control method also provides the opportunity for protecting -- as far as possible from a system standpoint -- personnel and equipment. Before the activate command is accepted, the current set of input values is checked for legality; if a value or combination of values is deemed illegal, then the activate command fails and the system enters an error state. Both the setting of values and the activation can be transmitted only via Ygor's network protocol.

By the way, Ygor provides two flavors of activate: prepare and start. Prepare configures a device by activating all values required to begin (including in the case of the antenna, slewing to the source) short of actually collecting data. This can be used to minimize the time necessary to initiate an observation, by configuring devices in advance. Start is used to fully initiate a scan.

Two programs exist which use Ygor's network protocol. One is the Tcl interpreter (segeste) which Cleo uses, and the other is a Glish client (ygor_g) used by GO. Cleo's windows tend to be device specific, and its widgets tend to have one-to-one mappings to device values. GO's windows tend to be observing mode specific, and its widgets attempt to capture observing parameters. Although all normal control of all devices is via either Cleo or GO, other mechanisms (such as accessing ygor_g directly from a standard glish session) are possible; these are not in widespread use.

Currently, any account running any application using Ygor's network protocol has equal and full access to the GBT.

Each device responds to all input values and to all activate commands as they arrive regardless of their sources. Conversely, each connected application will be updated continuously via feedback of the current values and activity of the device regardless of how or where it was initiated. In other words, though multiple users can control a device in parallel, any action by any one user is made public to all users (although if the other users are not displaying the relevant windows, they may not see the changes).

Ygor's network protocol has the capability for allowing or denying access to the telescope's devices by a set of rules using any combination of sub-device, user, or user's computer, i.e., user@host accessing subdevice xxx.

These rules can be defined and modified either statically or dynamically. The Ygor level device access is not currently turned on. Telescope access through Cleo is filtered at the Cleo layer by user, host and subdevice as controlled by the rules located in a file. Note that this file does not affect other avenues of access through GO, or through ygor_g and segeste directly via command-line commands.

Ygor can fully predict an action prior to the action taking place because of its two-tiered implementation of control.

An action by any telescope device must be fully specified prior to the activate command, and input values which are already in use cannot be modified during an action. The action must be completed or aborted before any new values will be acted upon. (Note, it is possible for a User Interface to download values for the next action while the current action is in progress, but these are not acted upon until the current action ends.) For example, an antenna's movement from start to finish must be fully specified before the movement begins; if modifications are needed, the antenna must first be stopped and then reactivated to modify its movement. If the proposed command contains an illegal portion such as running into a limit, then the movement will not be initiated.

Ygor has no information concerning a telescope device's future behavior except for that defined by the current set of input values.

For example, if a set of observations is set up in batch mode. Ygor can only verify the next scan; it knows nothing of observations whose input values are yet to be specified.