Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.adass.org/adass/proceedings/adass03/P9-11/
Дата изменения: Fri Aug 27 18:16:17 2004
Дата индексирования: Tue Oct 2 05:02:41 2012
Кодировка:
Поисковые слова: п п п п п п п п п п п п п
|
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).
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.
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}](img1.gif) |
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.
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).
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).
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.
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.
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.
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}](img2.gif) |
code on the SDSU system, HTTP based servers
on Linux and a 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.
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.
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).
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.
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
© Copyright 2004 Astronomical Society of the Pacific, 390 Ashton Avenue, San Francisco, California 94112, USA
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