We have all heard discussions about reusing software effort from one telescope to the next, but this has worked only in the very few cases where the goals, time scales, and communication proximity of two or more groups have been well matched. Too many factors that deter from system reuse are at work to assign much of the blame to the not-invented-here syndrome. We all have visions of the ``virtual telescope'' to which all software is designed and every user can use with only one learning curve. Let me finish up with a few thoughts on this from our design experience.
Every astronomical telescope is different for very good reasons. Attempts to hide these differences will usually hide the strengths of an instrument and make it more difficult for the observer to understand the telescope system. A good user interface should be informative, not an abstraction to some universal instrument.
We are pleased with the design and code structure that has emerged from the GBT effort. Our sense of a virtual telescope is one where a common connection between a user interface and the hardware control software can be defined (the dotted line in Figure 1). This connection is defined in terms of message definitions (start, set_parameter, get_parameter_value, etc.) that are independent of the specifics of the instrument. Within the GBT effort this has made building user interfaces to individual parts of the system much easier because the connections are all the same. Only the setup parameters are different.
From the programmer's point of view, the common functional elements, like scan sequencing, parameter control, and message handling, could be reused from one design to the next. To the extent that the operation of these embedded features is correct, it makes sense to carry them to other telescope implementations. However, this certainly will not happen unless the code system is documented to the extent that a knowledgeable programmer can pick up a manual like the one for, say, Tcl/Tk and start using the code system. This is an extremely tall order for any design group faced with the immediate demands from their home institution. The only alternative would be to carry a design from one project to the next in the heads of key personnel. Even then it is not clear that any of us would ever program a system the same way twice. There always seems to be a better way.
Full credit for the analysis and design of the GBT monitor and control system must go to the software engineers, particularly Mark Clark (project leader), Joe Brandt, John Ford, and Aron Benett of the NRAO in Green Bank, WV.
