In the GBT, a device is implemented using two sources of code: generic code from base classes which is used across all devices, and code written specifically for the device either by writing virtual methods inherited from a base class or by implementing new classes. Because the four device interfaces are identical for all devices, a larger proportion of the functionality can be designed into the base classes, and even much of the device-specific code is implemented as virtual methods. This approach allows many features to be handled wholly in the base classes.
An example of the use of base classes is the integration of the message/alarm system into the control system. A Manager's scan parameters can generate two possible errors: one is the result of user input (illegal value) and the other is the result of failures in digital interfaces (activate fault). Since some Managers may require a large numbers of scan parameters in order to define the operation of the device, specifying individual messages for illegal values and activate failures can be a non-trivial effort. In addition, there is the possibility of inconsistency of implementation across devices or even in the wording of the messages. It would be an advantage if these messages could be wholly implemented in the base Manager. Though the methods to check and activate scan parameter values are written for specific parameters in the derived Manager, these methods are called in the base class. The base Manager class uses the return value of the scan parameter virtual methods to generate and report the appropriate messages for all parameters.
Another example of integration of the control and message/alarm systems is the generation of a summary status for each device. Each message is assigned a severity level (i.e., information, notice, warning, error, fault, or fatal). The base Manager class computes a status based on its most severe message currently active. The control hierarchy of Managers that make up the control system recursively passes these summary statuses up the hierarchy so that the status of each device and subsystem reflects the most severe level of all of its messages. From this it becomes trivial to create a display for indicating statuses for the entire system.
Each individual monitor value and scan parameter is referenced by an object of the class DataDescriptor which contains a complete description of the value including name, explanation, data type, size, units, and array count (if a vector). These DataDescriptors allow more functionality to be handled by the base classes than otherwise would be possible. For example, the user-programs do not have to be rewritten (or even recompiled) to handle new devices and their associated scan parameters and monitor values since the reading, writing, communicating, and displaying of their values depends on code based on the DataDescriptors, not on compiled data types. Also, the displays can be embellished with explanations and units since the information is readily available. In fact, the DataDescriptor is complete enough that headers for FITS binary tables (Cotton et al, 1995) can be generated automatically. This allows the engineers to select any monitor point, whose values are sent to a logging program which generates files in FITS format. Likewise, the observer can select any monitor point's values to be stored as part of the observational data along with traditionally sampled values such as antenna positions and weather.