Template for User Requirements Specification

EUROPEAN SOUTHERN OBSERVATORY

Organisation Européenne pour des Recherches Astronomiques dans l'Hémisphère Austral

Europäische Organisation für astronomische Forschung in der südlichen Hemisphäre

VLT PROGRAMME

VERY LARGE TELESCOPE

VLT Software

---

VLT Instrumentation Software

Template for User Requirements Specification

Doc. No.: VLT-SPE-ESO-17240-3221

Issue: 1

Date: 30/01/2004

Name Date Signature

Prepared: A.Longinotti 30/01/2004

Name Date Signature

Approved: K.Wirenstrand

Name Date Signature

Released: M.Cullum

VLT PROGRAMME * TELEPHONE: (089) 3 20 06-0 * FAX: (089) 3 20 06 514

CHANGE RECORD

ISSUE

DATE

SECTION/PAGE

AFFECTED

REASON/INITIATION

DOCUMENTS/REMARKS

30/01/2004

All

First issue

TABLE OF CONTENTS 3

1 INTRODUCTION 5

1.1 PURPOSE 5

1.2 Scope 5

1.3 Applicable Documents 5

1.4 Reference Documents 6

1.5 Abbreviations and Acronyms 6

1.6 Glossary 7

1.7 Stylistic Conventions 7

1.8 Naming Conventions 8

1.9 Problem Reporting/Change Request 8

2 OVERVIEW 9

3 USER SOFTWARE REQUIREMENTS 11

3.1 Devices 11

3.2 Modes 12

3.2.1 Blue spectroscopy 12

3.2.2 Red spectroscopy 12

3.2.3 Dichroic spectroscopy 12

3.2.4 Red Imaging 12

3.3 States 12

3.4 Configuration 13

3.5 Simulation 13

3.6 Data 13

3.6.1 Acquisition 13

3.6.2 Display 13

3.6.3 Storage 13

3.6.4 Archive 13

3.6.5 On-line processing on the Instrument Workstation 13

3.6.6 Logging 13

3.7 User Interface 14

3.7.1 User Station 14

3.8 Telescope 14

3.9 Power-up/down 14

3.10 Science operations 15

3.11 Maintenance operations 15

3.12 Templates 15

3.12.1 Acquisition 15

3.12.2 Calibration 15

3.12.3 Science 16

3.12.4 Maintenance 16

3.13 Documentation 16

3.14 Performance 16

3.15 Test 17

3.16 Safety 17

3.16.1 Interlocks 17

3.16.2 Warnings 17

3.16.3 Alarms 17

3.17 Summary of the requirements 17

1 INTRODUCTION

This document aims to provide Instrument System Engineers and Scientists with a template of Instrument Software User Requirements Specification (ISURS) document. Instrument specific ISURS documents should be based on this template. They should contain at least the structure and information described herein (whenever applicable), and possibly add instrument specific parts.

In the present document, XXXX is used to indicate the name of a generic instrument.

Examples appearing in this document are taken from the UVES and ISAAC user requirements documents.

Paragraphs in italics should be removed or at least adapted to the specific instrument.

1.1 PURPOSE

The purpose of this document is to describe the set of user requirements towards the control Software of the XXXX Instrument. Such requirements are both of scientific and technical nature and come from:

The requirements to software coming from the instrument characteristics, as described in [AD 01] and [AD 06].
The requirements to software imposed by ESO:

The standard organization of the instrument software, as described in [AD 02].
The use of hardware and software standards (common software), as described in [AD 03].
The general requirements for Cassegrain/Nasmyth Instruments, as described in [AD 04]/ [AD 05].

This is the first document entirely dedicated to Software for the XXXX Instrument It shall be applicable to all the following ones, in particular the Instrument Software Functional Specification (ISFS), which logically directly follows it

In order to trace more easily all requirements and related solutions in the next Software documents, all requirements described here have a numbered tag: [REQ nn].

