Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.adass.org/adass/proceedings/adass96/reprints/youngp.pdf Дата изменения: Thu Jan 15 01:21:23 1998 Дата индексирования: Tue Oct 2 11:44:46 2012 Кодировка: Поисковые слова: http www.astronomy.ru forum index.php topic 4644.0.html

Astronomical Data Analysis Software and Systems VI ASP Conference Series, Vol. 125, 1997 Gareth Hunt and H. E. Payne, eds.

CICADA, CCD and Instrument Control Software
Peter J. Young, Mick Brooks, Stephen J. Meatheringham, and William H. Rob erts Mount Stromlo and Siding Spring Observatories, Australian National University, Canberra, ACT, Australia 2611, E-mail: pjy@mso.anu.edu.au Abstract. Computerised Instrument Control and Data Acquisition (CICADA) is a software system for control of telescop e instruments in a distributed computing environment. It is designed using ob ject-oriented techniques and built with standard computing tools such as RPC, SysV IPC, Posix threads, Tcl, and GUI builders. The system is readily extensible to new instruments and currently supp orts the Astromed 3200 CCD controller and MSSSO's new tip-tilt system. Work is currently underway to provide supp ort for the SDSU CCD controller and MSSSO's Double Beam Sp ectrograph. A core set of processes handle common communication and control tasks, while sp ecific instruments are "b olted" on using C++ inheritance techniques.

1.

Introduction

Computerised Instrument Control and Data Acquisition (CICADA) is a software system develop ed to provide access to, control of, and retrieval of data from, instruments mounted on observatory telescop es. User access is provided through a graphical user interface running on a workstation similar to those used for data reduction. Requirement and functional sp ecifications can b e found at MSSSO's Web site.1 2. Instrument Control Model

As shown in Figure 1, CICADA consists of a process group running on the observer's workstation and p otentially more than one process group running on p erhaps more than one instrument computer (which may also b e the observer's workstation). Each process group consists of a parent control process and a set of sub ordinate processes, each resp onsible for the functioning of a subset of the system. The document CICADA Design2 has more detailed information of the CICADA model. Each instrument is describ ed by a C++ class definition. This class definition is required to provide a set of generic instrument methods as well as sp ecific
1 2

http://msowww.mso.edu.au/computing/cicada http://msowww.mso.edu.au/computing/cicada/cicada design

385

© Copyright 1997 Astronomical Society of the Pacific. All rights reserved.


386

Young et al.
CICADA Model
FITS Observer Process Group Master Archiver Displayer GIT
Image Status

Instrument Process Groups Remote Slave Data

CCD

FITS
Commands Image Status

Display

Remote Slave Data

CCD

Display
Status

Remote Slave

Filter Wheel

Status

TCS

Figure 1.

CICADA Process Model.

methods p eculiar to the instrument. The slave process for an instrument will instantiate an ob ject for the instrument it is talking to using p olymorphism (see §3) and therefore b e unconcerned with the actual typ e of instrument b eing used. 2.1. Action Requests

CICADA resp onds to action requests made by the observer. The user interface creates an instance of a control class ob ject 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 b efore setting the relevant slave process op erating. For example, a readout request will result in a message b eing sent to an Archiver process to ready a FITS file and another message sent to a Slave process to b egin 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 resp onsible for initiating all status gathering requests. Requests are formed using free-form text strings consisting of a verb followed by a numb er of optional parameter/value pairs. Requests can also b e submitted in the form of a Tcl script (see §3), so that sequences of commands can b e performed. 2.2. Data Delivery--Data Structures

Each instrument class generates its own request data structures using its own generate req method, which is called by the control class. These data structures are designed using the rpcgen programming language, to facilitate the use of RPC for inter-machine communication. 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' mailb ox 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.


CICADA, CCD and Instrument Control Software 2.3. Status and Message Passing

387

The instru process in tained for as a FIFO queue can 3.

ment process group maintains a shared memory area (see §3) for each the group to store status information. A memory area is also maintime-stamp ed, information and exception messages and is op erated queue. Since these messages are only delivered when asked for, the overflow with older messages dropping off.

Implementation and Techniques Used

CICADA has b een 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 ob jective of the pro ject has b een to build the system in a platform indep endent way, some of the elements of this approach are describ ed b elow: · Standards. It is imp ortant to adhere to accepted standards so as to achieve platform indep endence. · Ob ject Oriented Programming--C++. CICADA makes good use of the ob ject oriented techniques encapsulation, inheritance, polymorphism, and exception handling. · RPC for network communications. We have used rpcgen for painlessly building inter-machine communication links. · System V Inter Process Communications Facilities. CICADA is a system consisting of groups of coop erating processes. Much use is made of UNIX System V message passing, semaphores, and shared memory. · Posix Threads. CICADA makes little use of the Posix thread model as yet but this is planned for improved p erformance and utility. At present multi-threading is used in the Archiver and Slave processes to achieve coprocessing during I/O wait situations. · Tcl for scripting. Tcl is used to provide a command scripting facility. Standard CICADA free-form text requests can b e emb edded in a Tcl script for processing sequences of commands. · Standard Image Display programs--Ximtool, SAOtng. · Exception Handling--ANSI C++ standard. Exception handling is an imp ortant asp ect of CICADA. Throwing an exception at the level it occurs and then catching it at a convenient location is a very elegant solution in a multi-processing, distributed application. · Real-time scheduling. Sun Solaris provides a real-time scheduling class, use is made of this for time-critical functions in the instrument process group.


388 4.

Young et al. Current Applications

CICADA has currently b een built to supp ort the following instrument typ es at MSSSO: · Astromed 3200 CCD Controller. · MSSSO's New Tip-tilt Secondary. · San Diego CCD Controller. More detail on the implementation of the ab ove can b e found in the full text of this pap er.3 MSSSO plan to use CICADA to drive its double-b eam sp ectrograph and a planned 8k в 8k CCD mosaic, so hardware classes for these instruments are b eing designed. 5. Adding New Instrument Supp ort

New instrument supp ort from within CICADA requires the programmer to provide a C++ class definition of the hardware, a set of command definitions that are supp orted and a GUI or CLI module to interface with the defined class. Also imp ortant, of course, is the provision of tools for directly testing the op eration of the hardware. These tools should b e available for running on the instrument computer without any of the CICADA infrastructure, but by using the defined hardware class. 5.1. Creating the User Interface

CICADA has b een structured so that the user interface is separated from the underlying machine-sp ecific and hardware-sp ecific code. At the moment, the only interface is a Motif GUI develop ed using Sun's Sparcworks Visual. All an interface needs to do is generate the command strings exp ected and understood by the particular hardware class and create an instance of the sp ecific control class to pass these commands to. 6. Graphical Image To ol

A separate stand-alone program designed to provide quick-look image analysis functions has b een 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 p erform functions such as line plots, statistics and image arithmetic. See The GIT Users Guide4 for a full description.

3 4

http://msowww.mso.edu.au/computing/cicada/cicada adass96 http://msowww.mso.edu.au/computing/cicada/git