Figure: CICADA Process Model. Original PostScript figure (8kB).
|
Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.adass.org/adass/proceedings/adass96/youngp.html
Дата изменения: Tue Jun 23 21:17:40 1998 Дата индексирования: Tue Oct 2 01:50:53 2012 Кодировка: Поисковые слова: п п п п п п п п п п п п п п |
Next: Real Time Science Displays for the Proportional Counter Array Experiment on the Rossi X-ray Timing Explorer
Previous: Planning and Scheduling Software for the Hobby·Eberly Telescope
Up: Real-Time Systems
Table of Contents - Index - PS reprint - PDF reprint
Peter J. Young, Mick Brooks, Stephen J. Meatheringham, and
William H. Roberts
Mount Stromlo and Siding Spring
Observatories, Australian National University, Canberra, ACT,
Australia 2611, E-mail: pjy@mso.anu.edu.au
Computerised Instrument Control and Data Acquisition (CICADA) is a software system developed to provide access to, control of, and retrieval of data from, instruments mounted on observatory telescopes. User access is provided through a graphical user interface running on a workstation similar to those used for data reduction. Requirement and functional specifications can be found at MSSSO's Web site.
As shown in Figure 1, CICADA consists of a process group running on the observer's workstation and potentially more than one process group running on perhaps more than one instrument computer (which may also be the observer's workstation). Each process group consists of a parent control process and a set of subordinate processes, each responsible for the functioning of a subset of the system. The document CICADA Design has more detailed information of the CICADA model.
Figure: CICADA Process Model. Original PostScript figure (8kB).
Each instrument is described by a C++ class definition. This class definition is required to provide a set of generic instrument methods as well as specific methods peculiar to the instrument. The slave process for an instrument will instantiate an object for the instrument it is talking to using polymorphism (see § 3) and therefore be unconcerned with the actual type of instrument being used.
CICADA responds to action requests made by the observer. The user interface creates an instance of a control class object that starts the underlying processes and readies the system for action. Requests are then delivered to the Master process running on the local workstation which interprets the actions needed before setting the relevant slave process operating. For example, a readout request will result in a message being sent to an Archiver process to ready a FITS file and another message sent to a Slave process to begin the readout. The Master process monitors the progress of the request and delivers status information to the observer when required. The user interface process is responsible for initiating all status gathering requests.
Requests are formed using free-form text strings consisting of a verb followed by a number of optional parameter/value pairs. Requests can also be submitted in the form of a Tcl script (see § 3), so that sequences of commands can be performed.
An instrument is designed to deliver status information and, for imaging instruments, image data. When an instrument process group is running on the same machine as the observers process group, these data are delivered directly to the control class' mailbox or the waiting FITS file. Otherwise, when the instrument process group is on a remote machine, data are sent via RPC to an RPC server running on the observer's machine.
The instrument process group maintains a shared memory area (see § 3) for each process in the group to store status information. A memory area is also maintained for time-stamped, information and exception messages and is operated as a FIFO queue. Since these messages are only delivered when asked for, the queue can overflow with older messages dropping off.
CICADA has been implemented on Sun workstations running the Solaris operating system, Intel x86 machines also running the Solaris OS and partly on VAX/VMS systems. A main objective of the project has been to build the system in a platform independent way, some of the elements of this approach are described below:
CICADA has currently been built to support the following instrument types at MSSSO:
More detail on the implementation of the above can be found in the full text of this paper.
MSSSO plan to use CICADA to drive its double-beam spectrograph and a planned 8k × 8k CCD mosaic, so hardware classes for these instruments are being designed.
New instrument support from within CICADA requires the programmer to provide a C++ class definition of the hardware, a set of command definitions that are supported and a GUI or CLI module to interface with the defined class. Also important, of course, is the provision of tools for directly testing the operation of the hardware. These tools should be available for running on the instrument computer without any of the CICADA infrastructure, but by using the defined hardware class.
CICADA has been structured so that the user interface is separated from the underlying machine-specific and hardware-specific code. At the moment, the only interface is a Motif GUI developed using Sun's Sparcworks Visual. All an interface needs to do is generate the command strings expected and understood by the particular hardware class and create an instance of the specific control class to pass these commands to.
A separate stand-alone program designed to provide quick-look image analysis functions has been provided to run with CICADA. This program has an X11 GUI and allows the observer to load images as they are readout from the CCD. It can perform functions such as line plots, statistics and image arithmetic. See The GIT Users Guide for a full description.
Next: Real Time Science Displays for the Proportional Counter Array Experiment on the Rossi X-ray Timing Explorer
Previous: Planning and Scheduling Software for the Hobby·Eberly Telescope
Up: Real-Time Systems
Table of Contents - Index - PS reprint - PDF reprint