This document shall be reviewed at the Conceptual Design Review (CDR), if foreseen, and in any case a few months before Preliminary Design Review (PDR). It shall be part of the CDR and PDR data package. Its contents shall be frozen at PDR. In case of exceptional changes to the requirements after PDR, once the change request has been approved by ESO, this document shall be updated accordingly.

1.2 Scope

This document defines the user requirements towards the XXXX Control Software only. Requirements towards other parts of the VLT data flow, such as the pipeline or the Observation Handling Tool (P2PP) are outside its scope.

1.3 Applicable Documents

The following documents, of the exact issue shown, form a part of this document to the extent specified herein. In the event of conflict between the documents referenced herein and the contents of this document, the contents of this document shall be considered as a superseding requirement.

Reference	Document Number	Issue	Date	Title
[AD 01]	VLT-SPE-ESO-xxxxx-xxxx	1	xx/xx/xxxx	XXXX Technical Specification
[AD 02]	VLT-SPE-ESO-17212-0001	3	30/01/2004	Instrumentation Software Specification
[AD 03]	VLT-SPE-ESO-17240-0385	3	30/01/2004	INS Common Software Specification
[AD 04]	VLT-SPE-ESO-10000-0005	2.0	23/05/2001	VLT Requirements for Cassegrain Instruments
[AD 05]	VLT-SPE-ESO-10000-0006	2	20/09/1995	VLT Requirements for Nasmyth Instruments
[AD 06]	VLT-SPE-ESO-xxxxx-xxxx	1	xx/xx/xxxx	XXXX Control Electronics Requirements
[AD 07]	VLT-ICD-ESO-17240-19200	1.3	07/06/2000	ICD between VCS and OH
[AD 08]	VLT-ICD-ESO-17240-19400	2.6	17/11/1997	ICD between VCS and Archive
[AD 09]	VLT-PLA-ESO-10000-0441	1.0	01/05/1995	VLT Science Operation Plan
[AD 10]	GEN-SPE-ESO-19400-0794	2.0	21/05/2002	Data Interface Control Document

1.4 Reference Documents

The following documents are referenced in this document.

Reference	Document Number	Issue	Date	Title
[RD 01]	VLT-MAN-ESO-17200-0888	1.0	17/08/1995	VLT Common Software Overview
[RD 02]	VLT-MAN-ESO-17200-0642	3	28/03/2003	VLT Common Software Installation Manual
[RD 03]	VLT-MAN-ESO-17230-0942	2	22/03/2002	TCS User Manual
[RD 04]	VLT-PLA-ESO-17240-2266	3	31/03/2003	INS Acceptance Test Plan Template Document
[RD 05]	VLT-MAN-ESO-17200-0981	2	16/10/1998	VLT Problem Report Change Request User Man.

1.5 Abbreviations and Acronyms

This document employs several abbreviations and acronyms to refer concisely to an item, after it has been introduced. The following list is aimed to help the reader in recalling the extended meaning of each short expression:

ADC	Analogue to Digital Converter
AIV	Assembly, Integration and Verification
API	Application Programmatic Interface
ATM	Asynchronous Transfer Mode
ATP	Acceptance Test Plan
BOB	Broker for Observation Blocks
CCD	Charge Coupled Device
CCS	Central Control Software
CPU	Central Processing Unit
DCS	Detector Control Software
DFE	Detector Front-End Electronics
DICB	ESO Data Interface Control Board
DMA	Direct Memory Access
DRS	Data Reduction Software
DSP	Digital Signal Processor
FDR	Final Design Review
FITS	Flexible Image Transport Format
FWHM	Full Width Half Maximum
GUI	Graphical User Interface
HW	Hardware
HOS	High Level Operating Software
ICS	Instrument Control Software
IEE	Institution of Electrical Engineers (UK)
IEEE	Institute of Electrical and Electronics Engineers (USA)
INS	Instrumentation Software
I/O	Input/output
ISDD	Instrument Software Design Description
ISFS	Instrument Software Functional Specification
ISURS	Instrument Software User Requirements Specification
ISUM	Instrument Software User Manual
ISMM	Instrument Software Maintenance Manual
IWS	Instrument Workstation
LAN	Local Area Network
LCC	LCU Common Software
LCU	Local Control Unit
MIDAS	ESO-Munich Image Data Analysis System, ESO-MIDAS ^TM
MS	Maintenance Software
MTBF	Mean Time Between Failures
MTBS	Mean Time Between Service
N/A	Not Applicable
OB	Observation Block
OBD	Observation Block descriptor
OLAS	On-Line Archive Subsystem
OLDB	On-Line DataBase
OMT	Object Modeling Technique
OO	Object Oriented
OS	Observation Software
OSS	Observer Support Software
PAE	Preliminary Acceptance Europe
PAF	Parameters File
PDR	Preliminary Design Review
QE	Quantum Efficiency
RAM	Random Access Memory
SNR	Signal to Noise Ratio
SOS	Supervisory Observation Software
STRAP	System for Tip-tilt Removal with Avalanche Photodiodes
SW	Software
TBC	To Be Clarified
TBD	To Be Defined
TCCD	Technical CCD
TCS	Telescope Control Software
TIM	Time Interface Module
TRS	Time Reference System
TSF	Template Signature File
UIF	(Portable) User Interface (Toolkit)
UNIX	Trademark of Bell Laboratories (operating system)
VCSOLAC	VLT Control Software On-Line Archive Client
VLT	Very Large Telescope
VME	Versa Module Eurocard
VOLAC	VLT On-Line Archive Client
WS	Workstation

1.6 Glossary

The following is defined in [AD 02]:

Ø Exposure

Ø Integration

Ø Instrument Mode

Ø Instrument Workstation

The following is defined in [AD 07]:

Ø Observation Block

Ø Template

Ø Template Signature File

The following is defined in [AD 03]:

Ø Setup file

Ø Short Hierarchical Format

The following is defined only here:

Ø User

The term user encompasses different categories:

· Engineers testing or maintaining the instrument

· ESO staff astronomers and technical operators with a deep knowledge of the instrument

· Visiting astronomers with a limited training on the use of the instrument.

1.7 Stylistic Conventions

The following styles are used:

bold

in the text, for commands, filenames, pre/suffixes as they have to be typed.

italic

in the text, for parts that have to be substituted with the real content before typing.

teletype

for examples.

<name>

in the examples, for parts that have to be substituted with the real content before typing.

bold and italic are also used to highlight words.

1.8 Naming Conventions

This implementation follows the naming conventions as outlined in [AD 03].

1.9 Problem Reporting/Change Request

The form described in [RD 05] shall be used.

2 OVERVIEW

Summarize here (about one page) the main scientific and technical characteristics of the instrument.

XXXX is an echelle spectrograph designed to provide at the VLT high resolution spectra (R=40000-120000) of targets as faint as 21st magnitude. In this type of observations the stellar flux is distributed over a large area of the detector and for faint objects the number of photo-electrons in a wavelength bin is comparable to the read-out and dark current noise of the detector. In this regime of observations the gain of the large collecting area of the 8-m VLT telescope with respect to 4-m class telescopes is very significant.

The observations of brighter objects at high S/N ratios are dominated by the shot noise. There the reduction of exposure time will make possible at one 8m telescope scientific programs which one could not be carried out on smaller telescopes because the required integration times would be too long. To make these gains of the VLT possible, it is essential that the spectrograph is very efficient. This first general requirement calls for the use of efficient components (optics, gratings and detectors), for the minimization of light losses at the entrance slit by accurate guiding and image sharpening whenever possible and for a time-efficient operation.

The second general requirement for the instrument is a high degree of stability and calibration accuracy in its wavelength scale and instrumental profile to measure velocities and to derive physical information from the spectra.

Figure 1 shows a top view of XXXX. The instrument is split in two channels, one UV-blue channel covering the spectral range 300 - 500 nm and the red one from 420 - 1100 nm, in order to optimize the efficiency by the choice of dedicated coatings and detectors and the spectral format by selection of the groves density of the echelle grating and appropriate cross disperser.

