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 Functional Specification

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

Issue: 3

Date: 30/09/2005

Name Date Signature

Prepared: A.Longinotti 30/09/2005

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
1	30/04/2004	All	First issue
2	13/01/2005	4.13 5.14 6.17	ic0SelfTest replaced with inscSelfTest module xxd removed, as test sw moved (VLTSW20040158) test code moved from xxo (VLTSW20040158)
3	30/09/2005	10.2 10.3	Moved to Sw Management Plan template document (VLT-PLA-ESO-17240-3786)

TABLE OF CONTENTS

TABLE OF CONTENTS 3

1 INTRODUCTION 6

1.1 PURPOSE 6

1.2 Scope 6

1.3 Applicable Documents 6

1.4 Reference Documents 7

1.5 Abbreviations and Acronyms 7

1.6 Glossary 8

1.7 Stylistic Conventions 9

1.8 Naming Conventions 9

1.9 Problem Reporting/Change Request 9

1.10 Graphical notation 9

2 OVERVIEW 11

2.1 Instrument ID and prefix 11

2.2 Hardware architecture 11

2.2.1 Instrument LAN 11

2.3 Software architecture 12

2.3.1 INS environments 13

2.3.2 INS users 13

3 ANALYSIS 15

3.1 Use cases 15

3.1.1 Scientific Operations 15

3.1.2 Target Acquisition 15

3.1.3 Instrument Setup 16

3.1.4 Exposure execution 17

3.1.5 Filter substitution 18

4 INSTRUMENT CONTROL SOFTWARE (ICS) 19

4.1 Devices 19

4.1.1 Special devices 21

4.1.2 Cryogenics 21

4.1.3 Backlash compensation 21

4.1.4 Parallelism 21

4.2 Assemblies 21

4.3 States 21

4.4 Commands 21

4.5 Parameters 22

4.5.1 Setup 22

4.5.2 Status 22

4.6 Configuration 22

4.7 FITS header keywords 22

4.8 Stand-alone mode 22

4.9 Logging 23

4.10 Safety 23

4.10.1 Interlocks 23

4.10.2 Warnings 23

4.10.3 Alarms 23

4.11 Simulation 24

4.12 Performance 24

4.12.1 Initialization 24

4.12.2 Setup 24

4.13 Test Software 24

4.14 Standards 24

4.15 Modules 24

5 DETECTOR CONTROL SOFTWARE (DCS) 25

5.1 Data 25

5.1.1 Acquisition 25

5.1.2 Processing 25

5.1.3 Display 25

5.2 States 25

5.3 Commands 25

5.4 Parameters 25

5.4.1 Setup 25

5.4.2 Status 25

5.5 Configuration 26

5.6 FITS header keywords 26

5.7 Stand-alone mode 26

5.8 Logging 26

5.9 Failure Mode Operation 26

5.10 Simulation 26

5.11 Performance 26

5.11.1 Data rates 26

5.11.2 Real-Time Display 26

5.12 Test Software 26

5.13 Standards 27

5.14 Modules 27

6 OBSERVATION SOFTWARE (OS) 28

6.1 Modes 28

6.2 Exposure Types 28

6.3 Processes 28

6.3.1 OS Server 28

6.3.2 OS Archiver 28

6.3.3 OS Special processes 29

6.4 States 29

6.5 Commands 29

6.6 Parameters 29

6.6.1 Setup 29

6.6.2 Status 29

6.7 Configuration 29

6.8 FITS header keywords 29

6.9 Interface to TCS 29

6.10 User Interface 29

6.11 Logging 29

6.12 Archive 29

6.13 Templates 32

6.13.1 Instrument package 32

6.14 Performance 32

6.14.1 Exposure life cycle 33

6.15 Test Software 33

6.16 Standards 33

6.17 Modules 33

7 MAINTENANCE SOFTWARE (MS) 34

7.1 Configuration 34

7.2 Templates 34

7.2.1 Instrument technical package 35

7.3 Performance 35

7.3.1 Data processing 35

7.4 Test Software 35

7.5 Standards 35

7.6 Modules 35

8 OBSERVER SUPPORT SOFTWARE (OSS) 36

8.1 Standards 36

8.2 Modules 36

9 SYSTEM ATTRIBUTES 37

9.1 Installation 37

9.2 Startup/Shutdown 37

9.3 User Station 37

9.4 Security 37

9.5 Availability 37

9.6 Maintainability 37

9.7 Documentation 38

9.8 Adaptability and enhancement potential 38

9.9 Training 38

10 DEVELOPMENT AND TEST FACTORS 39

10.1 Project Control 39

10.2 Test 39

11 Traceability matrix 40

1 INTRODUCTION

This document aims to provide Instrument Software Engineers with a template of the Instrument Software Functional Specification (ISFS) document. Instrument specific ISFS 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 existing ISFS.

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 Functional Specifications of the XXXX Control Software. They are the result of the analysis study of the requirements, described in [AD 11], and [AD 02].

This document logically follows the Instrument Software User Requirements Specification (ISURS, see [AD 11]) and shall be applicable to all the following Software documents, in particular the Instrument Software Design Description (ISDD), which logically directly follows it

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

This document shall be reviewed at the Preliminary Design Review (PDR). It shall be part of the PDR data package. In case of exceptional changes to the requirements after PDR, once the change request has been approved by ESO, the ISURS and this document shall be updated accordingly.

1.2 Scope

This document defines the Functional Specifications of the XXXX Control Software only. Functional Specifications of other parts of the VLT data flow, such as the pipeline, 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	5	30/09/2005	Instrumentation Software Specification
[AD 03]	VLT-SPE-ESO-17240-0385	4	13/01/2005	INS Common Software Specification
[AD 04]	VLT-SPE-ESO-10000-2723	1	18/03/2005	VLT Requirements for Scientific Instruments
[AD 05]	VLT-PRO-ESO-10000-0228	1	10/03/1993	VLT Software Programming Standards
[AD 06]	VLT-SPE-ESO-xxxxx-xxxx	1	xx/xx/xxxx	XXXX Control Electronics Specification
[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	3	01/02/2005	Data Interface Control Document
[AD 11]	VLT-SPE-ESO-xxxx-xxxx	1	xx/xx/xxxx	XXXX Control Software User Requirements

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	4	29/04/2004	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	5	13/01/2005	INS Acceptance Test Plan Template Document
[RD 05]	VLT-MAN-ESO-17200-0981	2	16/10/1998	VLT Problem Report Change Request User Man.
[RD 06]	G. Booch, I. Jacobson, J. Rumbaugh		10/1998	The Unified Modelling Language User Guide
[RD 07]	VLT-MAN-ESO-17240-0934	5	31/03/2004	INS Common sw - Base ICS User Manual
[RD 08]	VLT-MAN-ESO-17240-2240	4	31/03/2004	INS Common sw for Templates User Manual
[RD 09]	VLT-MAN-ESO-13640-1388	3	31/03/2004	FIERA Control Software User Manual
[RD 10]	VLT-MAN-ESO-17240-2265	4	05/04/2004	INS Common sw - Base OS Stub User Manual
[RD 11]	VLT-MAN-ESO-17220-1332	4	19/04/2004	HOS/Broker for Observation Blocks User Manual
[RD 12]	VLT-MAN-ESO-17240-1973	5	13/01/2005	Template Instrument User and Maint.Manual
[RD 13]	VLT-PLA-ESO-xxxx-xxxx	1	xx/xx/xxxx	XXXX Software Management Plan
[RD 14]	VLT-MAN-ESO-17210-0619	2.4	31/03/2004	Central Control Software User Manual
[RD 15]	VLT-MAN-ESO-14100-1878	1.4	01/12/2003	IRACE-DCS User Manual

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
IR	Infra-Red
ISDD	Instrument Software Design Description
ISFS	Instrument Software Functional Specification
ISURS	Instrument Software User Requirements Specification
ISUMM	Instrument Software User and 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)
UV	Ultra-Violet
VCSOLAC	VLT Control Software On-Line Archive Client
VLT	Very Large Telescope
VME	Versa Module Eurocard
VOLAC	VLT On-Line Archive Client
WS	Workstation

<!-- Standard footer -->

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 in [AD 11]:

Ø User

The following is defined in [RD 07]:

Ø Assembly

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.

1.10 Graphical notation

The following graphical notation is used in Chapter 3 (see [RD 06]):

