2. Overview and Current Use

The Status Server serves as an open repository of status and state information available to any client within the CFHT network. Clients are able to view, create, update, remove or monitor information within the Status Server. In some respects, the Status Server could be thought of as a shared memory pool for multiple clients.

Some examples of how the Status Server is used include:

• A central staging area for the building of FITS files replacing template files. This allows FITS files to be built in a more parallel fashion without the need for explicit client-side synchronization.
• A replacement for the state information contained within passive text file databases (``par'' files. Information contained within ``par'' files require a relatively inefficient file scan from NFS mounted files.
• A source of information used in GUI status displayed and early warning systems.
• A source of instrument and session related information.
• A source of plant monitoring information.

Figure 1 shows a diagram of the software components which currently provide or use information contained within the Status Server. The low level software components can be broken down by category.

Figure 1: Status Server and Software Component Interactions

2.1 Agents and Instrument Control

Agents running under director as well as other software components involved in instrument control push information into the Status Server. For the most part, these components don't extract information from the Status Server since they are considered the ``master system of record'' for this information. The following list contains some of the agents or software components which populate the Status Server. All updates happen within the /i Status Server hierarchy.

• MegaCam fipcom agent - This agent communicates with the electronics controlling the filter jukebox, shutter, and cryovessel for MegaPrime. The agent updates both raw data values and state information in the /i/megacam/fipvar location of the Status Server.
• WIRCam filter wheel agent - This agent controls the two WIRCam filter wheels via a Galil and updates status in the /i/wircam/status location.
• WIRCam vacuum agent - This agent monitors the vacuum pressure of the cryostat via a Granville-Phillips vacuum gauge and updates status in the /i/wircam/status location.
• WIRCam temperature sensing agent - This agent monitors temperature sensors located in and around the cryostat for WIRCam. The agent communicates with a Sensoray DIN2419 16 channel temperature monitoring system and updates status in the /i/wircam/status location.
• WIRCam temperature control agent - This agent monitors and controls temperatures in the cryostat for WIRCam. Agent communicates with a LakeShore 332 temperature controller and updates status in the /i/wircam/status location.
• WIRCam guiding and acquisition system - How and where information will be updated in the Status Server for the guiding and acquisition system has yet to be defined. It is likely that the aquisition system will update acquisition state information in the Status Server for informational purposes. It may be useful to have the guider update state information in the Status Server as well (not 50Hz data).
• Espadons cassegrain agent - This agent monitors and manages the state of the hardware connected to the Espadons Cassegrain unit. This consists primarily of Galil controlled motors, calibration lamps, and temperature sensors. Information is stored in the /i/espadons/cassegrain subdirectory of the Status Server.
• Espadons spectrograph agent - This agent monitors and manages the state of the hardware connected to the Espadons Spectrograph unit. This consists primarily of Galil controlled motors and temperature sensors. Information is stored in the /i/espadons/spectrograph subdirectory of Status Server.
• Espadons guider agent - This agent monitors and manages the state of guiding for Espadons. Information is stored in the /i/espadons/guider subdirectory of the Status Server.

2.2 Plant Monitoring Information

There are several pieces of plant monitoring information which are populated in the Status Server including probe data from the datalogger, Allen-Bradley PLC information, and UPS status. All updates happen within the /p Status Server hierarchy.

• abss - This is a software program which utilizes the Allen-Bradley PLC communication library to extract data from network connected Allen-Bradley PLCs. At this point, the primary use is to monitor data for the MegaPrime cooling upper end, which is stored in the /p/plc/megaPrimeCoolingUpperEnd subdirectory of the Status Server.
• log_daemon - This is a daemon which extracts datalogger probe information and stores it every 10 seconds in the /p/logger subdirectory of the Status Server.
• ups daemon - There are two daemons, one at the summit and one in Waimea, which monitor the UPS systems. Data is updated in the /p/ups subdirectory of the Status Server.

2.3 FITS Staging Area

As previously mentioned, the Status Server is used as a central staging area for the consolidation of FITS header information. At this point, there are several Pegasus Session style handlers which have been updated to enable headers to be populated in the staging area. With Espadons and WIRCam, agents will directly update the staging area when called with ``beginfits'' and ``endfits'' commands. The staging area for FITS data is contained within the /f Status Server hierarchy.

• loggerh - This is the handler which gathers the datalogger information and populates the corresponding headers in the staging area of the Status Server.
• tcsh - This is the handler which gathers TCS information and populates the corresponding headers in the staging area of the Status Server.
• neodatah - This is a handler which is called before the exposure is taken, and before the other handlers are called, in order to set up the FITS staging area of the Status Server. It is also called after all the handlers are called at the end of an exposure to merge the FITS headers into the FITS file created by DetCom. Finally, it cleans up the FITS staging area associated with the exposure.

2.4 Graphical User Interfaces

Several interfaces have been developed to view and manipulate data within the Status Server.

• gss - This is a small gtk-based executable available on all our UNIX systems to view data within the Status Server in a fashion very similar to Windows Explorer. When called with the hidden ``-e'' option it also allows the ability to create, update, and remove objects and directories in the Status Server.
• web - There are several web pages available for viewing data within the Status Server. The RPM web server has the capability to easily set up dynamic forms to view Status Server information. An example of such a form can be found at http://rpm.cfht.hawaii.edu/ billy/megacamcooling.rpm. It is also possible to traverse the Status Server at http://www.cfht.hawaii.edu/cgi-bin/webss.
• session - Some instrument sessions have (MegaCam?) or will soon have (Espadons) GUIs which are tied very closely to the Status Server. For example, Espadons has many text fields and icons which are tied to Status Server data and are automatically updated whenever the instrument state data changes.
• telnet - It is possible to telnet into the Status Server, in order to view and manage data within it. You can telnet to the Status Server by typing ``telnet statserv statserv''. If you then type ``help'' you will see the following list of possible commands. Typing ``help <command>'' provides detailed help on the underlying command.

2.5 Other Interfaces

Other interfaces are currently in the prototype and planning stages. Now that the Status Server is populated with various bits of status data, there is an interest to archive some of the data for trend analysis and diagnostic purposes. In addition, notification messages need to be generated based on business rules designed to identify fault or warning conditions.

• archive - While not complete, a prototype archiving program has been created which takes a set of Status Server objects and deadbands stored in /ss/archive/objects and places monitors on each of these objects. The data is then stored in the file defined at /ss/archive/filename. Before putting a full archiving agent into use, more discussion need to occur regarding requirements and design. The instrumentation group is very interested in a mechanism to view history and plots of Status Server data.
• notification - A notification program has been created to send notifications to individuals based on rules defined in the /ss/notication subdirectory of the Status Server. At this point, the rules have been defined and tested to work for the PLC data for the MegaCam cooling system provided by the abss component. This program has been written based on the requirements documented in the ``Alert/Notification Requirements'' document which can be found on the web at http://software.cfht.hawaii.edu/statserv/notification.