The instrument physically consists of two main parts: the main body of the instrument is mounted on a table fixed to the Nasmyth platform and covered by a light-tight enclosure which provides thermal insulation and protection from dust. The second, smaller mechanical unit is mounted on the rotator (which remains stationary in the case of UVES) and contains an optical Derotator, which delivers a fixed orientation image to the entrance of the instrument.

On the basis of the optical layout, the following observing modes are foreseen:

Blue Arm spectroscopy
Red Arm spectroscopy
Dichroic spectroscopy
Red Arm Imaging

The light beam coming from the telescope encounters the functions listed below, where a means the function can be optionally selected and a Ø means that it is always in the beam or used during every observation.

the calibration unit containing a 45-degree mirror and several lamps whose light can be projected in the spectrograph to obtain intensity and wavelength calibrations

Ø an optical image Derotator which is used to compensate for the field rotation at Nasmyth

the pre-slit filter wheel

Ø a selection mirror to send the light to either blue, red or - using a dichroic - to both arms simultaneously

After the selection mirror come the red and blue spectrographs which each contain the following functions (either red or blue):

Ø the slit unit, of which slit width and Decker height must be set

Ø a filter wheel with typically order sorting and stray light filters

Ø the cross disperser unit, a grating turret on which two gratings are mounted back to back; the angle is set according to the required central wavelength

Ø the science CCD with exposure shutter. The blue arm will employ a 2048 x2048 device, the baseline for the red is 2048 x 4096 (single chip or 2 x 1 mosaic) upgradable to 4096 x 4096 pixels (single chip or mosaic of 2K x 2K or 2K x 4K chips)

diagnostic sensors that are monitored and logged continuously, regardless of instrument set-up. About 35 of these sensor signals for monitoring of the status and temperature of cryostats, enclosure and electronics are foreseen. They detect abnormal or dangerous situations and aid in the maintenance.

Figure 1 XXXX layout

3 USER SOFTWARE REQUIREMENTS

3.1 Devices

The following tables describes the devices seen by the control electronics and related software, i.e. those devices that are to be controlled or sensors whose output is to be monitored. See also [AD 06].

Table 1Total number of devices

TYPE	SYMBOL	Total
Lamps	LAM	4
Shutters	SHU	1
Servo driven rotational motion, no limit switches	ROT	6
Servo driven linear motion (slide), limit switches	LIN	2
Servo driven rotational motion, no limit switches, used to generate a linear motion, requiring position lookup table	EXC	2
All types of sensors, simple or complex; PMT's, temperature sensors, LN2 level detectors, vacuum sensors, contacts. Analogue or logical values (in digital form).	SEN	2
Detectors	DET	2
		19

Table 2 XXXX Devices [REQ01]

#	Device	Acronym	TYPE	REMARKS	VALUES
1	Calibration mirror slide	CALS	LIN	Slide with 4 positions	telescope / sphere / ThAr1 / ThAr2
2	ThAr lamp 1	TAL1	LAM	Allows lamp standby [REQ02]	Off/Standby/On
3	ThAr lamp 2	TAL2	LAM	Allows lamp standby [REQ02]	Off/Standby/On
4	ThAr shutter	TSH	SHU		Open/Close
5	FF lamp 1	FFL1	LAM	On sphere.	On/Off.
6	FF lamp 2	FFL2	LAM	On sphere	On/Off.
7	Image derotator	DROT	ROT	It has three modes [REQ03]: 1) derotate sky (fixed position angle of slit on the sky). Position angle selectable by observer. Default: N/S 2) derotate elevation direction (align the elongation direction of the stellar image with the slit) to eliminate need for ADC 3) stationary, used with image slicer	sky/elev/stat
8	Preslit filter wheel	PFIL	ROT	Wheel with 16 positions	Free/filter1...15
9	Mode selector	MODE	LIN	Slide with 3 positions	red / blue /dichroic
10	Blue slit	BSS	EXC	Width in arcsec. The requested position shall always be approached in the direction of increasing encoder steps to minimize mechanical backlash. [REQ04]	[0.01 – 10.00]
11	Blue filter wheel	BFIL	ROT	Wheel with 24 positions	Free/filter1...23
12	Blue cross disperser	BCD	ROT	User specifies grating and order number [REQ05]. Two gratings back to back.	grat1, [9000 – 11000] grat2, [8000 – 10000]
13	Red slit	RSS	EXC	Width in arcsec.	[0.01 – 10.00]
14	Red filter wheel	RFIL	ROT	Wheel with 24 positions	Free/filter1...23
15	Red cross disperser	RCD	ROT	User specifies grating and order number [REQ05]. Two gratings back to back.	grat1, [12000 – 15000] grat2, [11000 – 14000]
16	Blue camera temperature monitoring	TMBC	SEN CRY	Value in deg C Sampling period 60 sec [REQ06]
17	Red camera temperature monitoring	TMRC	SEN CRY	Value in deg C Sampling period 60 sec [REQ06]
18	Blue CCD		DET CRY	2028 x 2048 pixels. [REQ07]
19	Red CCD		DET CRY	2028 x 4096 pixels, upgradable to 4096 x 4096 pixels [REQ08]