Asynchronous message	A form of communication in which a producer task sends a message to a consumer task and does not wait for a response; a message queue could potentially build up between the tasks. Also referred to as “loosely coupled message communication”.
Dependency	Show which component and/or package communicates and/or depends with/on another one.
Package	A group of modelling elements.
Component	An active self-contained object with a well-defined interface.
Interface	The external specification of a class, task or component.
Actor	Shows an outside user or related set of users who interact with the system.
Node	In a distributed environment, each node consist of one or more processors with shared memory.
Object	An instance of a class that contains both hidden data and operations on that data.
Use Case Realization	A use case realization is a graphic sequence of events, also referred to as a scenario or an instance of a use case. These realizations or scenarios are depicted in either a sequence or collaboration diagram.

2 OVERVIEW

This document tries to associate, whenever possible, every functional aspect to one of the standard instrumentation modules (ICS, DCS, OS, OSS, MS). This approach is a consequence of the fact that in most of the instrumentation projects the software part is developed at several sites, and the repartition of responsibility among partners is based on the instrumentation modules (e.g. partner A is responsible for ICS, B for DCS, C for OS, OSS and MS). The risk of such approach however is that system and integration aspects do not get the necessary attention. For this reason, one separate chapter is dedicated to system aspects and one to the overall project organization aspects.

The present chapter aims to give an overview of the instrument hardware and software architecture.

Chapter 3 presents the results of the analysis of requirements in form of use cases presentation.

Chapter 4 describes the functionality of the ICS module

Chapter 5 describes the functionality of the DCS module

Chapter 6 describes the functionality of the OS module

Chapter 7 describes the functionality of the MS module

Chapter 8 describes the functionality of the OSS module

Chapter 9 describes the functionality related to the whole instrument

Chapter 10 describes aspects about the project organization

2.1 Instrument ID and prefix

The instrument ID will be XXXX. The instrument prefix will be xx. [ISFS01]

2.2 Hardware architecture

Figure 1 gives an overview of the instrument hardware architecture.

Following the VLT standard system architecture, the instrument hardware will be located in the Telescope Area.

As from [AD 06], the instrument devices will be controlled from two LCUs.

The two scientific detectors are controlled by two dedicated Detector LCUs (Ultra-Sparc Workstations).

Control and data information is transferred over the Instrument LAN between the Instrument Workstation and the Instrument and Detectors LCUs.

The Instrument Workstation (IWS) is located in the Computer Room in the Control Building. The typical amount of data produced and stored on disk during an observing night is xx GB and the maximum amount is xx GB. Considering that the two scientific detectors may produce data in parallel, in order to optimize disk write operations, the IWS will be equipped with two hard disks of xx GB each and minimum speed of xx MB/sec [ISFS58].

Only the LCU controlling the image derotator device will be equipped with a TIM board and connected to the Time Reference System. The other LCUs have no time critical synchronization requirements and will therefore not be equipped with a TIM board [ISFS02].

The two screens of the User Station console will be used: one for control and status display and the other one for real-time image display (see 9.3).

2.2.1 Instrument LAN

The Instrument LCUs have a normal Ethernet connection to the Instrument LAN.

The two scientific detectors LCUs, as well as the Instrument WS, have a large bandwidth ATM connection to the Instrument LAN.

The name of the nodes will be [ISFS03]:

• wxxxx for the Instrument Workstation
• lxxics1 for the first instrument LCU
• lxxics2 for the second instrument LCU
• wxxdir for the infra-red science detector LCU
• wxxduv for the ultra-violet science detector LCU

Figure 1 Hardware architecture

2.3 Software architecture

Figure 2 shows the architecture of the instrument software and the data flow between its components [ISFS80].

The instrumentation software is subdivided in the standard INS modules (see [AD 02]) ICS, DCS, OS, MS, OSS [ISFS04].

Observation Blocks (OBs) are normally prepared by the observing team at the home institute well before the observing night, using the Phase 2 Proposal Preparation (P2PP) Tool.

During the observing run, the next OB to be executed is loaded again in the P2PP Tool on the Observation Handling WS. It is then sent to the Broker for Observation Blocks (BOB) Tool on the Instrument WS.

BOB reads the contents of the OB and executes one by one the templates specified in there. Each template consists in general of a sequence of commands to be sent to the Observation Software (OS) Server. OS Server translates the incoming commands into further commands to be sent to the Detector Control Software (DCS), Instrument Control Software (ICS) and Telescope Control Software (TCS). DCS, ICS and TCS then take care of instructing the respective LCUs of all actions they should take with the connected hardware.

The typical simple sequence of commands sent to OS by science observation templates to execute an exposure is:

• SETUP (one or more)
• START (exposure)
• WAIT (till exposure finished)

As a result of an exposure, the related DCS generates detector data and saves them in a FITS file. The OS process responsible for archiving data takes care of merging into that file the information, coming from the other sub-systems (TCS and ICS), related to the same exposure. It then informs the standard VLT On-Line Archive (VOLAC) process that a new file is ready to be archived. In turn, VOLAC passes this information to the standard VCSOLAC process, which finally transfers the file to the On-Line Archive Subsystem (OLAS) on the On-Line Archive WS.

2.3.1 INS environments

The environments used by the instrumentation software are [ISFS06]:

• wxxxx on the Instrument Workstation. Type CCS-lite
• lxxics1 on the first instrument LCU
• lxxics2 on the second instrument LCU
• wxxduv on the UV science detector LCU. Type CCS-lite

The IR science detector LCU Software runs under no-CCS and therefore does not need any CCS environment.

2.3.2 INS users

Two UNIX users will be dedicated to this instrument [ISFS07]:

• xxxxmgr, responsible for building and installing the Software
• xxxx, responsible for starting/stopping and running the INS environments and the INS Software

Figure 2 Software architecture

3 ANALYSIS

3.1 Use cases

This section is optional. If use cases are included (recommended, limited to the most important or peculiar/complex ones), they should follow the UML notation.

The following are just examples of use cases in the UML notation. They are copied from the OmegaCAM functional specs and therefore reflect the peculiarities of that instrument. They are not supposed to be considered valid for all instruments and therefore should NOT be copied without any adaptation to the actual instrument.

3.1.1 Scientific Operations

Describe here the contents of Figure 3

Figure 3 Scientific Operations Use Case

3.1.2 Target Acquisition

Figure 4 shows the sequence diagram for target acquisition. During target acquisition the telescope is preset to the target and the auto-guiding subsystem is prepared to perform auto-guiding during subsequent exposures. In parallel with the telescope preset, the auto-guiding software queries the guide star catalogue for candidate guide stars. After the telescope has preset, guide stars are selected, possibly with operator intervention.

Figure 4 Acquire Target Use Case sequence diagram

3.1.3 Instrument Setup

Figure 5 shows the sequence diagram for instrument setup. Instrument setup is performed to prepare the instrument for an exposure. The most important operation is the filter exchange. A filter dependent focus offset (if any) is applied by asking the Telescope Control System to move M2. In case the setup is for a calibration observation of type dome flat, than lamps are switched on (not shown in the figure).

Figure 5 Setup Instrument Use Case sequence diagram

3.1.4 Exposure execution

Figure 6 shows the sequence diagram for the execution of an exposure. Before starting single exposures with the science detector, OS checks that the telescope can track on target for the required exposure time. Then ICS and telescope are instructed that an exposure is going to start so that they can collect FITS header information. DCS are then started: a command is sent to DCS-2 (slave) that instructs it to start when it will receive a synchronization signal from DCS-1. When DCS-2 is ready to get this signal a START command is sent to DCS-1, this effectively starts the exposure on both DCSes. At exposure end header data information is collected from ICS and TCS, and a merged data file is produced and sent to archive.

Figure 6 Perform Exposure Use Case sequence diagram

3.1.5 Filter substitution

Figure 7 shows the sequence diagram for the filter substitution. Filter substitution is a maintenance operation performed by means of a template. It begins with insertion in the optical path of a filter from the magazine other then the one being serviced (typically opaque or key filter). A SETUP command with filter ID (or name) and position is issued for each filter to be inserted. The command is forwarded by OS to ICS, that moves the magazine in order to put the filter in the requested position to the loading plane, undocked. When the ICS status becomes "waiting for filter ID", the operator removes the existing filter, inserts the new one. ICS reads the filter ID, validates it, updates the position/filter ID in the database and returns successfully.

Figure 7 Substitute Filters Use Case sequence diagram

4 INSTRUMENT CONTROL SOFTWARE (ICS)

One single ICS controls all devices, except the detectors [ISFS16].

It consists of one part, which runs on LCU(s) and one part, which runs on the IWS.

The LCU part is responsible for the interface to the devices hardware and the low-level control. No real-time functionality is required.

