next up previous
Next: Common Interfaces to Hardware Up: Object-Oriented Experiences with GBT Previous: Long Analysis Phase

Modularity

Software modularity was rule number one in the GBT design. This comes from bitter experience with system interdependencies that have been extremely hard to debug in earlier telescope control implementations. The attraction of object-oriented modules is that a few generic modules can be developed and thoroughly debugged, and this robustness can be carried through to specific instantiations of these modules. This has had the added benefit that different designers of various software/hardware modules have been required to use common code libraries (in our case C++ classes) which encourage much similarity between the devices. Certainly, this similarity can be circumvented, but it is generally easier to adopt the common theme.

The adherence to modularity and code reuse has had an interesting effect on the operational aspects of the GBT system. Large closed loops are contrary to this design philosophy because they impose module interdependence. A typical example is having the start time of the data acquisition modules depend on the position of the telescope. Functionally, this make perfect sense, and it does not really introduce a great deal of complexity, but a combination of these interdependencies have quite serious consequences.

The goal of the GBT design has been that the failure or removal of any subsystem, even the antenna, will not affect the continued operation of the rest of the system. It may not make sense from the user's point of view to continue, but the intention is system robustness. How well this turns out to work remains to be seen.

This independence goal has dictated that all servo loops be closed at the lowest level possible and almost always within the same CPU. All synchronization of operation is done with a common clock which each CPU reads to the accuracy necessary to its functions. Each module is responsible for executing its commands as given, and any negotiation of actions is done with a common coordinator module.

Action sequences are grouped by ``scans'' where every action of each module is fully specified at the beginning of the scan. This could be as simple as one integration on a fixed sky position or as complex as a fast raster map of a moderately large area around a radio source. Doppler tracking, for example, is done on the basis of commanded antenna pointing, not actual pointing. Failure of a module to live up to expectations can be anything from a flagged condition to a fault error, but it affects independent modules only if a common action is decided upon at the top control level.

There is a module hierarchy in the system, but communication is strictly between parent and child.


next up previous
Next: Common Interfaces to Hardware Up: Object-Oriented Experiences with GBT Previous: Long Analysis Phase

Mark H. Clark
Thu Mar 26 09:49:56 EST 1998