1. Introduction

1.1. Purpose of this document

1.2 Document history

1.3. Scope of the system

• Operation of detector controllers.
• Saving of images to disk.
• Assembly of a FITS header for each run.
• Status reporting.
• Automatic display of observations.

The UltraDAS consists in the server and controller software, the client software, the status displays and the automatic image-display. All are parts of the the overall observing system, and the client software and displays are specifically part of the central intelligence of the observing system. The shorthand term DAS is used below to mean the server and controller software since those parts are associated with a DAS computer.

1.4. References

1. User requirement document for the UltraDAS data-acquisition system,

ING document INS-DAS-16 by Dennis Armstrong.

2. Software Engineering Standards

by C. Mazza et al., pub. Prentice Hall 1994, ISBN 0-13-106568-8. (This is a published version of the ESA standard PSS-05.)
3. Architecture for the ING observing-system,

ING document OBS-ARCH-1 by Guy Rixon.
4. Remote procedure calls for DRAMA clients

ING document OBS-RPC-1 by Guy Rixon, RGO.
5. WWW site of the CCD laboratory at San Diego State University,

http://mintaka.sdsu.edu/ccdlab/
6. WWW site of the CCD laboratory at San Diego State University,

http://mintaka.sdsu.edu/ccdlab/
7. Guide to writing DRAMA tasks

AAO document DRAMA_GUIDE by Tony Farrell.
8. User's guide to the message log and message display

ING document OBS-TALK-4 by Guy Rixon, RGO.

2. General description

2.1. Relation to other projects

The UltraDAS will be an important part of the programme to replace the VAX-ADAM system on the WHT. It may be the first part of that programme to release software.

The second phase of the INGRID development is expected to use the UltraDAS. IAC's LIRIS project will probably use UltraDAS too. The NAOMI project requires INGRID in its phase-2 form and so depends on the UltraDAS.

The 2-chip-mosaic camera for the WHT requires the UltraDAS to reach its planned performance.

Future detectors for ING are all expected to use SDSU controllers through the UltraDAS. Some planned cameras have large mosaics of detectors with many readout channels each. To accommodate these, the DAS has to be able to operate more than one detector controller per camera.

UltraDAS itself depends on the continued support for DRAMA. If ING chooses to dispense with DRAMA, then a large part of the UltraDAS will have to be replaced.

UltraDAS depends critically on the production of a PCI interface by the CCD laboratory at SDSU.

2.2. Environment and constraints

The project brief requires some of the code from the Data-Cell DAS to be re-used. This means that the server software must run on Solaris. To host the interfaces to the detector controllers in a PCI bus, the DAS computer must be from the Sun Ultra series or a clone of that kind.

To meet the release timescales, the architecture of the observing system must follow directly from the work on the INT and JKT [3]; there is no time to develop or import an alternative. UltraDAS assumes that:

• There is a system computer, running Solaris.
• The DAS has a dedicated computer, also running Solaris.
• The DAS computer runs server software and the system computer runs client programs. The two are linked by DRAMA [7].
• Some client programs are the transient kind, as described in OBS-ARCH-1 [3] and OBS-RPC-1 [4]; they use libcia [4]. The displays are resident clients and do not use libcia.
• The message-logging and display facility ("Talker") [8] is available.
• X-windows displays can be used.

2.3. Model description

2.3.1 Actors

• An observer is typically a guest observer on a PATT observing-programme and so cannot be expected to know the system or to have any technical ability. UR22 [1] applies to these people. An observer can also be a staff astronomer or a member of technical staff; not all observers are technical novices.
• Telescope operators (TOs) are distinguished from observers only by the fact that the system has to provide them duplicates of some controls. TOs are not expected to drive the UltraDAS during observing but they must be able to start it and monitor its performance.
• The Duty Engineer (DE) is the sole member of technical staff available to provide support at night. The DE roster includes individuals from many disciplines, so the DE role for the UltraDAS must either assume no special abilities, or must specify particular procedures in which DEs should be trained.
• A change crew member is the person on the team doing an instrument or detector change who is tasked to connect up and test the cameras. As with the DE, no special knowledge can be assumed, and standard procedures need to be laid down.
• A detector specialist is someone qualified to define the analogue signals fed to the detectors. Some parts of the configuration of the UltraDAS can only be done by these specialists.
• The tape copier is the member of staff who verifies D-tapes and produces C-tapes.