The total number of devices in a cryogenic environment (CRY) is 4.

According to past experience with first generation VLT instruments, the amount of moving devices in a cryogenic environment should be kept to the strictly necessary minimum. [REQ09]

3.2 Modes

The following observing modes are foreseen [REQ10]:

Blue spectroscopy
Red spectroscopy
Dichroic spectroscopy
Red Imaging

3.2.1 Blue spectroscopy

Whenever this mode is selected, the following setting must be automatically applied [REQ11]:

Mode selector mirror (MIRR) in position blue
……

3.2.2 Red spectroscopy

Whenever this mode is selected, the following setting must be automatically applied [REQ12]:

Mode selector mirror (MIRR) in position red
……

3.2.3 Dichroic spectroscopy

Whenever this mode is selected, the following setting must be automatically applied [REQ13]:

Mode selector mirror (MIRR) in position dichroic
……

3.2.4 Red Imaging

Whenever this mode is selected, the following setting must be automatically applied [REQ14]:

Mode selector mirror (MIRR) in position red
……

3.3 States

The standard instrument states and related commands to change state are described in [AD 03]. All scenarios have to fit into that scheme, because the whole common sw relies on it.

The XXXX states are the standard ones specified in [AD 03], namely:

OFF [REQ15]: part of the Software is not running and part of the LCUs and devices can be powered off.
LOADED [REQ16]: the whole hardware is powered on, the whole Software is running, but the interfaces to the hardware are not initialized.
STANDBY [REQ17]: the software and the hardware interfaces are initialized; the hardware can be not initialized.

lamps are off
shutters are closed
encoders are on
motors current is off.
Sensors monitoring is active.

ON-LINE [REQ18]: all software and hardware is loaded, initialized and active. This is the normal state during operations.

3.4 Configuration

It must be possible at any time to save and retrieve the current Instrument Configuration [REQ19].

Whenever a change to the Instrument Configuration is needed (e.g. replacement of a filter), the Software shall ask for confirmation before validating the change [REQ20].

Only authorized users can modify the Instrument Configuration [REQ21]. Observers shall never be able to accidentally modify or corrupt configuration parameters (detector clock voltages, limits, temperatures,..) however they might be interested to display them.

3.5 Simulation

The Control Software shall support degraded operations in case of problems with devices hardware. In such cases, the behavior of the device hardware shall be simulated by software in the most realistic way as possible and at the lowest level as possible [REQ22].

For training and test purposes, it shall be possible to simulate the complete Instrument hardware, thus giving the possibility to run and test templates and OBs also at locations where the hardware is not available [REQ23].

3.6 Data

3.6.1 Acquisition

Images files from the blue and red arms will have maximum formats of 2048x2048 and 4096x4096 respectively.

The fastest acquisition will take xx sec [REQ24].

The sw overhead, including data transfer to the IWS, shall not exceed xx sec [REQ25].

3.6.2 Display

All acquired image will be displayed [REQ26].

The maximum delay between end of image acquisition and end of image display shall not exceed xx sec [REQ27]

