For the GBT, we were not able to build a single class that could encapsulate any possible device; however we have built a base class, the Manager, which provides a common control interface and which implements a core set of functionality required by all devices.
Since the Manager class needs to encapsulate a wide-range of devices (from simple electronic switches to weather stations to large correlators to the antenna itself), a derived class, i.e., a Device Manager, is often used to add a variety of methods specific to the needs of its device. However, as far as the control interface is concerned, i.e., defining the operation for the next scan or commanding the scan, the base class guarantees that the interface is the same for all devices. In addition, the Manager has the ability to coordinate other Managers using the control interface. The aggregate of Managers making up the control system is organized into a hierarchy where any single Manager, branch of Managers, or the entire tree is capable of acting as a unit to run scans.
In the Manager, the control or ``set-up" variables which define the operation of a device during a scan are each encapsulated in the class Parameter. A Parameter may hold primitive data types, arrays, C structures, or simple C++ classes. When given the command recalculate, the code in the base Manager class handles the set-up calculations much like a spreadsheet where the cells (Parameters) are computed from other cells via formulas. Recomputation dependencies are handled analogously to recompilation by a Makefile, i.e., only necessary computations are performed. When given the command activate, the values of ``terminal cells" are loaded into hardware. So basically, what differentiates a receiver Manager from an antenna Manager is the associated sets of Parameters. Note that all of the devices' actions must be fully described by its Manager's Parameters' values prior to the scan.
The Manager is able to maintain one control interface across all possible sets of Parameters because the one method that sets the value of a Parameter, setParameter, is capable of setting any Parameter of any type. This is accomplished with the use of C++ templates and ``void" storage pointers. The only difference in the control interface from one device Manager to the next is the possible arguments to the method setParameter. Specific Device Managers may also differ in their needs for drivers, monitoring, scanning, data collection (if a backend), and messaging (as can be seen by the Device Manager's relations in the object diagram), but none of these latter device-specific additions alters the control interface in any way.
Other than setting up a scan, a Manager is controlled by changing its state (see the state machine in Figure 2). The events causing state transitions are methods of the Manager class. Once the scan is defined, i.e., its Parameter values are set, then the Manager needs to be commanded through the stages of a scan. Some of these commands or events come through the control interface and others - for the more complex devices - are driven by a control task labeled state machine cam task in the object diagram. The state sequence for a successful scan is Ready, Activating, Committed, Running (the actual scan), Stopping, and back to Ready. A device may remain in the Activating state for as little time as it takes for a digital interface to accept a new setting, or for as long as a physical mechanism needs to complete a movement. One may also command a ``prepare," i.e., do everything to prepare for a scan without starting it. The state sequence for a prepare is Ready, Activating, and back to Ready.
A Manager which is coordinating a number of other Managers is able to synchronize the start of a scan by requesting from each of its ``children" the Earliest Guaranteed Start Time (EGST). If the Manager is initiating the scan, then it uses the EGST as the commanded start of the scan for its children. If, however, the initiating Manager is further up the hierarchy, then the Manager passes its EGST up to its parent. As can be seen, the process is completely recursive and every Manager only needs to interact with other Managers above or below it in the hierarchy. Notice that even this interaction only occurs just prior to a scan; once the scan begins each Manager is completely independent. We believe this design provides the maximum modularization while still allowing scan synchronization among devices.
The control interface for a Manager, including network access, is encapsulated in the Panel classes for control and the Recipient classes for control feedback. The feedback is important to user interfaces because the Manager, upon every action, reports back its entire state by sending lists of annotated Parameters. Thus a user program always has a complete picture of the internal workings of the control software including Parameters containing illegal values and problems with activating terminal Parameters. Note that a Manager does not differentiate between whether its parent Manager or a user program is using its control interface. Observing or engineering user-interface programs are able to ``plug" into the hierarchy at any point.