The need for flexibility in software design due to continually emerging requirements is an established axiom in software engineering. This need becomes even more apparent in the design for controlling general-purpose telescopes, such as the Green Bank Telescope1 (GBT); the user community by its nature puts these telescopes to innovative uses which will require changes in hardware and software. The key to achieving software flexibility is to make the system as modular as possible. The guiding philosophy in the following discussion of modularity, and indeed in the initial analysis and design of the system, is Bertrand Meyer's views on object-oriented software construction. [2] The principles of modular design (i.e., linguistic modular units, few interfaces, small interfaces, explicit interfaces, and information hiding) are fairly straightforward, but achieving them is a little more challenging in a large system where real-time concerns traditionally have over-ridden desires for modularity. [3,4,5]
The original challenge for computer programming of telescope control systems was the automatic control of hardware. Initially, computers were used to control only the dynamic aspects of a telescope such as antenna movement or Doppler tracking. The task of software as an interface between a human being and the telescope hardware was inconsequential. In the newest systems, like the GBT, all hardware control and monitoring are through digital interfaces. One is lucky to find an indicator light, let alone a switch on modern pieces of equipment. The role of software has grown greatly; besides handling the automatic aspects of the system, it must configure into a ``user-friendly" environment all the complexity generated by an array of sophisticated equipment. A new, complex piece of equipment has become the primary responsibility of the software engineer: the user. On a telescope the user may be an operator, an engineer, an observer, or even the software developer. It is a difficult interface to ``get right."
Most of the GBT analysis and design effort has gone into configuring the software that must exist between a telescope device and the user. The problems of digital interfacing, real-time controls, networking, Doppler tracking, astronomical coordinate systems, and other control issues are well-understood and almost always successfully implemented. Flexibility and modularity are important throughout the telescope, but they are critical in the cycle of information that starts and ends with the user. We took several broad steps in our strategy to achieve a modular GBT control system.
Rather than thinking of the telescope as a single instrument, the first step is to try and think of it as a laboratory filled with devices or instruments which have to be coordinated to accomplish observations. We want to minimize, at least in software, the need for the various devices to communicate with each other. We want to isolate real-time dependencies wholly within each piece of device software. We want to see if it is possible to coordinate scans via a ``set up" mechanism common to the software for each device. If so, then the scan coordination system can be set up using this common mechanism to build a hierarchy rooted at a single ``scan coordination" module. With these goals accomplished, the GBT can then be more aptly described as a laboratory where each device is a fully autonomous system, a laboratory where one may easily run subsets of devices in conjunction with each other.
The next step toward a modular design is to condense the user requirements[6] into a minimum number of functions. We determined that there are four basic functions required of a telescope control system: control, monitor, message/alarm handling, and data production. Control predominately requires information flowing from the user to the telescope; the remaining three functions require only that information flow from the telescope to the user. Having a single mechanism to handle all the information within each function greatly reduces the number of interfaces used in the system and hides almost all of the implementation details from the system's client programs.
Finally, we committed at the beginning of the project to the use of object-oriented design and C++ throughout the system, including real-time code. This decision ensured that our design remained modular from the device level down to the smallest piece of code. Encapsulating code into classes made it possible to understand how changes in one module affect the behavior of other modules. Constraints of the language also helped to keep us on track while under the pressures of schedules and needs for ``quick fixes."