• The telescope-control system (TCS).
• The instrument-control system (ICS).
• The ING data-manager, being the thing that does the logging and archiving of observations.

2.3.2. States of a camera

Disconnected:

powered down, or not connected to the host computer.

Unclaimed:

cabled to DAS computer and powered up, but not in use by any software.

Unrecognized:

as "unclaimed", but the camera reports an identity for which the system has no profile; the camera cannot be used.

On-line:

contactable by clients on the system computer.

Idle:

in communication with the system computer but not executing a command.

Busy:

executing a command on behalf of the system computer.

Laboratory mode:

in use by a laboratory tool such as ccdtool (see the section on UIs, below).

When a camera goes from "unclaimed" to "on-line", it is ready for use. It has initialized itself from its profiles. Observers can send commands to the camera after it goes from "on-line" to "idle" [SR1.4].

The camera is "busy" while it is executing a user command during observing. The natural states of a detector - clearing, exposing, reading out, etc. - are all sub-states of "busy". The exact sub-state doesn't have much effect on the usage since the camera has to go back to "idle" before the user can do anything else.

Apart from moving simultaneously to the "unclaimed" state if the DAS computer crashes or is rebooted [SR1.5], cameras change state independently. There are no significant states of the DAS as a whole once its computer is running.

2.3.3. Data flows

The handling of pixels [SR2.1] (separately from other data) occurs entirely within the UltraDAS. In abstract terms, the source of data is the detector groups. More exactly, the video board of the detector controllers is on the boundary of the system and is the proximate source [SR2.1.1]. The destination of the data from an observation is a FITS file on the disc-server [SR2.1.2].  In the most general case (and one has to be general at this level to take account of the range of cameras that the UltraDAS supports) the pixel processing consists of a pipeline with a signal processing part [SR2.1.3] and a bulk-data processing part [SR2.1.4], separated by a buffer [SR2.1.5]. Signal processing defines the values of individual pixels and data handling arranges the pixels in a recognized raster format, taking into account windowing and binning of the readout.

This is shown in the data-flow diagram for pixels.

