INT-DAS-1
Issue 2.1; 16th November 1994
This document describes the astronomical requirements for operation and control of the interim data-acquisition system (DAS) at the INT. The system must satisfy these requirements to be acceptable to La Palma Operations. Since the interim DAS is a minimal system, many useful functions cannot be included. Functions that have been considered but excluded are listed. It is expected that this DAS will be upgraded and extra functionality added when the INT prime focus is installed.
The user requirements are produced in this form to ensure that the developers understand what is required of the system; the document is structured to suit a technical reader. Astronomers interested in the DAS should read also read the requirements. If any new requirements arise, the telescope manager should ensure that they appear in a later issue or this document.
1.2 Scope
The Interim Data-Acquisition System for the INT is a replacement for the Perkin-Elmer ADAM system, as described below. Its objectives are
z to provide access to observations through Unix computers (to allow easier inspections and analysis of the data);
z to reduce the time lost in in the reading out, displaying and saving of images.
z to remove obsolete and unreliable hardware - the drive box, ccd controller,lexidata and DMA tray, and to increase the commonality between all 3 telescopes in the ING.
z to remove the data acquisition from the Perkin Elmer instrument control computer, to open the way for their eventual replacement.
The system is concerned with acquisition and storage of CCD images and their accompanying telemetry.
1.3 References
[1] RGO Fox-Sbus Card Interface Specification
Technology-division document
INS-DAS-3 by Andrew Johnson.
[2] The Fibre-Optic Multiplexor: a Technical Description
Technology-division document
INS-DAS-7 by Nick Hall.
[3] Proposal for the Improved INT DAS
LPO document INTDAS-P-002b by Daniel Matthews.
1.4 Overview
Section 2 of this document explains the relationship of the DAS to current and future control systems. Some technical details of the control environment are discussed here. Section 3 lists the specific requirements that the system must satisfy if is is to be acceptable to Operations division.
At the time of writing, instruments and detectors at the INT are controlled through ADAM running on a Perkin-Elmer mini-computer known as the `instrument computer' (c.f. the WHT's `system computer'). Data from the CCDs is acquired directly into the instrument computer's memory and then written to the instrument computer's magnetic disk. The CCD controllers are the kind known as `Phase-I controllers' and pre-date the `Phase-II` or 'Dutch' controllers used at the WHT. After readout, each CCD image is displayed automatically on a `Lexidata' image-display.
The facilities for inspecting the observations on the instrument computer are minimal and no modern data-reduction software can be run. Observations are be transfered to a Unix system for analysis using tapes - however in the short term this will be speeded up by PE networking
The Lexidata displays are inadequate for large images and are not reliable. The Phase-I CCD-controllers could continue in service for some time, but impose a large maintenance cost. Ultimately, the instrument computer (which is an obsolescent design) will become unsupportable and must be replaced with a different platform. The process of acquiring images into the instrument computer's memory is delicate, has been seen to corrupt image-data and prevents other control activities running during a readout.
The new INT DAS, will remove the data-acquisition path from the instrument computer, making obsolete the Lexidata displays in the process. The Phase-I CCD-controller will be replaced with Phase-II units, which will not be controlled from ADAM.
The control system for the INT prime-focus camera will be a complete, stand-alone system that achieves the objectives above. It is expected that the new DAS will use software and hardware components developed for prime focus.
2.2 User characteristics
The main users of the system will be visiting observers: English-speaking scientists with no particular computer skills and (often) no prior experience of the system. The system should be as transparent as possible to these people, and should be forgiving of user errors. As much as possible, the user familiar with the WHT DAS, should find this system easy to use.
ING technical staff will need to use the system to check the operation of detectors. They may need access to low-level options and system-information that are hidden from the observers. Software staff will need to see evidence that the system is working correctly.
2.3 General constraints
A new DAS is required now. Except where noted in the specific requirements, functionality should be sacrificed to allow early release.
Essentially no money is available to build the initial DAS, except those funds allocated to the later, full-specification DAS and the INT prime-focus camera. At this time, there is no money for a computer to host the data acquisition. The system will have to be developed for a computer which Operations division already own, or one which they will acquire by February 1995.
2.4 Assumptions and dependencies
There is a requirement to read telemetry into the DAS from the instrument computer. This depends on networking facilities being available on the instrument computer and on the development within ADAM of a network-using program, although, serial port comms could be used as a last resort.
It is intended to build both the initial and final DAS on and for a SPARCstation running the Solaris 2 operating system.
Only one hardware interface has been considered for receiving pixel data into a SPARCstation (the S330A device supplied by Data Cell; see INS-DAS-3). If this device cannot be made to work, it is likely that this initial DAS wil be delayed.
2.5 Operational environment
The DAS will run on a SPARCstation. At the time of writing, it is intended to use the Solaris 2 operating environment at version 2.3 or later. This choice is to be agreed with Operations, who will provide the SPARCstation. An X-windows display is assumed, but most of the area of this screen will be taken up with an image display and will not be available to the DAS.
The DAS will run in parallel with ADAM. ADAM will control the instrument and the DAS will control the detector and receive and store the resulting data.
The DAS will receive data from the CCD controller via a fibre-optic connection of the type used at the WHT. The data are presented to the DAS' SPARCstation by a Fibre-optic multiplexor or `FOX-box', as described in INS-DAS-7.
The coupling between ADAM and the DAS will be the minimum necessary to achieve safe and efficient observing. The essential points of contact are as follows.
z A network connection will be provided, probably using TCP, by which ADAM can transmit telemetry (for FITS headers) to the DAS. The details of this connection will be determined during the design of the DAS.
z Some signalling mechanism will be provided such that ADAM can be informed of the end of an exposure and told to transmit the telemetry information. This connection may be a network connection using TCP, but mechanism and protocol are not yet chosen.
M1: established at a meeting attended by Chris McCowage, Emilios Halaftis, René Rutten, Daniel Mathews, Tony Bennett and Guy Rixon.
RGMR: specified in interviews with René Rutten or in subsequent mail from him.
EHH: specified in an interview with Emilios Harlaftis.
The date on each requirement is the date at which it was added to this document. This is not necessarily the date at which the requirement was first set.
All requirements are essential, except where noted in the text.
3.1 Basic operation
UR1; 02/10/94; M1.
The system shall accept pixel data from a single CCD controller via the fibre-optic interface defined in INS-DAS-7. All pixels from a single readout shall be collected together and considered to come from the same observation.
UR2; 02/10/94; RGMR.
The pixels from each readout shall be written to magnetic disk in a format approved by Operations. Disk-FITS and IRAF's native format are already approved; other formats might be approved during the design process.
UR3; 02/10/94; M1.
The disk files (or copies of them) shall be made available to the observers on a SPARCstation at ING for reduction and analysis.
UR4; 07/11/94; RGMR.
The CCD shall be able to be readout in windowed readout mode - irrespective of whether binned mode is also enabled. The system shall save windowed readouts in the same way as unwindowed, and shall size the files accordingly.
UR5; 07/11/94; RGMR.
It is desirable for the observer to be able to define multiple readout windows, and for these to be stored as images in the most efficient manner.
UR6; 10/10/94; RGMR
The system shall be able to readout the CCD binned mode. The system shall save binned readouts in the same way as unbinned readouts, and shall size the files accordingly. The system shall handle binning factors that may be set independently on each axis of the image to any integer from one to ten inclusive. Where a readout is both binned and windowed, the system shall allow for the binning when reconstructing the windows.
UR7; 02/10/94; M1.
CCD readouts may follow each other very quickly. The system shall be designed to minimize the chance of losing pixels. Ideally, the system shall become ready to receive a new readout immediately after the end of the previous readout. When this is not possible, the system must either apply an interlock or shall include displays that make it clear to the observer when it is safe to start a new observation and readout.
Whichever solution is chosen, the DAS shall work together such that the MULTRUN command continues to work as it does now.
UR8; 07/11/94; RGMR.
In producing the final image that is written to disk, it is desirable that the system shall apply a number of 90-degree rotations to produce the observer's preferred orientation.
UR9; 07/11/94; RGMR.
The system shall accept telemetry describing each observation from the Perkin-Elmer instrument computer via an interface to be designed later. The telemetry values shall be stored with the corresponding images and shall be made available with the images for archival and analysis. The system shall add to the telemetry a summary of the image's geometry; this summary shall be sufficient to determine the pixel on the CCD that produced each pixel in the final image. The resulting fits header should initilly provide the same information as the old system.
UR10; 02/10/94; RGMR.
The system shall provide a means of archiving observations to FITS tape. Ideally, this process should happen automatically as each observation is written to disk, but this automation is not essential.
UR11; 02/10/94; RGMR.
It is desirable to have each observation displayed as it is read out, but this ability is not essential. However, if the display is not automatic, the observers must be supplied with tools to display the image manually.
UR12; 07/11/94; RGMR.
Automatic logging of the observations is desirable, but it may be sufficient to use an IRAF script to extract the appropriate items from the headers.
UR13; 02/10/94; RGMR.
The observers may wish to retain any particular observation for archiving, to analyze the observation's disk-file without archiving it, or to discard it immediately. The system shall provide a way of selecting one of these options for each observation.
UR14; 02/10/94; RGMR.
The system shall include a reset control which aborts collection of the current observation and makes the system ready to receive the next observation.
UR15; 07/11/94; RGMR.
Accurate and reliable shutter timing information in the FITS headers is highly desirable.
3.2 Efficiency, reliability and ease of use
UR15; 02/10/94; RGMR.
No formal limit is set on the time taken to save each observation to disk. Data-saving times less than five seconds are desirable, and improvements down to one second are useful.
UR16; 02/10/94; RGMR.
Where local controls are provided for the DAS these should be designed to minimize mistakes by observers that could lose data or observing time. Any given operator error must not lose more than one observation, and any operator error must be recoverable within five minutes.
UR17; 02/10/94; RGMR.
No formal limits are set on reliability of the system. As a guideline, technical problems with the system should not lose more than 2% of the available observing time.
Appendix A. Document history
Issue 1.0 02/10/94 First issue.
Issue 1.1 10/10/94 Requirements for binned readout and for multrun were added. The numbering of requirements changed at this issue.
Issue 2.1 16/11/94 Preamble (sec1 & 2) modified for `Dutch' system. Windowing added, multiple windows not essential, shutter timing added. Numbering of requirements changed in this issue.