Positions and intensities shall be measurable at mouse driven cursor positions [REQ28].

Describe here all requirements, e.g. orientation, superimposing images or graphics/text etc.

3.6.3 Storage

Calibration and Observation data shall be stored in FITS files [REQ29]. The header shall conform to the ESO standards [REQ30], as described in [AD 10].

The following sensor values shall be included in the image file FITS header [REQ31].

Camera temperature at start and end of exposure, mean value and standard deviation.
…….

The typical amount of data produced and stored on disk during an observing night is xx GB [REQ32].

The maximum amount is xx GB [REQ33].

Additional requirements may come from the simultaneous usage of two detectors, each producing a separate data stream. In case of big images it might be better or even necessary to store the data on separate disks.

3.6.4 Archive

All stored FITS files shall be archived [REQ34].

The archiving operations shall not affect the duty cycle of the instrument, i.e. the archiving task shall run in background while the instrument is doing the next observations [REQ35].

3.6.5 On-line processing on the Instrument Workstation

On-line processing of the acquired data is normally done by the pipeline sw on a dedicated Workstation, and the related requirements are therefore outside the scope of this document. Whenever the results of the data processing are needed by the control sw, e.g. to decide within a template script what to do next or to set an instrument parameter to a certain value, then this part of the data processing has to run (also) on the Instrument Workstation (no feedback available from the pipeline to the Instrument Workstation). If this applies to your instrument, describe here the type of processing requested and why it must run on the IWS [REQ36]. Indicate also which tool is needed (current standard is on-line MIDAS). Examples:

Rough visibility estimates (for Interferometric instruments)
Instrument focus
…..

3.6.6 Logging

The following shall be logged [REQ37]:

Any unrecoverable error occurring during the execution of a command
Every change of status for all devices (e.g. lamp on/off, filter moved to position RED)
Every change of the state for all devices (e.g. from standby to online with related hw initialization)
Every periodical read-out of sensors values
Any warning and alarm

3.7 User Interface

Describe here any special Graphical User Interface needed for your instrument, apart from the standard ones, described in [AD 02].

The following information shall be continuously displayed in the OS Control GUI [REQ38]:

Instrument state
Instrument mode
Calibration lamp on
Filter used
Status of running exposure(s)
Available disk space
Name of last saved FITS file.

The following information shall be continuously displayed in the OS Status GUI [REQ39]:

Position of all devices (in user units)
Status of interlocks
Value of all sensors
Detector read-out main characteristics (windowing, binning, clock rate)
Active alarm conditions

3.7.1 User Station

The standard user station for an instrument is described in [AD 02] and consists of two screens. If more screens are needed, it must be indicated here as explicit requirement.

The XXXX User Station shall consist of:

Screen 1 [REQ40]:

Workspace 1: BOB GUI and OS Control GUI.
Workspace 2: OS status GUI
Workspace 3: ICS stand-alone GUI
Workspace 4: Detector stand-alone GUI

Screen 2 [REQ41]: Detector Real-Time Display GUI, Alarms GUI and Logs GUI

The editing and selection of Observation Blocks to be executed shall be done on the console screen of the Observation Handling (P2PP) Workstation [REQ42].

A separate screen shall be available for off-line data reduction [REQ43].

3.8 Telescope

Describe here all features needed from the Telescope and related sub-systems, such as auto-guiding, active optics etc. Examples [REQ44]:

Preset
Offset
Nodding
Auto-guiding
Adapter and rotator angle
M2 chopping

Presetting will result in positioning the object in the defined instrument aperture and auto-guiding, using an off-axis guide star.

The list of telescope commands and parameters (and defaults) to be given is specified in the TCS User Manual [RD 03].

3.9 Power-up/down

Power-up/down of the instrument will be made manually.

Power-up following a power failure may leave the instrument in a hazardous condition. Hardware interlocks will prevent aggravation of the condition e.g. by preventing start of closed cycle coolers if pressure is too high or movement of functions if temperature is too high [REQ45].

3.10 Science operations