The WS part is responsible for the coordination between LCUs and for the API to OS.

Both WS and LCU part will be based on the VLT standard icb package [ISFS30].

4.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 ICS 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
		17

Table 2 ICS Devices [ISFS17]

#	Device	NAME	TYPE	FITS KEYS	VALUES	LCU	REMARKS
1	Calibration mirror slide	CALS	LIN icbMOT_MIRROR	INS.MIRR1.NAME	TELESCOPE SPHERE THAR1 THAR2	1	Slide with 4 positions
2	ThAr lamp 1	TAL1	LAM icbLAMP	INS.LAMP1.ST	T/F	1	T=On F=Off Special power level in standby state [ISFS24]
3	ThAr lamp 2	TAL2	LAM icbLAMP	INS.LAMP2.ST	T/F	1	T=On F=Off Special power level in standby state [ISFS24]
4	ThAr shutter	TSH	SHU icbSHUTTER	INS.SHUT1.ST	T/F	1	T=Open F=Close
5	FF lamp 1	FFL1	LAM icbLAMP	INS.LAMP3.ST	T/F	1	T=On F=Off On sphere
6	FF lamp 2	FFL2	LAM icbLAMP	INS.LAMP4.ST	T/F	1	T=On F=Off On sphere
7	Image derotator	DROT	ROT icbMOT_DROT	INS.DROT.MODE INS.DROT.POSANG INS.DROT.RA INS.DROT.DEC	SKY ELEV STAT [0.0 – 360.0]	1	It has three modes [ISFS23]: 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
8	Preslit filter wheel	PFIL	ROT icbMOT_FILTER	INS.FILT1.NAME	B U … FREE	1	Wheel with 16 positions
9	Mode selector	MODE	LIN icbMOT_MIRROR	INS.MIRR2.NAME	IR UV DICHROIC	1	Slide with 3 positions
10	UV slit	UVSS	EXC icbMOT_SLIT2_WID	INS.SLIT1.WID	[0.01 – 10.00]	2	Width in arcsec. Backlash
11	UV filter wheel	UVFIL	ROT icbMOT_FILTER	INS.FILT2.NAME	B U … FREE	2	Wheel with 24 positions
12	UV cross disperser	UVCD	ROT icbMOT_GRATING2	INS.GRAT1.NAME INS.GRAT1.WLEN	GRAT1 GRAT2 [9000 –11000] [8000 –10000]	2	User specifies grating and order number [ISFS26]. Two gratings back to back.
13	IR slit	IRSS	EXC icbMOT_SLIT2_WID	INS.SLIT2.WID	[0.01 – 10.00]	2	Width in arcsec. Backlash
14	IR filter wheel	IRFIL	ROT icbMOT_FILTER	INS.FILT3.NAME	B U … FREE	2	Wheel with 24 positions
15	IR cross disperser	IRCD	ROT icbMOT_GRATING2	INS.GRAT2.NAME INS.GRAT2.WLEN	GRAT3 GRAT4 FREE [12000-15000] [11000-14000]	2	User specifies grating and order number [ISFS26]. Two gratings back to back.
16	UV camera temperature monitoring	TUVC	SEN (CRY) xxiLAKE (special)	INS.TEMP1.VAL		2	Value in deg C Sampling period 60 sec [ISFS27]
17	IR camera temperature monitoring	TIRC	SEN (CRY) xxiLAKE (special)	INS.TEMP2.VAL		2	Value in deg C Sampling period 60 sec [ISFS27]

4.1.1 Special devices

For every special device, a justification why none of the icb standard devices can be used must be given.

The only special devices are the two camera temperature monitoring sensors (TUVC and TIRC). None of the temperature sensor standard devices supported by icb fulfills the requirements in terms of accuracy and operability in a cryogenic environment. For these reasons, a Lakeshore xyz device, not supported by icb, has been chosen [ISFS29].

4.1.2 Cryogenics

For every device in a cryogenic environment, a justification why it cannot be located outside shall be given (if already done in another document, it is enough to refer to it).

The only devices in a cryogenic environment (CRY) are the two camera temperature monitoring sensors (TUVC and TIRC). They cannot be located outside the cryogenic environments because they must be closely connected to the science camera [ISFS28]

4.1.3 Backlash compensation

Due to mechanical backlash, the target position for the two slit devices (UVSS and IRSS) shall always be approached in the direction of increasing encoder steps. This will be achieved by using the two-steps motion feature provided by the standard VLT motor library [ISFS25]. The size of last step will be 100 encoder steps.

4.1.4 Parallelism

Actions on all devices (initialization, setup) will be done in parallel, as they are fully independent from each other [ISFS61]. This functionality is embedded in the icb architecture.

4.2 Assemblies

All calibration lamps are mutually exclusive, i.e. it does not make sense to have more than one turned on at one time.

In order to make the ICS API easier to higher level Software (OS), an assembly (see [RD 07]) will be implemented:

• INS.LAMP [ISFS45]. Possible values:
• OFF. All lamps are off. Shutter TSH is closed
• TAL1. Only Thar 1 is on. . Shutter TSH is open
• TAL2. Only Thar 2 is on. Shutter TSH is open
• FFL1. Only flat-field 1 is on. Shutter TSH is closed
• FFL2. Only flat-field 2 is on. Shutter TSH is closed

4.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 Software relies on it.

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

1. OFF [ISFS31]: part of the Software is not running and part of the LCUs and devices can be powered off.
2. LOADED [ISFS32]: the whole hardware is powered on, the whole Software is running, but the interfaces to the hardware are not initialized.
3. STANDBY [ISFS33]: the interfaces are initialized, but the hardware may not.
1. Sphere lamps are off. ThAr lamps are in a special standby power status.
2. Shutters are closed
3. Encoders are on
4. Motors current is off.
5. Sensors monitoring is active.
4. ONLINE [ISFS34]: all software and hardware is loaded, initialized and active. This is the normal state during operations.

4.4 Commands

Being ICS based on the icb package, the commands are those defined in the CDT table for the process ic0Control [ISFS35].

4.5 Parameters

4.5.1 Setup

All Setup keywords will be registered in the dictionary XXXX_ICS.

The following functionality is embedded in icb, and will be also implemented in the instrument specific code (e.g. special device LCU code), whenever applicable:

• The syntax of Setup keywords shall be checked for validity [ISFS41]
• The value of Setup keywords shall be checked for validity before taking any action [ISFS40]
• The value of Setup parameters shall be stored in the LCU and/or WS on-line database in dedicated attributes, different from the attribute containing the corresponding status parameter [ISFS66].
• The value of Setup parameters in the on-line database shall not be changed until a new SETUP command is executed [ISFS38].

4.5.2 Status

All Status keywords will be registered in the dictionary XXXX_ICS

The following functionality is embedded in icb, and will be also implemented in the instrument specific code (e.g. special device LCU code), whenever applicable:

• The syntax of Status keywords shall be checked for validity against the dictionary and against the rules defined in [AD 10] [ISFS41]
• Status parameters shall be stored in the LCU and/or WS on-line database in dedicated attributes, different from the attribute containing the corresponding setup parameter [ISFS66].
• The status of any on-going action, as well as its completion status, shall be available in the on-line database [ISFS39].
• The copying of status parameters from the LCU to the WS on-line database will use the CCS scan system. Attributes will generally be updated on change. Polling mode will not be used. [ISFS42]

4.6 Configuration

All Configuration keywords, if not already registered in ICB_CFG, will be registered in the dictionary XXXX_CFG.

Configuration parameters will be stored in dedicated files, belonging to module xxmcfg (see 7.1) [ISFS37].

The following functionality is embedded in icb, and will be also implemented in the instrument specific code, whenever applicable:

• The syntax of Configuration keywords shall be checked for validity against the dictionaries [ISFS41]
• The standard tool ctoo is used to access these parameters from the ICS WS part and to make them available in the LCU OLDB after booting [ISFS64].

4.7 FITS header keywords

The following functionality is embedded in icb:

• The ICS part of the FITS header can be obtained by issuing the standard command

STATUS –header [-dumpFits <filename>]

• It shall contain the actual status of the instrument and all related devices (also in simulation). It shall also contain: [ISFS50]

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

4.8 Stand-alone mode

ICS shall provide an engineering GUI, based on the VLT standard package icbpan [ISFS48].

Figure 8 shows a mockup of such GUI (example taken from Omegacam)

Figure 8 Mockup of ICS stand-alone engineering GUI

4.9 Logging

In addition to the standard logging embedded in the icb module, the code for the special devices shall provide the following logs [ISFS49]:

1. Errors during the execution of any command, according to the CCS error system rules.
2. Temperature values, when they change by 0.1 Celsius degrees when the instrument is in operation or stand-by mode.

4.10 Safety

4.10.1 Interlocks

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 movement of functions if temperature is too high. [ISFS78].

Software alarms will be implemented to warn the user that the environmental conditions (e.g. temperature) are approaching the hardware limits (see 4.10.3)

4.10.2 Warnings

They shall be treated as low priority alarms. See 4.10.3.

4.10.3 Alarms

The following alarms are foreseen [ISFS36]:

1. UV camera temperature too high
2. IR camera temperature too high

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

All alarms will be logged as operational logs [ISFS53]

4.11 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. Furthermore, it shall be possible for test and maintenance purposes to run ICS also where the LCUs are not available.

Two levels of simulation are implemented in icb:

1. Simulation for the entire instrument LCU at workstation level.
2. Simulation for device hardware at LCU level.

The same levels of simulation will be implemented also in the code for the special devices, thus giving the possibility to run and test templates and OBs also at locations where the hardware or the LCUs are not available [ISFS46].

The ICS GUI and the ICS part of the FITS header shall clearly indicate which device is in hw simulation [ISFS47].

4.12 Performance

All critical performance requirements must be analyzed here. In particular, it shall be investigated if the usage of standards fulfills all performance requirements or special solutions must be considered instead. Information about performance aspects related to the usage of the VLT common software is available in the VLT software documentation (User Manuals) or may be provided by ESO software staff. Whenever uncertainties are present, dedicated prototyping is mandatory and the results must be presented here, together with the conclusions and the proposed solutions.

The following sub-sections are just examples of typical fields where performance requirements are specified. They should not be considered exhaustive for all instruments nor are all of them necessarily applicable to all instruments.

4.12.1 Initialization

It is required that the initialization of the whole instrument does not exceed xx sec. Because all devices will be initialized in parallel (see 4.1.4), the overall initialization time for the whole instrument shall correspond to that device, which takes longer. The devices which require higher accuracy and will take longer time to initialize are the cross-dispersers. It is expected that their initialization will be within the required maximum time. However, a final test will be possible only once a prototype of the device will be available [ISFS14].

4.12.2 Setup

It is required that the setup of the whole instrument does not exceed xx sec. Because all devices will be moved in parallel (see 4.1.4), the overall setup time for the whole instrument shall correspond to that device, which takes longer. The devices which require higher accuracy and will take longer time to move are the cross-dispersers. It is expected that their maximum setup time will be within the required limit. However, a final test will be possible only once a prototype of the device will be available [ISFS15].

4.13 Test Software

The ICS Test Software shall consist of [ISFS44]:

1. Low-level LCU test procedure for the Lakeshore special device (see [RD 04])
2. High-level WS test procedure for the Lakeshore special device (see [RD 04])
3. Self-test procedure, based on inscSelfTest (see [RD 04])

4.14 Standards

ICS will be based on icb and icbpan.

4.15 Modules

The cmm modules belonging to ICS are [ISFS43]:

• xxi. It is the main module and includes the ICS WS front-end and LCU simulator.
• xxipan. It includes the ICS stand-alone GUI
• xxilak. It includes the code for the Lakeshore special device

5 DETECTOR CONTROL SOFTWARE (DCS)

The instrument is equipped with two science detector cameras [ISFS18].

Two DCSs will be in place, each controlling one of the two science cameras [ISFS19].

The DCS for the UV camera will be an instance of the standard FIERA package [ISFS20].

The UV CCD detector size will be 2028 x 2048 pixels, upgradeable to 4096 x 4096 [ISFS21].

The DCS for the IR camera will be an instance of the standard IRACE package [ISFS107].

The IR detector size will be 1024 x 1024 pixels [ISFS22].

5.1 Data

5.1.1 Acquisition

The following read-out modes are foreseen [ISFS76]:

• UV CCD:

1. two outputs, 125 kHz clock rate, no binning, max. one window

2. one output, 250 kHz clock rate, binning 2x2, no window

3. ……

• IR detector:

1. one output, 500 kHz clock rate, max. one window

2. …..

Considering the chip size, the fastest acquisition will therefore be xx sec for the UV camera and yy sec for the IR camera.

The files, defining the clock patterns for each read-out mode, will be stored in dedicated cmm modules (see 5.14).

5.1.2 Processing

No real-time or in general “fast” data processing (such that it must be performed on the DCS LCU) is requested.

5.1.3 Display

Standard applications will be used for image display: rtd for the UV camera and irtd for the IR camera. They implement all features required [ISFS65].

5.2 States

The DCS states are those defined by the FIERA package (see [RD 09]) for the UV camera and by the IRACE package (see [RD 15]) for the IR camera. [ISFS20]

5.3 Commands

The DCS commands are those defined in the FIERA fcdconCI.cdt CDT file (see [RD 09]) for the UV camera and IRACE iracqServer.cdt CDT file (see [RD 15]) for the IR camera. [ISFS20]

5.4 Parameters

5.4.1 Setup

The DCS setup keywords are those defined in the dictionary FCDDCS (see [RD 09]) for the UV camera and in the dictionary IRACE (see [RD 15]) for the IR camera. [ISFS20]

5.4.2 Status

The DCS status keywords are those defined in the dictionary FCDDCS (see [RD 09]) for the UV camera and in the dictionary IRACE (see [RD 15]) for the IR camera. [ISFS20]

The copying of status parameters from the UV camera LCU to the WS on-line database will use the CCS scan system, configured through the FIERA scripts fcdDcsScan.sh and fcdosScan.sh [ISFS20]

Being the IR camera software based on IRACE, its LCU part runs under no-CCS (no CCS environment, no CCS on-line database).

5.5 Configuration

The DCS configuration for each camera is stored in dedicated cmm modules (see 5.14) and consists of:

• One file containing configuration parameter values
• Clock pattern files and directories

The DCS configuration for the UV camera is installed using the standard FIERA script fcdInstall.sh.

The DCS configuration for the IR camera is installed using the standard IRACE script iracqInstallData.

5.6 FITS header keywords

The DCS keywords for the FITS header are those defined in the dictionary FCDDCS (see [RD 09]) for the UV camera and in the dictionary IRACE (see [RD 15]) for the IR camera. [ISFS20]

5.7 Stand-alone mode

The DCS stand-alone engineering GUI will be that provided by the FIERA package (see [RD 09]) for the UV camera and by the IRACE package (see [RD 15]) for the IR camera. [ISFS20]

5.8 Logging

The DCS logs are those produced by FIERA package (see [RD 09]) for the UV camera and by the IRACE package (see [RD 15]) for the IR camera. [ISFS20]

5.9 Failure Mode Operation

The Failure Mode Operations supported by FIERA are described in [RD 09], those supported by IRACE are described in [RD 15]. [ISFS20]

5.10 Simulation

The DCS simulation levels are those defined by FIERA (see [RD 09]) for the UV camera and by IRACE (see [RD 15]) for the IR camera. [ISFS20]

5.11 Performance

All critical performance requirements must be analyzed here. In particular, it shall be investigated if the usage of standards fulfills all performance requirements or special solutions must be considered instead. Information about performance aspects related to the usage of the VLT common software is available in the VLT software documentation (User Manuals) or may be provided by ESO software staff. Whenever uncertainties are present, dedicated prototyping is mandatory and the results must be presented here, together with the conclusions and the proposed solutions.

The following sub-sections are just examples of typical fields where performance requirements are specified. They should not be considered exhaustive for all instruments nor are all of them necessarily applicable to all instruments.

5.11.1 Data rates

It is required that the fastest acquisition for a 4096x4096 detector does not exceed xx sec with a maximum overhead for the image transfer to the IWS of xx sec. This corresponds to yy Mbit/sec data rate. Such a rate can be sustained by the standard ATM network connection between detector LCU and Instrument Workstation and by the hard disk model and related interface mounted on VLT standard IWS [ISFS12].

5.11.2 Real-Time Display

It is required that the maximum delay between end of image acquisition and end of image display does not exceed xx sec

Using the Template Instrument as test bench and the VLT standard real-time display tool, we have determined a maximum delay over 20 acquisitions of yy sec. This shows that the VLT standard packages (FIERA and IRACE for DCS and rtd for the Real Time Display) are good enough for our requirements [ISFS13].

5.12 Test Software

The DCS Test Software shall consist of [ISFS84]:

1. Self-test procedure for the UV camera, consisting of taking one exposure for each read-out mode (see [RD 04])
2. Self-test procedure for the IR camera, consisting of taking one exposure for each read-out mode (see [RD 04])

5.13 Standards

DCS for the UV camera is based on the FIERA package [ISFS20]

DCS for the IR camera is based on the IRACE package [ISFS107].

Image display is based on the rtd package [ISFS65]

5.14 Modules

The cmm modules belonging to DCS are [ISFS81]:

1. xxdir. It includes the configuration files for the IR camera.
2. fcdXXXXUV. It includes the configuration files for the UV camera. It is delivered by ESO.

6 OBSERVATION SOFTWARE (OS)

The Observation Software (OS) is the highest layer of the control Software and will run in the Instrument Workstation (see Figure 2). It consists of:

• OS Server process, responsible for the execution of single exposures.
• OS Archiver process, responsible for archiving the results of exposures in FITS files.
• If applicable, any process dedicated to special features, such as secondary guiding
• If applicable, Supervisory OS
• Templates, defining and running sequence of exposures

The OS processes (Server and Archiver) will be based on the standard package boss [ISFS75].

Templates will be based on the standard package tpl [ISFS71].

6.1 Modes

The following instrument modes (keyword INS.MODE) are foreseen [ISFS74]:

1. UVSPEC (UV spectroscopy)

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

INS.MIRR2.NAME UV

2. IRSPEC (IR spectroscopy)

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

INS.MIRR2.NAME IR

3. DSPEC (Dichroic spectroscopy)

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

INS.MIRR2.NAME DICHROIC

4. IRIMG (IR Imaging)

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

INS.MIRR2.NAME IR INS.GRAT2.NAME FREE

6.2 Exposure Types

The following sub-set of the standard exposure types (keyword DPR TYPE), defined in [AD 10], will be used [ISFS85]:

• OBJECT
• SKY
• STD
• FLUX
• SPECTEMPL
• BIAS
• DARK
• FLAT
• LAMP
• WAVE
• FMTCHK
• ORDERDEF

6.3 Processes

In case of one SOS coordinating several OSs, there must be separate sessions describing the processes for each OS, and one section for the SOS process.

6.3.1 OS Server

Describe here what you intend to implement, in addition to what already provided by boss, and explain why.

6.3.2 OS Archiver

Describe here what you intend to implement, in addition to what already provided by boss, and explain why.

6.3.3 OS Special processes

Describe here the processes you intend to implement in addition to the Server and Archiver. Justify why the functionality has to be implemented in separate processes and describe the interface to the Server and other sub-systems.

6.4 States

The instrument states are the standard ones specified in [AD 03] and [RD 10], and described in section 4.3 [ISFS75].

6.5 Commands

The OS commands are those defined in the boss CDT file osbControl.cdt (see [RD 10]). [ISFS75]

6.6 Parameters

6.6.1 Setup

The OS setup keywords are those defined in the dictionary XXXX_OS [ISFS82]

6.6.2 Status

The OS status keywords are those defined in the dictionary XXXX_OS [ISFS82]

6.7 Configuration

All Configuration keywords are registered in the dictionary OSB.

Configuration parameters will be stored in dedicated files, belonging to module xxmcfg (see 7.1) [ISFS83].

The following functionality is embedded in boss, and will be also implemented in the OS specific code, whenever applicable:

• The syntax of Configuration keywords will be checked for validity against the dictionary [ISFS75]

6.8 FITS header keywords

The OCS keywords for the FITS header are those defined in the dictionary XXXX_OS [ISFS82]

6.9 Interface to TCS

The following TCS standard functionality (see [RD 03]) will be used:

• Preset
• Offset
• Auto-guiding
• Adapter and rotator angle

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

The whole functionality will be accessed from templates, in particular using methods of the standard tpl class tplTCS (see [RD 08]). [ISFS86]

6.10 User Interface

The OS panels will be:

• OS Control GUI. A mockup is shown in Figure 9 (example taken from FLAMES)[ISFS87]
• OS Status GUI. A mockup is shown in Figure 10 (example taken from GIRAFFE)[ISFS88]
• If applicable, panels dedicated to special functionality, e.g. slit viewer control.

6.11 Logging

The OS logs are those produced by the boss package (see [RD 10]) [ISFS75]

6.12 Archive

Calibration and Observation data shall be stored in FITS files, according to the rules and guidelines defined in [AD 10].

The following functionality is embedded in boss and tpl, and will be also implemented in the OS specific code, whenever applicable:

• FITS files will follow the naming conventions described in [RD 08]. [ISFS59].
• The OS Server process shall inform the OS Archiver process that it can start the archiving operations as soon as it has completed collecting information for the FITS header from the various sub-systems (ICS, TCS) after DCS has declared the exposure complete from its side. This way archiving and preparation of the next exposure can run in parallel [ISFS60].

Figure 9 Mockup of OS Control GUI

Figure 10 Mockup of OS Status GUI

6.13 Templates

The implementation of templates will be based on the rules defined in [RD 08] and on the standard tool tpl [ISFS71].

The parameter values used within OS templates will always be in user units and never in engineering units (e.g. encoder units) [ISFS89]

The following templates are foreseen [ISFS72]:

· Acquisition

1. XXXX_UVSPEC_acq. UV Spectroscopy 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. ……

2. ….

· Calibration

1. XXXX_UVSPEC_cal_std. UV Spectroscopy standard calibration. The first operation will be a SETUP command to turn on the calibration lamp selected (to optimize exposure cycle due to lamp warm-up time) [ISFS69]

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)

2. ….

· Science

1. XXXX_UVSPEC_obs_std. UV Spectroscopy standard observation. Before starting the exposure, the derotator continuous motion must be started, with SETUP –function INS.DROT.MODE SKY [ISFS70]

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)

2. ….

The setup reference files, used by all templates generating images, will always contain the keywords

DET.DISPLAY 0

DET.FRAM.FITSMTD 2

They specify that images must be displayed and saved in a FITS file [ISFS67].

6.13.1 Instrument package

OS shall provide to P2PP, as part of the xxotsf module, the Instrument Package XXXX.zip, consisting of all the OS templates and the Instrument Summary File XXXX.isf.

6.14 Performance

All critical performance requirements must be analyzed here. In particular, it shall be investigated if the usage of standards fulfills all performance requirements or special solutions must be considered instead. Information about performance aspects related to the usage of the VLT common software is available in the VLT software documentation (User Manuals) or may be provided by ESO software staff. Whenever uncertainties are present, dedicated prototyping is mandatory and the results must be presented here, together with the conclusions and the proposed solutions.

The following sub-sections are just examples of typical fields where performance requirements are specified. They should not be considered exhaustive for all instruments nor are all of them necessarily applicable to all instruments.

6.14.1 Exposure life cycle

It is required that 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 (see [AD 11]).

Using the Template Instrument as test bench, we have determined a maximum execution time over 20 exposures with the FIERA DCS of yy sec and with the IRACE DCS of zz sec. This shows that the VLT standard packages (FIERA and IRACE for DCS and boss for OS) are good enough for our requirements [ISFS11].

6.15 Test Software

The OS Test Software shall consist of [ISFS92]:

1. OS processes test. Execute a sequence of typical exposures (see [RD 04]).
2. OS templates test. Execute a self-test OBD consisting of the whole list of implemented templates (see [RD 04]).

6.16 Standards

The OS Server and Archiver processes are based on the standard package boss (see [RD 10]), which is conform to the VCS-Archive interface requirements (see [AD 08]) [ISFS75]

Templates are based on the standard package tpl (see [RD 08]) and are executed through the standard bob utility (see [RD 11]), which is conform to the VCS-OH interface requirements (see [AD 07]). [ISFS90]

The OS GUIs are built using the CCS panel editor utility.

6.17 Modules

The cmm modules belonging to OS are [ISFS91]:

1. xxo. It is the main module and includes the OS processes code.
2. xxopan. It includes the code for the OS GUIs
3. xxoseq. It includes the templates code and the templates test obd files
4. xxotsf. It includes the templates signature files and instrument package.

7 MAINTENANCE SOFTWARE (MS)

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.

All maintenance operations supported by Software will be implemented as technical Templates, as requested in [AD 02], and are listed in section 7.1

7.1 Configuration

The whole Instrument Configuration will be contained in configuration files within the module xxmcfg.

Only user xxxxmgr will be allowed to change the contents of configuration files and thus to change the instrument configuration. User xxxx can only read the contents of the configuration files [ISFS99].

The standard mechanism, described in [RD 12], to change and save the instrument configuration will be used [ISFS100].

7.2 Templates