The nature of the detectors means the detector controller has to do the signal processing in real time without compromising detector performance [SR2.1.3]. The bulk manipulation of pixels has to be done in the DAS computer (the controllers don't have enough memory or processing power) [SR2.1.4] and the latter machine can't work to hard real-time constraints. Hence, the pipeline has to have a buffer in the middle [SR2.1.5]. Changing the pixel format from 16-bit unsigned integers to FITS format (signed 16-bit integers or 32-bit reals) could be put either side of the buffer, but has been shown as part of the signal processing here.

The data for FITS headers come in to the system from the cameras [SR2.2.1], the TCS [SR2.2.2], the ICS [SR2.2.3]. Some (e.g. the title of the observation) come directly from the observer as part of the command that starts an observation [SR2.2.4].

The TCS and ICS produce complete FITS packets which the system can copy verbatim into a FITS header. This is a standard arrangement of the observing system which needs to be preserved in the UltraDAS [SR2.2.5].

The packets describing the camera and the formatting of the output image are produced in the DAS [SR2.2.6].

The world-coordinate-system packet combines pointing data from the TCS, geometry data from the TCS and configuration/format data from the camera; the latter are more numerous. To avoid unnecessary coupling, this packet is made inside the UltraDAS [SR2.2.7]. It would be simpler to make the WCS packet in a post-processing chain (outside the system), but it is more desirable to have the data made in time for use in the automatic display.

These flows in transformations are shown in the data-flow diagram for FITS headers.

The data-flow diagram for completed observations shows how the UltraDAS fits into the observatory's data-management process.

The boxes on the right of the diagram represent the observatory's data products. The UltraDAS can produce none of these by itself; they require interoperation with the disk server [SR2.3.1], the data manager [SR2.3.2] and the FITS-tape packages [SR2.3.3].

The boxes on the left are the displays produced to aid observing. The UltraDAS produces the image display, but the display of the night report comes from the Data manager. The image display could be arranged either as a co-operation with the disk server  [SR2.3.4], or a direct data-feed from the DAS [SR2.3.5].

The flow of observations emphasizes the central role of the disk server. This installation is a single point of failure for all outputs. The organization and naming of files on the disk server has to be an agreed standard [SR2.3.6] between the UltraDAS, the data-manager and the tape packages. The users also have to know the location of files to do local data-reduction.

2.3.4. Concepts and associations

The first diagram defines what constitutes "a camera" [SR3.1]. Note the concept of detector group to describe the detectors operated by one controller.

The second diagram illustrates how the detector controllers of a camera are connected to the DAS. It show the number of parallel readouts that the DAS is required to support [SR3.2]. Note that one DAS (there could be more than one DAS per observing system!) can either serve a few single-channel cameras or one camera with several detector groups but not both at once. The hardware prevents many multi-detector cameras being used at once.

The third diagram shows how the system identifies the attached cameras and determines their configuration [SR3.3]. By the use of plugs carrying an ID code, the connections between detector groups, detector controllers and the DAS can be determined in software and used to set the configuration by matching the IDs against a library of profiles. The system is almost self-configuring, but it may need to take account of the instrument in use. This latter information comes in from the CIA and modifies the choice of profile. If there are no instrument-specific features, or if those features can be embodied as alternatives within one profile, then the system becomes much simpler to work with.

The engineering profiles are written and filed when a new camera is released onto the system. They define the settings of the camera that only a specialist can set; in particular, the profile defines which controller software to run [SR3.4].

The user profiles modify the defaults in the engineering profiles for user-selected settings uch as the size and position of windows. The users profiles are the system's memory of the preferred settings and are built up as the observers configure a camera for observing [SR3.5].

2.3.5. User interfaces

The laboratory software is expected to be the program ccdtool or one of its variants. These programs have built-in graphical interfaces [SR4.1].

The engineering software, used to investigate and configure a camera separately from the observing system, will be a program with a built-in graphical interface [SR4.2]. This tool consists in

• a mimic display of the state of the camera [SR4.2.1;
• an editor window in which the user can view and alter the engineering profile [SR4.2.2];
• a limited set of controls [SR4.2.3] for
• applying the engineering profile;
• resetting the camera;
• setting readout formats;
• taking test frames.
• controls for selectively starting and stopping individual cameras [SR4.2.4].

The observer's interface to the UltraDAS is a varied set of GUI programs [SR4.3]. The DAS display is merged with the mimics and GUIs for the instrumentation [SR4.3.1]; e.g., the wide-field camera mimic has displays for the filter wheel, shutter and CCDs in the same window. Hence, the graphic design of the display is expected to differ from instrument to instrument, forcing the production of multiple GUIs. To make these programs more manageable, there must be a standard interface into the DAS from which state data can be read [SR4.3.2] and a standard interface for giving commands [SR4.3.3].

The engineering interface is a simple client of the DAS that can be run on the DAS computer.  The observer interface
is part of the CIA and has to be run on the system computer.

The engineering and observer interfaces can be "attached" to a camera at the same time in the sense that both can display the camera's state.  Only one interface should send commands at a time; the interlocking between engineering and observing commands will be minimal.  The two interfaces can send commands alternately.

2.3.6. Use cases

• Prepare to observe
• Observe classically with a CCD
• Observe with INGRID
• Observe with Taurus
• Observe with a CCD photometer
• Move observations from disk to tape

• Prepare detector in lab.
• Introduce new detector
• Change cameras
• Tune a camera
• Perform DE checks
• Test a camera

3. Specific responsibilities