[REQ46] The science operations of XXXX follow closely the VLT Science Operations Plan [AD 09].

A typical XXXX Observation Block (OB) consists of one or more exposures on the target and is accompanied by a set of calibration exposures which may be taken directly before or after the science exposure or during daytime. The execution of the OB could be carried out by a service observer or a visiting astronomer. The tools used by the service or classical observers to plan, execute and verify the observations will be the same. In both cases the observers will be assisted by an instrument operator.

The value of parameters the user is confronted with shall never be in engineering units, such as encoder values, but always in user units (e.g. filter name, wavelength in nm, width in arcsec, focus position in mm) [REQ47]

Parameter values shall be checked for validity. An error shall be returned whenever a parameter value is not valid (unknown name or numerical value outside valid range) [REQ48]

Parallel setup of devices is to be implemented as much as possible to increase the efficiency [REQ49].

Calibration lamps which require warm-up time should be switched on at the start of any set-up [REQ50].

The derotator requires continuous movement that is governed by object and telescope coordinates and time. This continuous movement has to be initiated for every exposure before the detector shutter is opened [REQ51].

3.11 Maintenance operations

Besides the scientific operation at the telescope, the control software needs to support the testing activities in Europe and in Chile, the commissioning phase and the maintenance of the instrument.

The value of parameters can be in user or engineering units, such as encoder values [REQ52].

All maintenance operations supported by Software shall be implemented as technical Templates [REQ53], as requested in [AD 02], and are listed in section 3.12.4.

3.12 Templates

If Templates are already covered by a separate Instrument Calibration Plan document, it is enough to refer to that document. If instead that document does not exist or is more oriented to scientific readers and does not clearly describe the set of Templates to be implemented, then this should be done here [REQ54]

3.12.1 Acquisition

1. Standard object acquisition

Parameters:

· Instrument mode

· Object Coordinates

· …..

Sequence:

a. Set instrument mode

b. Preset telescope

c. Wait of auto-guiding and active optics active

d. ……

3.12.2 Calibration

Standard calibration

Parameters:

· Instrument mode

· Lamp name

· Integration time

· …..

Sequence:

a. Set instrument mode

b. Switch lamp on

c. Wait for lamp to warm-up

d. Take a full frame exposure (integration time xx sec)

3.12.3 Science

Standard observation

Parameters:

· Instrument mode

· Integration time

· …..

Sequence:

a. Set instrument mode

b. Setup the instrument according to the given parameters value

c. Take a full frame exposure (integration time specified by the user)

3.12.4 Maintenance

Instrument focus. Measure the instrument focus.

Parameters:

· Steps size

· …..

Sequence:

a. Set instrument mode

b. Take 7 full frame exposures 1 sec each by moving device xyz stepwise by xx mm

Filter exchange. It helps maintenance staff to exchange a filter, log this operation and save the new Instrument Configuration.

Parameters:

· Old filter ID

· New filter ID

· …..

Sequence:

a. ……..

LN2 tank refilling. It helps maintenance staff to refill the LN2 tank and to verify the new tank level

Parameters:

· ……

Sequence:

a. ……..

Motor current. Run a motor at full speed, measure the current and record the data for trend analysis.

Parameters:

· Motor name

· Speed

· Sampling period

· …..

Sequence:

a. ……..

3.13 Documentation

The documentation to be produced for the Control Software is defined in [AD 02].

3.14 Performance

The execution of a bias full frame, from the start till when the complete FITS file is available on the IWS for being archived, shall not exceed xx sec [REQ55]

The initialization of the whole instrument shall not take longer than xx sec [REQ66]

The setup of the whole instrument before any exposure shall not take longer than xx sec [REQ67]

3.15 Test

The set of tests described in [RD 04] shall be implemented [REQ56]

Add here instrument specific tests.

3.16 Safety

3.16.1 Interlocks

Serious alarm conditions, which may leave the instrument in a hazardous condition, shall be avoided by appropriate hardware design, e.g. by mean of hardware interlocks. In such cases software alarms shall help to warn the user that the environmental conditions (e.g. temperature) are approaching the hardware limits [REQ57]