The implementation of templates will be based on the rules defined in [RD 08] and on the standard tool tpl [ISFS71].

The parameter values used within MS templates will be in user units, whenever possible, or engineering units, if necessary [ISFS94]

The following templates are foreseen [ISFS73]:

1. XXXX_IRIMG_cal_focus. Instrument focus. Measure the instrument focus. It will use a MIDAS procedure to for the on-line image processing [ISFS68].

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

c. Determine the optimal focus position and log its value in FITS format [ISFS97]

2. XXXX_gen_tec_filtXchg. 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. ……..

b. Ask the operator to validate this change in the instrument configuration [ISFS98]

c. Log the change in FITS format [ISFS97]

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

Parameters:

· ……

Sequence:

a. ……..

4. XXXX_gen_tec_motcurr. 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. ……..

7.2.1 Instrument technical package

MS shall provide to P2PP the Instrument Technical Package XXXX_tec.zip [ISFS77], consisting of all the OS and MS templates and the Instrument Summary File XXXX.isf.

7.3 Performance

All critical performance requirements must be analyzed here. In particular, it shall be investigated if the usage of standards fulfills all performance requirements or special solutions must be considered instead. Information about performance aspects related to the usage of the VLT common software is available in the VLT software documentation (User Manuals) or may be provided by ESO software staff. Whenever uncertainties are present, dedicated prototyping is mandatory and the results must be presented here, together with the conclusions and the proposed solutions.

The following sub-sections are just examples of typical fields where performance requirements are specified. They should not be considered exhaustive for all instruments nor are all of them necessarily applicable to all instruments.

7.3.1 Data processing

For the foreseen on-line data processing on the IWS, the standard tool used guarantees a satisfactory response time.

7.4 Test Software

The MS Test Software shall consist of [ISFS95]:

1. MS templates test. Execute a self-test OBD consisting of the whole list of implemented technical templates (see [RD 04]).

7.5 Standards

Templates are based on the standard package tpl (see [RD 08]) and are executed through the standard bob utility (see [RD 11]).

7.6 Modules

The cmm modules belonging to MS are [ISFS96]:

1. xxmcfg. It includes all instrument configuration files
2. dicXXXX. It includes all instrument dictionaries
3. xxmseq. It includes the technical templates code and the templates test obd files
4. xxmtsf. It includes the technical templates signature files and the technical instrument package.

8 OBSERVER SUPPORT SOFTWARE (OSS)

8.1 Standards

The standard P2PP utility is used to prepare Observation Blocks [ISFS93]

8.2 Modules

No cmm module is foreseen for OSS.

9 SYSTEM ATTRIBUTES

9.1 Installation

The Software installation procedure will be based on the standard tool pkgin and the related files will be part of the installation module xxins [ISFS105]

9.2 Startup/Shutdown

Scripts xxinsStart and xxinsStartup will be implemented to startup the whole instrumentation software or parts of it. Script xxinsStop will be implemented to shutdown the whole instrumentation software or parts of it [ISFS09].

These scripts will be based on standard features available in the module stoo [ISFS10].

9.3 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 User Station shall consist of [ISFS55]:

1. Screen 1:
1. Workspace 1: BOB GUI and OS Control GUI.
2. Workspace 2: OS status GUI
3. Workspace 3: ICS stand-alone GUI
4. Workspace 4: Detector stand-alone GUI
2. Screen 2: Detector Real-Time Display GUI, Alarms GUI (VLT standard) [ISFS51] and Logs GUI (VLT standard)

Optionally, sounds will be associated to individual alarms [ISFS54]

GUIs will always be started/stopped as the result of the execution of the script xxinsStart/xxinsStop. They will never be started or stopped automatically by processes. The only exception is represented by small acknowledgement panels, which may be started from templates [ISFS104].

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

A separate screen will be available for off-line data reduction [ISFS57].

9.4 Security

The following alarms will be handled [ISFS101]:

1. UV camera temperature too high. OLDB attribute <alias>TUVC.alarm0 [ISFS103]
2. IR camera temperature too high. OLDB attribute <alias>TIRC.alarm0 [ISFS103]
3. …..

Alarm will be triggered only if the value of the associated on-line database attribute is up-to-date [ISFS102], in particular:

• The scan system link to the LCU controlling the related device is active.
• The related device is online and monitoring the value.
• No error was detected during the last read operation from the hardware.

What above will be achieved by applying the appropriate Calculation Engine formula (see [RD 14]) to the CCS on-line database attribute.

9.5 Availability

Software Configuration Control shall be guaranteed by using official releases of the VLT Software and the standard cmm facilities to archive and modify instrument specific code [ISFS62].

9.6 Maintainability

It will be possible to build and install from scratch the whole instrument software [ISFS05]. The procedure to achieve this will be based on the standard tool pkginBuild [ISFS08].

Instrument specific code will be developed according to the rules defined in [AD 05] [ISFS63]

9.7 Documentation

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

Each Software document is archived in a separate cmm module (same name as the document number). The format of the source file is WinWord [ISFS79].

9.8 Adaptability and enhancement potential

Being the Software heavily based on VLT Software standard components, thus minimizing the amount of specific code to be developed, it will be able to run on any platform supported by the VLT Common Software.

No enhancements to the baseline are at the present stage foreseen.

9.9 Training

Being the Software heavily based on VLT Software standard components, no specific training for users (scientists, operators and engineers) with experience of VLT operations is foreseen. Paranal staff is however supposed to be involved in the PAE in Europe and AIV and commissioning in Chile, and this shall be considered as part of their training.

10 DEVELOPMENT AND TEST FACTORS

10.1 Project Control

See [RD 13]

10.2 Test

The set of tests described in [RD 04] and [AD 11], and in the present document at sections 4.13, 5.12, 6.15 and 7.4, are part of the Instrumentation Software package deliverables.

They will be developed in parallel with the control code and will periodically (at least once every two months) repeated as part of the exercise aiming to rebuild the Control Software from scratch, thus aligning the running version at all development and integration locations. For this reason, the test procedures will be automatic and the results reproducible, also in absence of some hardware components (i.e. with devices in simulation); the VLT standard tool tat will be used for this purpose [ISFS106]

It will also be the basis for the PAE run.

11 Traceability matrix

The following table aims to set a link between the requirements defined in [AD 02] and [AD 11] and the contents of this document.

