A very important aspect of a common software module design is that all interfaces to modules derived from this design are identical. This is not unique to object-oriented design, but it is a valuable byproduct of strong adherence to the method.
The most ubiquitous code unit in the GBT is something called a ``manager.'' In its use at the lowest levels of the system there is a one-to-one correspondence between a manager and a piece of hardware, a spectrometer, for example. The manager contains the mechanisms for receiving and computing parameter setups and for sequencing a scan on the basis of clock time. Managers can be controlled by another manager all the way up to the highest level where the scan coordinator resides. A piece of this hierarchy is shown in Figure 2
Figure 2: The hierarchy of managers in the GBT system. Each box is a
manager which shares common interface, parameter control, and scan
sequencing mechanisms with all others.
The only differences between specific instances of managers are the parameters they contain and, in the case of the lowest level managers, the hardware drivers. Each manager contains a state machine shown in Figure 3.
Figure 3: The manager state machine. Each state is shown in a rounded
box, and the actions that cause transitions between states are the arrow
labels. A typical scan sequence is Ready, Activating, Committed,
Running, Stopping, Ready. Data are acquired during the Running state.
Upon receiving an activate command the managers that are connected directly to hardware automatically sequence themselves through the Ready, Activating, Committed, Running, Stopping, and Ready states. Parent managers echo the most advanced state of any of their children.
At the beginning of a scan the scan coordinator queries each of its children to find out who has the longest delay to the beginning of the next scan, given the specified scan parameters. The antenna is usually the slowest. If the user has said, ``Start as soon as possible.'' the scan coordinator then issues the same earliest feasible start time to all sub-managers and then leaves them to go about their business until all have returned to the ready state. If the slew time to the next object is quite long, the scan coordinator might query the antenna for an update on the time-to-source estimate and issue an amended start time to everyone.
In the more complex hardware devices there is a complicated mapping of setup parameters that make sense to the user to values that are required by the hardware. In many cases the order in which the input parameters are used in the calculation of hardware values is important. The generic manager's parameter control mechanism was specifically designed to enforce the correct order of dependent parameter calculations. In most cases the user changes only a few inputs, but the current values of all the rest are still crucial. Keeping the calculation order straight while avoiding a complete recalculation of all unaffected hardware values is a very difficult coding problem. This was solved by a mechanism similar to the compiling make rules, plus a few coding rules largely enforced by the parameter class.
All managers inherit a common set of control commands such as 'set a parameter', 'start', and 'abort'. This makes building a user interface to them a very consistent bit of code construction, and it makes connecting one manager to another quite straightforward.