3.16.2 Warnings

Warnings shall be part of the operational logs [REQ58]

They shall be treated as low priority alarms, using the same display tool as for any other alarm [REQ59]

3.16.3 Alarms

Alarms shall be clearly shown to the user/operator by mean of standard tools common to all VLT applications [REQ60]

The Alarms display GUI shall be permanently running in the User Station (see 3.7.1) [REQ61]

The following alarms are foreseen for the XXXX Instrument [REQ62]:

Blue camera temperature too high
Red camera temperature too high
…..

All alarms shall be logged as operational logs [REQ63]

Optionally, sounds shall be associated to individual alarms [REQ64]

Monitoring of alarm conditions shall be active also when the instrument is in the STANDBY state (e.g. during daytime) [REQ65]

3.17 Summary of the requirements

Label	PAGE	DESCRIPTION
REQ01	11	List of devices
REQ02	11	Lamps in stand-by state
REQ03	11	Derotator modes
REQ04	11	Measures to overcome mechanical backlash
REQ05	11	Gratings setup parameters
REQ06	12	Sensors sampling period
REQ07	12	Blue detector size
REQ08	12	Red detector size
REQ09	12	Cryogenic devices kept to the necessary minimum
REQ10	12	List of observing modes
REQ11	12	Automatic settings in blue spectroscopy
REQ12	12	Automatic settings in red spectroscopy
REQ13	12	Automatic settings in dichroic spectroscopy
REQ14	12	Automatic settings in red imaging
REQ15	12	Description of state OFF
REQ16	12	Description of state LOADED
REQ17	12	Description of state STANDBY
REQ18	12	Description of state ONLINE
REQ19	13	Save and retrieve Instrument Configuration
REQ20	13	User acknowledgement before changing Instrument Configuration
REQ21	13	Protection of Instrument Configuration files
REQ22	13	Device hardware simulation
REQ23	13	Support full hardware simulation
REQ24	13	Data acquisition maximum speed
REQ25	13	Maximum sw overhead for data acquisition
REQ26	13	Display all images
REQ27	13	Maximum delay between acquisition and display
REQ28	13	Mouse driven operations on image display
REQ29	13	Image files in FITS format
REQ30	13	FITS header conform to ESO standards
REQ31	13	Sensors information in the FITS header
REQ32	13	Typical disk storage requirement for one night
REQ33	13	Maximum disk storage requirement for one night
REQ34	13	Archive all image FITS files
REQ35	13	Archive in background
REQ36	13	On-line data processing on the IWS
REQ37	13	Information to be logged
REQ38	14	Information displayed in the OS control GUI
REQ39	14	Information displayed in the OS status GUI
REQ40	14	User Station screen 1 contents
REQ41	14	User Station screen 2 contents
REQ42	14	P2PP on dedicated screen
REQ43	14	Off-line data reduction on dedicated WS and screen
REQ44	14	Functionality required from TCS
REQ45	15	Hardware interlocks
REQ46	15	Science operations according to the Science Operations Plan
REQ47	15	Parameters during science operations in high level units
REQ48	15	Check for parameters value validity
REQ49	15	Parallel setup of devices
REQ50	15	Lamps with warm-up time switched on at the first setup
REQ51	15	Continuous derotator motion during integrations
REQ52	15	Parameters during maintenance operations in high level or engineering units
REQ53	15	Maintenance operations supported by Templates
REQ54	15	List of Templates
REQ55	16	Maximum time for bias exposure
REQ56	17	List of scripts/procedures for the test Software
REQ57	17	Software alarms warn for approaching hardware interlock conditions
REQ58	17	Warnings shall be logged
REQ59	17	Warnings treated as low priority alarms
REQ60	17	Alarms displayed with standard tool
REQ61	17	Alarms GUI permanently displayed
REQ62	17	List of Alarms
REQ63	17	Alarms shall be logged
REQ64	17	Sounds associated to alarms
REQ65	17	Alarms monitoring also in STANDBY
REQ66	16	Initialization maximum time
REQ67	16	Setup maximum time