Req.	DOC.	LABEL	PAGE	DESCRIPTION
REQ01	[AD 11]	ISFS17 ISFS45 ISFS18	19 21 25	List of devices and assemblies
REQ02	[AD 11]	ISFS24	19	Lamps in stand-by state
REQ03	[AD 11]	ISFS23	20	Derotator modes
REQ04	[AD 11]	ISFS25	21	Measures to overcome mechanical backlash
REQ05	[AD 11]	ISFS26	20	Gratings setup parameters
REQ06	[AD 11]	ISFS27	20	Sensors sampling period
REQ07	[AD 11]	ISFS21	25	UV detector size
REQ08	[AD 11]	ISFS22	25	IR detector size
REQ09	[AD 11]	ISFS28	21	Cryogenic devices kept to the necessary minimum
REQ10	[AD 11]	ISFS74	28	List of observing modes
REQ11	[AD 11]	ISFS74	28	Automatic settings in UV spectroscopy
REQ12	[AD 11]	ISFS74	28	Automatic settings in IR spectroscopy
REQ13	[AD 11]	ISFS74	28	Automatic settings in dichroic spectroscopy
REQ14	[AD 11]	ISFS74	28	Automatic settings in IR imaging
REQ15	[AD 11]	ISFS31	21	Description of state OFF
REQ16	[AD 11]	ISFS32	21	Description of state LOADED
REQ17	[AD 11]	ISFS33	21	Description of state STANDBY
REQ18	[AD 11]	ISFS34	21	Description of state ONLINE
REQ19	[AD 11]	ISFS100	34	Save and retrieve Instrument Configuration
REQ20	[AD 11]	ISFS98	34	User acknowledgement before changing Instrument Configuration
REQ21	[AD 11]	ISFS99	34	Protection of Instrument Configuration files
REQ22	[AD 11]	ISFS46	24	Device hardware simulation
REQ23	[AD 11]	ISFS46	24	Support full hardware simulation
REQ24	[AD 11]	ISFS12	26	Data acquisition maximum speed
REQ25	[AD 11]	ISFS12	26	Maximum Software overhead for data acquisition
REQ26	[AD 11]	ISFS67	32	Display all images
REQ27	[AD 11]	ISFS13	26	Maximum delay between acquisition and display
REQ28	[AD 11]	ISFS65	25	Mouse driven operations on image display
REQ29	[AD 11]	ISFS59	30	Image files in FITS format
REQ30	[AD 11]	ISFS59	30	FITS header conform to ESO standards
REQ31	[AD 11]	ISFS50	22	Sensors information in the FITS header
REQ32	[AD 11]	ISFS58	11	Typical disk storage requirement for one night
REQ33	[AD 11]	ISFS58	11	Maximum disk storage requirement for one night
REQ34	[AD 11]	ISFS59	30	Archive all image FITS files
REQ35	[AD 11]	ISFS60	30	Archive in background
REQ36	[AD 11]	ISFS68	34	On-line data processing on the IWS
REQ37	[AD 11]	ISFS49 ISFS20 ISFS75	23 25 28	Information to be logged
REQ38	[AD 11]	ISFS87	29	Information displayed in the OS control GUI
REQ39	[AD 11]	ISFS88	29	Information displayed in the OS status GUI
REQ40	[AD 11]	ISFS55	37	User Station screen 1 contents
REQ41	[AD 11]	ISFS55	37	User Station screen 2 contents
REQ42	[AD 11]	ISFS56	37	P2PP on dedicated screen
REQ43	[AD 11]	ISFS57	37	Off-line data reduction on dedicated WS and screen
REQ44	[AD 11]	ISFS86	29	Functionality required from TCS
REQ45	[AD 11]	ISFS78	23	Hardware interlocks
REQ46	[AD 11]	ISFS72	32	Science operations according to the Science Operations Plan
REQ47	[AD 11]	ISFS89	32	Parameters during science operations in high level units
REQ48	[AD 11]	ISFS40 ISFS20 ISFS75	22 25 28	Check for parameters value validity
REQ49	[AD 11]	ISFS61	21	Parallel setup of devices
REQ50	[AD 11]	ISFS69	32	Lamps with warm-up time switched on at the first setup
REQ51	[AD 11]	ISFS70	32	Continuous derotator motion during integrations
REQ52	[AD 11]	ISFS94	34	Parameters during maintenance operations in high level or engineering units
REQ53	[AD 11]	ISFS73	34	Maintenance operations supported by Templates
REQ54	[AD 11]	ISFS72 ISFS73	32 34	List of Templates
REQ55	[AD 11]	ISFS11	33	Maximum time for bias exposure
REQ56	[AD 11]	ISFS44 ISFS84 ISFS92 ISFS95	24 26 33 35	List of scripts/procedures for the test Software
REQ57	[AD 11]	ISFS36	23	Software alarms warn for approaching hardware interlock conditions
REQ58	[AD 11]	ISFS53	24	Warnings shall be logged
REQ59	[AD 11]	ISFS36	23	Warnings treated as low priority alarms
REQ60	[AD 11]	ISFS51	37	Alarms displayed with standard tool
REQ61	[AD 11]	ISFS51	37	Alarms GUI permanently displayed in the User Station
REQ62	[AD 11]	ISFS36	23	List of Alarms
REQ63	[AD 11]	ISFS53	24	Alarms shall be logged
REQ64	[AD 11]	ISFS54	37	Sounds associated to alarms
REQ65	[AD 11]	ISFS52	23	Alarms monitoring also in STANDBY
REQ66	[AD 11]	ISFS14	24	Initialization maximum time
REQ67	[AD 11]	ISFS15	24	Setup maximum time
INS01	[AD 02]	ISFS01	11	Define Instrument ID and prefix in agreement with ESO
INS02	[AD 02]	ISFS02	11	Time critical synchronization via Time Reference System
INS03	[AD 02]	ISFS03	11	Naming conventions for Instrument LAN nodes
INS04	[AD 02]	ISFS04	12	Instrument Software divided into the standard INS Modules
INS05	[AD 02]	ISFS05 ISFS09	37 37	Facilities to build, install, startup and shutdown must be available
INS06	[AD 02]	ISFS68	34	On-line data processing done within templates, if no real-time requirements
INS07	[AD 02]	ISFS68	34	ESO approval required for on-line data processing
INS08	[AD 02]	ISFS68	34	ESO approval required for the choice of on-line data processing tool
INS09	[AD 02]	ISFS48 ISFS20 ISFS87 ISFS88	22 25 29 29	All GUIs based on the VLT panel editor
INS10	[AD 02]	ISFS44 ISFS84 ISFS92 ISFS95	24 26 33 35	Test Software part of the mandatory deliverables. Standard minimum set applicable
INS11	[AD 02]	See [RD 13]		Use Template Instrument to build a new instrument from scratch
INS12	[AD 02]	ISFS62	37	Use cmm for Software configuration control management (Archive)
INS13	[AD 02]	ISFS43 ISFS81 ISFS91 ISFS96	24 27 33 35	Follow cmm modules naming conventions
INS14	[AD 02]	ISFS63	37	VLT programming standards applicable to Instrumentation Software
INS15	[AD 02]	ISFS96	35	Instrument configuration under Software configuration control
INS16	[AD 02]	ISFS37 ISFS83	22 29	Instrument configuration files in one single cmm module belonging to MS
INS17	[AD 02]	ISFS06	13	One CCS environment for each LAN node
INS18	[AD 02]	ISFS06	13	Use CCS-lite
INS19	[AD 02]	ISFS06	13	CCS environment name same as LAN node name
INS20	[AD 02]	ISFS07	13	Two users for each instrument
INS21	[AD 02]	N/A	N/A	Use CCD Software for Technical CCDs
INS22	[AD 02]	ISFS107	25	Use IRACE Software for Infra-red scientific cameras
INS23	[AD 02]	ISFS20	25	Use FIERA Software for optical scientific cameras
INS24	[AD 02]	ISFS20	25	Use dxf for data transfer between nodes
INS25	[AD 02]	ISFS65	25	Use rtd for Real-Time display
INS26	[AD 02]	ISFS30	19	Use icb for ICS processes and icbpan for ICS GUIs
INS27	[AD 02]	ISFS75	28	Use boss for OS processes
INS28	[AD 02]	ISFS71	32	Use tpl for templates
INS29	[AD 02]	ISFS30 ISFS20 ISFS75	19 25 28	Use oslx for FITS keywords handling
INS30	[AD 02]	ISFS08	37	Use pkgin for build and installation
INS31	[AD 02]	ISFS64 ISFS75	22 28	Use ctoo for Instrument configuration files handling
INS32	[AD 02]	ISFS10	37	Use stoo for startup and shutdown
INS33	[AD 02]	ISFS16	19	ICS controls all devices, except detectors
INS34	[AD 02]	ISFS31 ISFS20 ISFS75	21 25 28	ICS, DCS and OS implement standard states
INS35	[AD 02]	ISFS35 ISFS20 ISFS75	21 25 28	ICS, DCS and OS implement standard commands
INS36	[AD 02]	ISFS37 ISFS20 ISFS75	22 25 28	ICS, DCS and OS configuration parameters values shall not be hard-coded
INS37	[AD 02]	ISFS66 ISFS20	22 25	ICS and DCS LCU status stored in the database
INS38	[AD 02]	ISFS38 ISFS20 ISFS75	22 25 28	ICS, DCS and OS parameters values shall not be changed until a new command requests for it
INS39	[AD 02]	ISFS66 ISFS20 ISFS75	22 25 28	ICS, DCS and OS set and actual values stored in separate database attributes
INS40	[AD 02]	ISFS39	22	Status of ICS on-going and completed actions shall be accessible
INS41	[AD 02]	ISFS40 ISFS20	22 25	ICS, DCS and OS Set values shall be checked for validity
INS42	[AD 02]	ISFS41 ISFS20	22 25	ICS, DCS and OS keywords shall be syntactically checked against dictionary
INS43	[AD 02]	ISFS42 ISFS20	22 25	Use CCS scan system to transfer ICS and DCS parameters values from LCU to IWS database
INS44	[AD 02]	ISFS50 ISFS20	22 25	ICS and DCS part of FITS header shall contain full status information and some statistics
INS45	[AD 02]	ISFS50 ISFS20	22 25	ICS and DCS part of FITS header shall be produced also in simulation
INS46	[AD 02]	ISFS41 ISFS20 ISFS82	22 25 29	ICS, DCS and OS keywords in the FITS header should be syntactically checked against dictionary and comply with the rules defined in the Data Interface Control Document.
INS47	[AD 02]	ISFS48 ISFS20	22 25	ICS and DCS stand-alone GUI must be available
INS48	[AD 02]	ISFS49 ISFS20	23 25	ICS and DCS complete logging: commands, errors, LCU boot, sensors values, movements
INS49	[AD 02]	ISFS46 ISFS20	24 25	ICS and DCS simulation at WS level
INS50	[AD 02]	ISFS46	24	ICS devices simulation at LCU level
INS51	[AD 02]	ISFS47	24	ICS and DCS simulation shall not be hidden to the user
INS52	[AD 02]	ISFS47	24	ICS and DCS simulation shall be indicated in the FITS header
INS53	[AD 02]	ISFS29	21	Implementation of ICS special devices must be approved by ESO
INS54	[AD 02]	ISFS43	24	ICS cmm modules follow the naming conventions
INS55	[AD 02]	ISFS19	25	One DCS responsible for each camera (one camera may control a mosaic)
INS56	[AD 02]	ISFS20 ISFS75	25 28	Handling of FITS header size between DCS and OS
INS57	[AD 02]	ISFS20	25	DCS DFE simulation at LCU level
INS58	[AD 02]	ISFS20	25	DCS hw simulation at DFE level
INS59	[AD 02]	ISFS20	25	DCS readout frames simulation supported
INS60	[AD 02]	ISFS11	33	DCS must support highest possible duty cycle
INS61	[AD 02]	ISFS20	25	DCS DUMP command for image re-transmission
INS62	[AD 02]	ISFS20	25	Save readout data also in case of failure
INS63	[AD 02]	ISFS20	25	DCS data saved in FITS format uncompressed
INS64	[AD 02]	ISFS20	25	DCS data saved in binary format
INS65	[AD 02]	ISFS58	11	DCS data saved on dedicated disk not concurrently accessed by other applications
INS66	[AD 02]	ISFS20	25	DCS must check for disk space availability before starting an exposure
INS67	[AD 02]	ISFS76	25	Windowed and binned readout supported
INS68	[AD 02]	ISFS65	25	DCS data optionally displayed with different orientation
INS69	[AD 02]	ISFS20	25	DCS responsible for shutter time. If shutter controlled by ICS, use TRS for synchronization
INS70	[AD 02]	ISFS20	25	Actual exposure time should take into account shutter opening and closing time
INS71	[AD 02]	ISFS81	27	DCS cmm modules follow the naming conventions
INS72	[AD 02]	ISFS75	28	OS Server responsible for coordination of single exposures
INS73	[AD 02]	ISFS75	28	OS Server shall handle overlapping exposures
INS74	[AD 02]	ISFS75	28	OS Server shall handle parallel exposures
INS75	[AD 02]	ISFS59	30	Results of exposures shall always be archived (FITS format)
INS76	[AD 02]	ISFS60	30	OS Archiver shall not affect the observing cycle. Archiving errors shall be reported to BOB
INS77	[AD 02]	ISFS59	30	FITS files containing results of exposures shall follow naming conventions
INS78	[AD 02]	ISFS72	32	OS includes templates
INS79	[AD 02]	N/A	N/A	SOS responsible for coordination of exposures involving more than one instrument
INS80	[AD 02]	ISFS75	28	Mandatory OS parameters are available
INS81	[AD 02]	ISFS85	28	Use standard exposure types
INS82	[AD 02]	ISFS59	30	Follow rules for FITS files and keywords contained in the Data Interface Control Document
INS83	[AD 02]	ISFS72 ISFS73	32 34	Implement complex operations in Templates
INS84	[AD 02]	N/A	N/A	Implement special functionality (e.g. auto-guiding, active optics) in separate OS process
INS85	[AD 02]	ISFS73	34	All AIV and Commissioning activities supported by technical templates
INS86	[AD 02]	ISFS87	29	Implement OS Control panel
INS87	[AD 02]	ISFS88	29	Implement OS Status panel
INS88	[AD 02]	ISFS90	33	Follow ICD between OS and OH
INS89	[AD 02]	ISFS75	28	Follow ICS between OS and Archive
INS90	[AD 02]	ISFS91	33	OS cmm modules follow the naming conventions
INS91	[AD 02]	ISFS96	35	All Instrument configuration files in one cmm module belonging to MS
INS92	[AD 02]	ISFS96	35	All dictionary files in one cmm module belonging to MS
INS93	[AD 02]	ISFS99	34	Instrument configuration parameters protected from not authorized users
INS94	[AD 02]	ISFS100	34	Use standard mechanism to control Instrument configuration changes
INS95	[AD 02]	ISFS97	34	Instrument configuration changes shall be logged in FITS format
INS96	[AD 02]	ISFS73 ISFS77	34 35	MS procedures implemented as technical templates. A Technical Instrument Package must exist
INS97	[AD 02]	ISFS97	34	Results of technical templates logged in FITS format or in CCS sampling tool format
INS98	[AD 02]	ISFS96	35	MS cmm modules follow the naming conventions
INS99	[AD 02]	ISFS93	36	ESO authorization needed if p2pp complemented by a dedicated OSS tool for OB preparation tool
INS100	[AD 02]	N/A	N/A	Special tool for target selection, if needed, part of OSS
INS101	[AD 02]	N/A	N/A	OSS cmm modules follow the naming conventions
INS102	[AD 02]	ISFS36	23	Alarms must be listed in ISFS document and detailed in ISDD document
INS103	[AD 02]	ISFS51	37	Alarms implementation compatible with the CCS Alarm System
INS104	[AD 02]	ISFS102	37	Alarms triggered only if the value of the related database attribute is up-to-date
INS105	[AD 02]	ISFS103	37	Alarm database attributes associated to sensors must follow a standard naming scheme
INS106	[AD 02]	ISFS88	29	Alarm conditions displayed in the OS status panel
INS107	[AD 02]	ISFS104	37	Panels shall not pop-up and disappear automatically
INS108	[AD 02]	ISFS55	37	Static placement of panels
INS109	[AD 02]	ISFS104	37	A GUI shall not automatically close another panel
INS110	[AD 02]	ISFS55	37	User Station must follow standard configuration (2 screens). Extensions must be agreed with ESO
INS111	[AD 02]	ISFS86	29	Follow standard interface to TCS/VLTI
INS112	[AD 02]	ISFS105	37	Installation module shall follow the standard naming convention
INS113	[AD 02]	N/A	N/A	Instrument specific adds-on to stoo functionality must be in the installation module
INS114	[AD 02]	ISFS09	37	Restart one INS module without restarting the whole INS Software
INS115	[AD 02]	ISFS09	37	ICS and DCS must provide own startup/shutdown scripts for the stand-alone mode
INS116	[AD 02]	ISFS79	38	Documentation in same electronic format used at ESO
INS117	[AD 02]	ISFS80	12	Instrument Software architecture must follow the scheme described in the INS Software Specs
INS118	[AD 02]	ISFS20 ISFS64 ISFS65 ISFS30 ISFS75 ISFS71 ISFS08 ISFS10	25 22 25 19 28 32 37 37	Use VLT common software wherever possible
INS119	[AD 02]	See [RD 13]		Software activities included in the Instrument Software Management Plan
INS120	[AD 02]	See [RD 13]		Instrument Software User Requirements document reviewed before PDR
INS121	[AD 02]	See [RD 13]		Freeze Software User Requirements at PDR
INS122	[AD 02]	See [RD 13]		Review Software Functional Specification at PDR. Recommended a few iterations before
INS123	[AD 02]	See [RD 13]		Before PDR run Template Instrument, build Instrument Software skeleton, check performances
INS124	[AD 02]	See [RD 13]		Review Software Design document(s) at FDR. Recommended a few iterations before
INS125	[AD 02]	See [RD 13]		Review Acceptance Test Plan document at FDR.
INS126	[AD 02]	See [RD 13]		Before FDR Instrument skeleton according to actual configuration, no code except for prototypes
INS127	[AD 02]	ISFS106	39	Software test procedures automatic and reproducible, based on tat
INS128	[AD 02]	See [RD 13]		Accept. Test Plan, User and Maintenance manual ready for PAE. Recommended a few iterations before
INS129	[AD 02]	See [RD 13]		Acceptance Test Report produced as result of PAE
INS130	[AD 02]	See [RD 13]		Agree with ESO intermediate check points between FDR and PAE
INS131	[AD 02]	See [RD 13]		PAE at integration premises and in the VLT Control Model
INS132	[AD 02]	ISFS43 ISFS81 ISFS91 ISFS96 ISFS105 ISFS79	24 27 33 35 37 38	Software and documentation under cmm
INS133	[AD 02]	N/A	N/A	OS shall be able to handle secondary guiding TCCDs in parallel to science exposures.

___oOo___