The role the DHS plays within the Gemini systems is that of the the data controller. DHS is data-driven, acting on any data it receives from any Gemini principal system. DHS is responsible for maintaining a permanent data store, creation of archivable media, data processing, and displaying data for quality control. These tasks are performed by the eight server programs described below and in more detail in Hill et al. (1999b).
The DHS will run at both the base and summit facilities for both Gemini Telescope locations: Cerra Pachon, Chile and Mauna Kea, Hawaii. It is expected that some subset of the set of DHS servers will run at each facility.
The primary functions of the DHS graphical user interface (GUI) are to display the current status of the DHS and to provide a means of controlling the DHS. Status information is displayed textually and graphically on the various components of the GUI. The DHS is controlled through various commands, which are typically requested from the GUI by selecting buttons.
The DHS GUI behaves like an application which is external to DHS, despite being the controller and monitor of the DHS. The GUI communicates directly to two of the eight servers described above: the Status and Command servers. Figure 1 shows the channels of communication between the DHS and the DHS graphical user interface.
The entire DHS GUI was written in Tcl/Tk (Ousterhout 1994) and uses the OCSWish (Walker & Gilles 1998) interpreter. The OCSWish Tcl/Tk interpreter was provided by the Gemini International Project Office, Software and Controls group. One facility the OCSWish interpreter provides are mechanisms for sending commands to DHS servers and for the reception of status information. The status information may be received from an Experimental Physics and Industrial Control System (EPICS) database or directly from the DHS Status server. The GUI also uses the object oriented facilities provided by the [incr Tcl]/[incr Tk] Tcl/Tk extension to encapsulate some of its components. The ESO GUI guidelines (Ballester & Comin 1993) were used to determine the general layout and design of the GUI.
The main window of the DHS console is shown in Fig. 2. This window is the only window shown when the Console is initially displayed. On the main window there are buttons that send commands to the entire DHS, such as a shutdown command. The main window also displays the current DHS status and the resource usage.
Each DHS subsystem server can be controlled from its subsystem window. A subsystem's window is displayed when the appropriate button is selected in the ``Subsystem Overview'' panel on the main window. The subsystem window also displays status information which pertains only to the particular subsystem. An example of a subsystem window is shown in Fig. 3, the Storage Server's subsystem window. The Storage Server is one of the more complex subsystem windows. The top half of the window is the same for all subsystems - standard status information plus buttons for executing the standard commands. The bottom half is a series of buttons which control the creation of media, see Dunn (1999a) for more details.
A second advantage is the ease with which the command interface and status interface have each been encapsulated into a single module/object. This was easy to implement since each has a single contact point. External software, such as the Console, should not be forced to have full knowledge of the DHS design in order to interface with it, and by having only two servers to be concerned with this is achieved. Also, the encapsulation makes maintenance and debugging of the DHS Console software easier.
The third advantage to the design is the DHS Console is able to monitor and control multiple server programs instead of using a separate GUI for each server. Screen real-estate is a precious commodity, and by having an single GUI for the entire system the real-estate required is drastically reduced.
The minimization of connections is also a disadvantage. If anything goes wrong with the status server the GUI will stop reporting status information for the entire DHS. Similarly, if the command server stops processing commands the GUI can no longer control the DHS. Having a single point of failure is an undesirable situation but the advantages of this design outweigh this disadvantage.
Ballester, P. & Comin, M. 1993, ESO Graphical User Interface Common Conventions (GEN-SPE-ESO-00000-0266) (Garching: ESO)
Dunn, J., Cockayne, S., Gaudet, S., Jaeger, S., & Albrecht, M. 1999a, this volume, 265
Dunn, J., Jaeger, S., Hill, N., Gaudet, S., & Cockayne, S. 1999b, this volume, 167
Hill, N., Gaudet, S., Dunn, J., Jaeger, S., & Cockayne, S. 1999a, this volume, 163
, 1999b, this volume, 155
Ousterhout, J. K. 1994, Tcl and the Tk Toolkit (Reading: Addison-Wesley)
Walker, S. & Gillies, K 1998, OcsWish Technical Manual
(ocs.ocs.015-OcsWishTechnical/02, Gemini Project)