Next: NEWFIRM Software--System Integration Using OPC
Up: Control System
Previous: When the Observer isn't there: The OMP Feedback System
Table of Contents - Subject Index - Author Index - Search - PS reprint - PDF reprint

Vick, A., Folger, M., McLay, S., & Pickup, A. 2003, in ASP Conf. Ser., Vol. 314 Astronomical Data Analysis Software and Systems XIII, eds. F. Ochsenbein, M. Allen, & D. Egret (San Francisco: ASP), 732

The WFCAM instrument software

Andrew Vick, Martin Folger, Stewart McLay, Alan Pickup
UK Astronomy Technology Centre, Royal Observatory Edinburgh, EH9 3HJ, UK

Abstract:

WFCAM is a new wide field camera for the UK Infrared Telescope, and is currently under construction at the UK Astronomy Technology Centre. The software written for WFCAM includes a camera control and acquisition system, a survey definition system and instrument control systems. The software for control and acquisition of the science detectors has been designed as four separate channels, one for each detector, to ensure robustness and to handle the high data rate (120 GBytes per night).

1. Introduction

WFCAM is the wide field camera due to be installed at the UKIRT (the UK Infrared Telescope on Mauna Kea) in early 2004. The system is designed around four Hawaii-II detectors each 2048 pixels square. The pixel size in the focal plane is 0.4 arc-seconds; higher sampling will be provided using micro stepping of the arrays, then interleaving the result. The arrays are spaced out by 90% in the image plane. Each detector sees an area of 13.7 arc-minutes square, so in order to image a contiguous area of sky, four pointings of the instrument are required, making a super array of 0.865 degrees on a side. It is expected that a normal night's observing will produce 120GBytes of data, with a maximum of 200GBytes. Because WFCAM blocks the light path to the normal UKIRT auto-guider, the instrument provides its own auto-guider array, a 1024 pixel square line transfer CCD, which sits in the centre of the four science arrays.

2. Software overview

Figure 1 (left) shows an overview of the software system for WFCAM.

**Figure 1:** WFCAM software architecture (left) and a single camera channel (right)
$\begin{figure} %epsscale{.80} \plotone{P9-11-f1.eps} \end{figure}$

The observation preparation (OT), observation management and telescope control (TCS) systems are all well established infrastructure at UKIRT. New development has focused on survey preparation and the four channel camera control and acquisition system.

2.1 Survey preparation

The existing observation preparation system (ORAC-OT) is unwieldy for preparing the number of pointings in the planned surveys (100-21,000 pointings). To facilitate semi-automated preparation of large area surveys a new tool has been developed (Folger et al. 2004).

2.2 Observation preparation, management and control

The existing UKIRT systems have been updated to be compatible with WFCAM. Some changes have been necessary to sequence micro-stepping of the arrays and to deal with the four separate channels (one for each detector).

2.3 Instrument mechanisms

UKIRT uses EPICS mechanism control software, and standard EPICS routines have been used to provide software control similar to that used by other UKIRT instruments.

2.4 Camera channels

The WFCAM camera channels are the major new development that the UK ATC is undertaking. Each channel (see Figure 1 right) comprises:

a camera control system: a DRAMA based local control server and a version of the UK-ATC's Ultracam SDSU control and acquisition system (Beard et al. 2002);
a data handling system, based on the existing UKIRT DHS:
a data reduction system, using UKIRT ORAC-DR;
visualization using the Starlink Gaia package;
an Ultrium tape archiving system;

Each channel has been made functionally separate from the others by implementing it on its own pair of standard Intel-based PC systems. This means that:

an entire (fifth) channel can be kept to act as a replacement;
the instrument can be used with any number (1 to 4) channels in operation;
the data rate is spread across the four channels, reducing the throughput and processing requirements on individual computers.

3. The Ultracam SDSU control and acquisition system

The Ultracam camera control system was developed at the UKATC as part of the Ultracam high speed photometry system for the University of Sheffield. Ultracam is a "visiting" instrument at several observatories and has to provide a totally self-contained system. As such there was no requirement to design the camera control around existing observatory systems. Instead an effort was made to provide a modular control system, using only industry standard protocols and hardware, such that the system could be re-used in a variety of future instruments.

3.1 Architecture

The Ultracam system is based on a three-layer architecture (see Figure 2), comprising DSP

**Figure 2:** Camera acquisition system architecture
$\begin{figure} \epsscale{.40} \plotone{P9-11-f2.eps} \end{figure}$

code on the SDSU system, HTTP based servers on Linux and a real-time layer.

3.2 Real-time layer

The real-time layer has been kept as simple and efficient as possible. It handles all data transfers without any complicated parsing or examination of the data; commands to the SDSU PCI or timing DSPs are passed over the PCI bus and blocks of shared memory are handed to the SDSU DSP when data needs to be returned.

3.3 DSP Applications

Previous SDSU control systems developed and used at the ATC have used a single large DSP application. This application had to incorporate a command parser to allow data to be delivered from the host system. In part this was necessary to allow the application to support additional functionality as time went on. In the Ultracam system this style is abandoned in favor of smaller applications that perform one major task; a new mode is added to the system by creating a new, downloadable application. The command parser has been replaced by direct memory addressing; the DSP COFF code is processed to identify the locations of variables in the DSP memory map. This parameter location data is stored in an XML file so that higher level software can change the value of a variable directly.

3.4 Servers

The top level interface to Ultracam is via two HTTP servers: the camera control server which handles all interaction with DSP applications; and the data server that handles all returned (pixel) data from applications. Both the servers use XML passed in the body of an HTTP/1.0 message as a means of communication with external systems. The path element from the HTTP header is used to select the action required (download, set parameter, return status etc).

3.5 XML definition files

As part of the XML system that defines the interface to the DSP applications, the Ultracam system also provides: an expression parser that allows the DSP programmer to define the allowable ranges and values of a parameter in terms of other parameters or variables; a means of passing complicated data structures (user descriptions of observations, WCS variables or whatever) through the camera system to be placed in the output; descriptions of the data to allow automatic data processing etc.

3.6 High level interfaces

Communication with the servers, since it is based on HTTP, can be provided using almost any language. Interfaces have been generated in:

a combination of C-shell and command line tools (for simple test scripts);
Python (for more complex test scripts);
Java;
C/C++, as an API for other systems to use.

References

Beard, S. et al. 2002, Proc. SPIE, 4848, 218

Folger, M. et al. 2004, this volume, 716