Template Document

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 Instrumentation Software

---

Acceptance Test Plan

Template Document

Doc. No.: VLT-PLA-ESO-17240-2266

Issue: 3

Date: 31/03/2003

Name�� Date�� Signature

�� Prepared:� A.Longinotti�� 31/03/2003

Name�� Date�� Signature

�� Approved:� K.Wirenstrand��

Name�� Date�� Signature

�� Released:� K.Wirenstrand��

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	17/08/2000	All	First issue
2	28/03/2002	All	MAR2002
3	31/03/2003	All	APR2003

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�� 8

1.7.1�� Data Flow and Processor Model Diagrams�� 8

1.8�� NAMING CONVENTIONS�� 8

1.9�� PROBLEM REPORTING/CHANGE REQUEST�� 8

2 OVERVIEW�� 9

2.1�� HARDWARE REQUIREMENTS�� 9

2.2�� SOFTWARE REQUIREMENTS�� 9

3 TEST DESCRIPTION�� 10

3.1�� DOCUMENTATION�� 10

3.1.1�� Instrument Software Acceptance Test Plan�� 10

3.1.2�� Instrument Software User and Maintenance Manual (DOC001)�� 10

3.1.3�� Instrument Software Acceptance Test Report�� 10

3.2�� STANDARDS�� 10

3.2.1�� Programming Standards (STD001)�� 10

3.2.2�� Standard Architecture (STD002)�� 10

3.2.3�� DCS packages (STD003)�� 10

3.2.4�� ICS package (STD004)�� 10

3.2.5�� OS package (STD005)�� 10

3.2.6�� Startup procedures (STD006)�� 10

3.2.7�� Rules and package for templates (STD007)�� 10

3.2.8�� Instrument Configuration files (STD008)�� 10

3.2.9�� Users name (STD009)�� 11

3.3�� INSTALLATION�� 11

3.3.1�� Rebuild Instrument Software from scratch (INS001)�� 11

3.3.2�� Usage of pkgin to build the Instrument Software (INS002)�� 11

3.3.3�� Access to cmm Archive (INS003)�� 11

3.3.4�� Installation failures check (INS004)�� 11

3.3.5�� Instrument package for P2PP (INS005)�� 11

3.4�� SUB-SYSTEMS TEST�� 11

3.4.1�� DCS test (DCS001)�� 11

3.4.2�� ICS special sensor device LCU test� (ICS001)�� 11

3.4.3�� ICS special device test� (ICS002)�� 12

3.4.4�� ICS test� (ICS003)�� 12

3.5�� GRAPHICAL USER INTERFACE�� 12

3.5.1�� DCS stand-alone GUI (GUI001)�� 12

3.5.2�� ICS stand-alone GUI (GUI002)�� 12

3.5.3�� OS Control GUI (GUI003)�� 12

3.5.4�� OS Status GUI (GUI004)�� 12

3.5.5�� GUIs layout (GUI005)�� 12

3.6�� OS�� 12

3.6.1�� Startup/Shutdown (OS001)�� 12

3.6.2�� Single exposure (OS002)�� 13

3.6.3�� Templates (OS003)�� 13

3.7�� MS�� 13

3.7.1�� Technical templates (MS001)�� 13

3.7.2�� Results format (MS002)�� 13

3.8�� ALARMS�� 13

3.8.1�� Emergency cases (ALM001)�� 13

3.8.2�� Simulate alarms (ALM002)�� 13

3.8.3�� Configure alarm conditions (ALM003)�� 13

3.9�� DATA FLOW�� 13

3.9.1�� Interface P2PP-BOB (DFS001)�� 13

3.9.2�� Interface OS-Archive (DFS002)�� 13

4 TEST EXECUTION�� 14

5 REFERENCE�� 18

5.1�� xxinsTestClean�� 18

5.2�� xxdTest�� 19

5.2.1�� xxdTestIrace�� 20

5.2.2�� xxdTestTccd�� 21

5.2.3�� xxdTestFiera�� 22

5.3�� xxidevTest�� 23

5.4�� xxiTest�� 24

5.5�� xxoTest�� 25

5.6�� xxoTestAlarms�� 26

This page has been left intentionally blank.

1 INTRODUCTION

1.1 PURPOSE

Purpose of Preliminary Acceptance Europe (PAE) is to verify the readiness of an instrument, in terms of fulfilling requirements, before being shipped to Chile for commissioning.

According to the VLT Software Management Plan [AD 12], an Acceptance Test Plan (ATP) document has to be issued by the consortium in charge of the instrument and reviewed by ESO well before the foreseen PAE. Such a document must contain a list of tests, which have to successfully pass in order to certify that the instrument has completed the implementation phase and is ready for commissioning. As a result of PAE, an Acceptance Test Report (ATR) document has to be produced.

The ATR document normally consists of the ATP added with the results of the PAE, including any relevant comment/remark. It has to be prepared by the consortium and agreed with ESO, before being issued.

The present document provides structure and contents of an ATP document and indicates which characteristics the software for an instrument, to be operated and maintained at Paranal, is expected to have, in terms of packages and standards used. In particular it aims to emphasize the importance of using common software to implement common functionality: it increases the maintainability of the final product.

This document is intended to be applicable to all contracts with consortia for. It should therefore be added to the list of applicable documents in the related Statement of Work.

1.2 SCOPE

The present document describes all tests foreseen for PAE, to verify the completeness of the instrument software before shipment to Chile. It covers the whole set of functionality as described in the User Requirements document.

This document aims to provide instrumentation software responsible, from ESO and from consortia, with a template of Acceptance Test Plan (ATP) document. Instrument specific ATP documents should be based on this template. They must contain at least the tests described herein (whenever applicable), and possibly add instrument specific tests.

Paragraphs in italics should be removed.

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]	GEN-SPE-ESO-19400-0794	2.0	31/10/1997	DICB - Data Interface Control Document
[AD 02]	VLT-SPE-ESO-10000-0011	2.0	30/09/1992	VLT Software Requirements Specification
[AD 03]	VLT-PRO-ESO-10000-0228	1.0	10/03/1993	VLT Software Programming Standards
[AD 04]	VLT-PLA-ESO-10000-0441	1.0	01/05/1995	VLT Science Operation Plan
[AD 05]	VLT-MAN-ESO-17210-0667	1.0	03/12/1997	Guidelines for VLT applications.
[AD 06]	VLT-SPE-ESO-17212-0001	2.0	23/02/1995	INS Software Specification
[AD 07]	VLT-SPE-ESO-17240-0385	2.1	15/07/1996	INS Common Software Specification
[AD 08]	VLT-ICD-ESO-17240-19400	2.6	17/11/1997	ICD between VCS and Archive
[AD 09]	VLT-ICD-ESO-17240-19200	1.3	07/06/2000	ICD between VCS and OH
[AD 10]	TEC-TSW-00/0044	Memo	16/08/2000	Software documentation for Instrum. projects
[AD 11]	TEC-TSW-00/0045	Memo	01/08/2000	Rtap policy for Instrumentation Control Software
[AD 12]	VLT-PLA-ESO-00000-0006	2.0	21/05/1992	VLT Software Management Plan

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	2	30/03/2002	VLT Common Software Installation Manual
[RD 03]	VLT-SPE-ESO-17120-1355	1.2	12/01/1999	Final Lay-out of VLT Control LANs
[RD 04]	VLT-MAN-SBI-17210-0001	3.6	01/03/2001	LCU Common Software User Manual
[RD 05]	VLT-MAN-ESO-17210-0600	1.7	02/10/1998	Motor Control sw User Manual API/ACI
[RD 06]	VLT-MAN-ESO-17210-0669	1.4	20/10/1997	Motor Engineering Interface User Manual
[RD 07]	VLT-MAN-ESO-17210-0619	2.2	31/03/2002	Central Control Software User Manual
[RD 08]	VLT-MAN-ESO-17210-0707	1.6	30/09/1999	On Line Database Loader User Manual
[RD 09]	VLT-MAN-ESO-17210-0771	1.8	06/10/2001	EVH User Manual
[RD 10]	VLT-MAN-ESO-17210-0770	1.8	30/09/2001	Extended CCS User Manual
[RD 11]	VLT-MAN-ESO-17210-0690	4.3	31/03/2002	Panel Editor User Manual
[RD 12]	VLT-MAN-ESO-17240-0853	1.4	25/04/2001	INS Common sw � oslx User Manual
[RD 13]	VLT-MAN-ESO-17240-0672	1.6	25/09/1998	CCD Detectors Control Software User Manual
[RD 14]	VLT-MAN-ESO-14100-1878	1.1	19/10/1999	IRACE-DCS User Manual
[RD 15]	VLT-MAN-ESO-17240-0934	3	30/03/2002	Base ICS User Manual
[RD 16]	VLT-MAN-ESO-17240-2265	1.1	25/04/2001	Base OS Stub User Manual
[RD 17]	VLT-MAN-ESO-17240-1913	2	30/03/2002	Installation Tool for VLT Sw packages
[RD 18]	VLT-MAN-ESO-17240-2153	2	30/03/2002	Startup Tool Stub User Manual
[RD 19]	VLT-MAN-ESO-17220-0737	3	28/03/2002	HOS � Sequencer User Manual
[RD 20]	VLT-MAN-ESO-17220-1999	2	27/03/2002	Broker for Observation Blocks User Manual
[RD 21]	VLT-MAN-ESO-13640-1388	1.2	22/11/1999	FIERA CCD Controller Software User Manual
[RD 22]	VLT-MAN-ESO-17240-2240	2	28/03/2002	Common Software for Templates User Manual
[RD 23]	VLT-MAN-ESO-17240-1973	3	28/03/2002	Template Instrument User Manual
[RD 24]	VLT-MAN-ESO-17240-2606	2	28/03/2002	Base ICS GUI User Manual
[RD 25]	VLT-MAN-ESO_17200-0908	1.4	15/02/2001	Tool for Automated Testing 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:

ATP	Acceptance Test Plan
ATR	Acceptance Test Report
CCS	Central Control Software
CPU	Central Processing Unit
DCS	Detector Control Software
DFS	Data Flow System
ESO	European Southern Observatory
FITS	Flexible Image Transport Format
GUI	Graphical User Interface
HW	Hardware
ICS	Instrument Control Software
INS	Instrumentation Software Package
I/O	input/output
ISAAC	Infrared Spectrograph and Array Camera
ISF	Instrument Summary File
IWS	Instrument Workstation
LAN	Local Area Network
LCC	LCU Common Software
LCU	Local Control Unit
MS	Maintenance Software
N/A��	Not Applicable
OMT	Object Modeling Technique
OO	Object Oriented
OOD	Object Oriented Design
OS	Observation Software
PAE	Preliminary Acceptance Europe
P2PP	Phase 2 Proposal Preparation
RAM	Random Access Memory
RTAP	Real-Time Application Platform
SW	Software
TAT	Tool for Automated Testing
TBC	To Be Clarified
TBD	To Be Defined
TCS	Telescope Control Software
TIM	Time Interface Module
TRS	Time Reference System
TSF	Template Signature File
UIF	(Portable) User Interface (Toolkit)
UVES	UltraViolet Visual Echelle Spectrograph
VLT	Very Large Telescope
VME	Versa Module Eurocard
WS	Workstation

1.6 GLOSSARY

No special definition is introduced in this manual

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.7.1 Data Flow and Processor Model Diagrams

Data Flow and processor Model Diagrams are based on De Marco/Yourdon notation for real-time systems [RD 20].

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 02] shall be used.

2 OVERVIEW

The present document is structured as follows:

� Chapter 3 gives a detailed description of the tests to be performed.

� Chapter 4 describes the exact sequence of actions to be executed during PAE.

� Chapter 5 contains the manual pages of the test scripts used to run the tests.

2.1 HARDWARE REQUIREMENTS

The list below refers to the Template Instrument XXXX. It must be modified to reflect the actual requirements of each specific instrument.

In order to perform the whole set of tests described in this document, the following computers and hardware components must be available:

� One Instrument Workstation

� Two LCUs for ICS

� One LCU for the TCCD

� One Sparc LCU for IRACE

� One Sparc LCU for FIERA

2.2 SOFTWARE REQUIREMENTS

In order to perform the whole set of tests described in this document, the following software components must be available:

� UNIX Operating System (see [RD 02] for the types and versions supported).

� VLT Common Software � MAR2001or higher, installed according to [RD 02].

� Access to the cmm Archive.

3 TEST DESCRIPTION

3.1 DOCUMENTATION

This section describes the documents produced for PAE.

3.1.1 Instrument Software Acceptance Test Plan

It is prepared and reviewed before PAE.

It consists of the present document.

3.1.2 Instrument Software User and Maintenance Manual (DOC001)

It is based on [RD 23] and includes:

1. One chapter dedicated to an overview of the architecture of the whole Instrumentation sw (LAN, computers, processes, environments, and database).

2. One chapter dedicated to the installation of the whole Instrumentation Software.

3. One chapter dedicated to observation scenarios, including a layout of the GUIs.

4. One chapter dedicated to Templates.

3.1.3 Instrument Software Acceptance Test Report

It is produced after PAE.

It is derived from the present document, in particular chapter 4, by adding the results and comments from PAE.

3.2 STANDARDS

The following aspects of the Instrumentation Software will be verified through code inspection.

3.2.1 Programming Standards (STD001)

Compliance with Software Programming Standards ([AD 03]) is verified through code inspection on files (randomly around 10% of the total source code) of all main categories (C++, C, tcl).

Since this verification takes time, it is recommended to do it separately before the actual PAE takes place.

3.2.2 Standard Architecture (STD002)

The LAN and hardware platforms (WS, LCUs), including names, are conform to what specified in [RD 03].

For VLTI, VST, La Silla instruments an equivalent reference document should exist.

3.2.3 DCS packages (STD003)

DCS uses the standard DCS package FIERA ([RD 13]) or CCD ([RD 14]) or IRACE ([RD 21]).

Exceptions must be justified and agreed upon at FDR latest.

3.2.4 ICS package (STD004)

ICS uses the base ICS package icb [RD 15] and icbpan [RD 24].

The specific code developed for the instrument ICS must be justified and documented.

3.2.5 OS package (STD005)

OS uses the common OS package BOSS, [RD 16].

The specific code developed for the instrument OS must be justified and documented.

3.2.6 Startup procedures (STD006)

Startup/Shutdown procedures are based on the common tool stoo, [RD 18].

If not based on stoo, at least a short description of the startup procedure (processes started, initialized attributes, commands sent) must be included in the documentation (see 3.1.2).

3.2.7 Rules and package for templates (STD007)

Templates use the common library tpl and follow the rules defined in [RD 22].

3.2.8 Instrument Configuration files (STD008)

All files dealing with the instrument configuration belong to one single dedicated module (xxmcfg).

The User Manual describes the procedures to be followed to keep under sw configuration control any change to the Instrument configuration parameters.

3.2.9 Users name (STD009)

The target Instrument WS defines two users:

1. xxxxmgr, responsible for the installation

2. xxxx, who runs the instrument sw.

For both users, INTROOT and INS_ROOT must be defined according to the standard adopted at Paranal:

� INTROOT� set to /vlt/XXXX/INTROOT

� INS_ROOT set to /data/XXXX/INS_ROOT

3.3 INSTALLATION

All tests described in this section must be executed as user xxxxmgr

3.3.1 Rebuild Instrument Software from scratch (INS001)

It is possible to rebuild from scratch the complete instrument software and related environments.

Before running the installation procedure, the old contents of

$INTROOT, $INS_ROOT, $VLTDATA/ENVIRONMENTS, $VLTDATA/config

are (re)moved, to verify that installation can be done from scratch.

3.3.2 Usage of pkgin to build the Instrument Software (INS002)

The Instrument Software installation is based on pkgin ([RD 17]).

In any case, there must be an automatic installation procedure. To minimize the downtime of the target host during software upgrades at Paranal, verify that the installation procedure is or can be split into two main phases (as pkgin does):

1. Creation of the INTROOT, placing there all files needed by the instrument software, creation of CCS and LCU environments.� It should be possible to execute this phase off-line, not necessarily on the target WS.

�� It should be possible to copy the result (INTROOT) to the target host.

2. The rest of the installation (environment initialization and startup, scan links creation and scan system startup) is always executed at the target host. If possible, this phase should not need access to the sources, only to the INTROOT produced by the first phase.

It must be possible to execute each of these steps with one single UNIX shell command.

3.3.3 Access to cmm Archive (INS003)

The complete code is accessible and can be retrieved from the cmm Archive. This can be verified by checking the contents of the file xxins/config/xxinsINSTALL.cfg.

In order to be able to repeat the tests at any time with exactly the same configuration, all module versions are explicitly registered in this file.

3.3.4 Installation failures check (INS004)

The installation procedure, being based on pkgin, allows easy tracing of failures and possible reasons.

3.3.5 Instrument package for P2PP (INS005)

As result of the build and installation procedure, the Instrument Packages XXXX.tar.gz (observations) and XXXX_tec.tar.gz (maintenance), as defined by P2PP, are produced and placed in $INTROOT/config.

3.4 SUB-SYSTEMS TEST

All tests described in this section must be executed as user xxxx

3.4.1 DCS test (DCS001)

Run dedicated test procedure(s), which exercises for every individual detector system (DCS):

� the proper startup/shutdown

� state change

� execution of the main operations when online:

q one single exposure, for all implemented read-out modes, or a selection of them, if too many.

q verify if FITS files are properly saved in $INS_ROOT/SYSTEM/DETDATA.

Examples are available in xxd/test. The tests can be executed under tat (see [RD 25]); this is the recommended approach.

3.4.2 ICS special sensor device LCU test� (ICS001)

Run for each ICS special sensor device from the vxWorks shell a low-level test, which exercises the device functionality by accessing directly the associated driver.

Examples are available in ic0sen/test.

3.4.3 ICS special device test� (ICS002)

Run for each ICS special device a self-test procedure, which exercises:

� state change

� SETUP all functions in all possible named positions (or samples over a continuous range),

� STATUS �header

An example is available in xxidev/test. The test xxidevTest can be executed under tat (see [RD 25]); this is the recommended approach

3.4.4 ICS test� (ICS003)

Run the ICS self test procedure, based on ic0SelfTest (see [RD 15]). It exercises:

� the proper startup/shutdown

� state change

� SETUP all functions in all possible named positions (or samples over a continuous range),

� STATUS -header -dumpFits.

An example is available in xxi/test. The test xxiTest can be executed under tat (see [RD 25]); this is the recommended approach

3.5 GRAPHICAL USER INTERFACE

3.5.1 DCS stand-alone GUI (GUI001)

The DCS stand-alone GUI allows performing all main operations foreseen:

� startup/shutdown

� go online

� set simulation level

� define a setup

� execute an exposure.

3.5.2 ICS stand-alone GUI (GUI002)

The ICS stand-alone GUI is based on icbpan and allows performing all main operations foreseen:

� startup/shutdown

� go online

� set global simulation level

� set single device simulation level

� define a setup

� execute a setup

3.5.3 OS Control GUI (GUI003)

The OS Control GUI has the following characteristics:

� It is complementary (not alternative) to BOB, in particular

� there is no START button

� there are PAUSE, CONTINUE, CHANGE exp. time, ABORT one single exposure, whenever applicable.

� It shows a summary of the current instrument status

� It shows the current instrument mode

� It shows the main ongoing activities (e.g. status of running exposures).

3.5.4 OS Status GUI (GUI004)

The OS Status GUI shows the detailed status of the whole instrument and its devices.

3.5.5 GUIs layout (GUI005)

GUIs used during observations fit into the scheme and space adopted by Paranal.

In particular, they fit into two screens:

1. Main screen for BOB (left) and OS control (right).

2. Second screen for image display with RTD.

3.6 OS

All tests described in this section must be executed as user xxxx

3.6.1 Startup/Shutdown (OS001)

Run the startup/shutdown procedure, based on the stoo package, for the whole instrument.

3.6.2 Single exposure (OS002)

Execute, through a dedicated test script, one single exposure, involving all sub-systems (DCSs, ICS), and verify the result (FITS file) and its contents. Verify also that the generated FITS file is placed by volac in the right directory for archiving: $INS_ROOT/SYSTEM/ARCDATA.

An example is available in xxo/test. The test xxoTest can be executed under tat (see [RD 25]); this is the recommended approach

3.6.3 Templates (OS003)

Execute through a dedicated test OB (file .obd), in sequence the complete set of templates implemented.

Purpose is not to verify the scientific result, but just the technical result.

In particular, the run time of such an OB should not be more than one hour, possibly < 15 minutes.

Templates, which require the availability of sub-systems (typically acquisition templates, which require the telescope) should preferably implement a simulation of the missing sub-systems. Alternatively, they should not be part of the complete test OB and be included instead in a separate dedicated test OB, to be run only when the sub-systems are available.

3.7 MS

All tests described in this section must be executed as user xxxx

3.7.1 Technical templates (MS001)

All MS procedures are implemented in form of technical templates.

Exceptions should be justified and agreed upon.

3.7.2 Results format (MS002)

The results produced by MS procedures are archived either in form of an ASCII file, with the same format supported by the CCS sampling tool (for those results obtained through this tool or equivalent), or as part of the operational logs file (short-FITS format).

3.8 ALARMS

All tests described in this section must be executed as user xxxx

3.8.1 Emergency cases (ALM001)

The main emergency conditions that may affect the instrument are identified and documented.

3.8.2 Simulate alarms (ALM002)

Alarms corresponding to emergency conditions are implemented in the software.

If possible, check that these alarms work. If it is impossible to test the real cases, HW shall implement simulation conditions. The SW simulation shall be done if there is really no other alternative. Special care will be taken for Emergency Stops, if any.

3.8.3 Configure alarm conditions (ALM003)

Alarm thresholds (if applicable, e.g. LN2 tank level, temperature threshold) can be set through a GUI.

3.9 DATA FLOW

All tests described in this section must be executed as user xxxx

3.9.1 Interface P2PP-BOB (DFS001)

Verify that the P2PP and the Instrument Package are properly installed on the Observation Handling Workstation.

Define an OB with the P2PP tool and fetch it from BOB. Execute it from BOB.

For test purposes P2PP can be installed and started on the Instrument Workstation.

3.9.2 Interface OS-Archive (DFS002)

Verify that all FITS files generated when running an OB are transferred to the online Archive Workstation.

This test can be executed only if an Archive Workstation is available.

4 TEST EXECUTION

This chapter describes, in tabular form, the sequence of actions/commands performed during the PAE to run the complete set of tests/verifications.

The last column in the table is reserved for notes and remarks to be added during PAE and included in the ATR document.

The names of commands and scripts refer to the Template Instrument XXXX. They have to be adapted to each specific instrument

Test ID	Action/Command	Expected results	Notes/comments
DOC001	Check contents of Software User and Maintenance Manual	Document structure and contents similar to [RD 23]
STD001	Inspect around 10% of the code	Compliance with [AD 03]
STD002	Check contents of Software User and Maintenance Manual	Compliance with [RD 03] or equivalent
STD003	Code and documentation inspection	Standard DCS packages are used. Exceptions are explained, justified and agreed by ESO.
STD004	Code and documentation inspection	Standard ICS package is used. Exceptions are explained, justified and agreed by ESO.
STD005	Code and documentation inspection	Standard OS package is used. Exceptions are explained, justified and agreed by ESO.
STD006	Code and documentation inspection	Standard startup package is used. Exceptions are explained, justified and agreed by ESO.
STD007	Code and documentation inspection	Standard templates package is used. Exceptions are explained, justified and agreed by ESO. Compliant with rules described in [RD 22]
STD008	Code and documentation inspection	All configuration files are in module xxmcfg. Manual describes clearly procedures to update the instrument configuration.
STD009	Login on the Instrument WS as user xxxxmgr and xxxx	It is possible to login as xxxxmgr and xxxx. INTROOT and INS_ROOT set as in section 3.2.9
INS001	Run (see 5.1): xxinsTestClean �	$INTROOT, $INS_ROOT $VLTDATA/ENVIRONMENTS are empty. $VLTDATA/config/lxx* files do not exist.
INS002	Run: pkginBuild xxins	No errors from pkginBuild. INTROOT and INS_ROOT contain all files needed to run the instrument software.
INS003	Check contents of xxins/config/xxinsINSTALL.cfg	Only cmm modules are used to build the software from scratch. For each module, the version is specified.
INS004	Check contents of INSTALL/pkginBuild.err	File is empty.
INS005	Check contents of $INTROOT/config	The following files exists: XXXX.tar.gz XXXX_tec.tar.gz
DCS001	Run (see 5.2): xxdTest	The script terminates without errors.
ICS001	From the vxWorks shell run: -> xxidevTestVx �/iser0�	The program executes without errors all what specified in 0
ICS002	Run (see 5.3): xxidevTest	The program executes without errors all what specified in 3.4.3
ICS003	Run (see 5.4): xxiTest	The script executes without errors all what specified in 3.4.4
GUI001	Run: xxinsStart �panel TCCD xxinsStart �panel FIERA xxinsStart �panel IRACE	It is possible to execute all operations described in 0 on each of the DCS panels
GUI002	Run: xxinsStart �panel� ICS	It is possible to execute all operations described in 3.5.2
GUI003	Run: xxinsStart �panel OS_CONTROL	It is possible to execute all operations described in 3.5.3
GUI004	Run: xxinsStart �panel� OS_STATUS	It is possible to execute all operations described in 3.5.4
GUI005	Run: xxinsStartup Wait that the� startup configuration panel pops-up Push the button START	The default panels fits into two screen and the layout is the same as described in 3.5.5
OS001	Run: xxinsStart xxinsStop	The whole Instrument Software is first started and then stopped. No process/panel must be active. The scripts are based on stoo.
OS002	Run (see 5.5)): xxoTest Verify that the results are stored in FITS file(s) and check contents.	The script executes without errors all what specified in 3.6.2
OS003	Load from BOB panel the file XXXX_gen_tec_SelfTest.obd Run from BOB panel that OB. Verify that this OB contains all observation templates.	The OB terminates successfully
MS001	Load from BOB panel the file XXXX_gen_tec_MSTest.obd Run from BOB panel that OB. Verify that this OB contains all maintenance templates.	The OB terminates successfully
MS002	Check results of the execution of XXXX_gen_tec_MSTest.obd	The format is the same as specified in 3.7.2
ALM001	Check contents of Software User and Maintenance Manual	Emergency cases are identified and documented
ALM002	Run (see 5.6): xxoTestAlarms Verify that alarms simulated by HW trigger software alarms	All foreseen software alarms are one by one triggered.
ALM003	Run: xxinsStart �panel ALARM	It is possible to configure through a GUI alarm conditions
DFS001	Start p2pp on the OH WS Build an OB, which produces at least one FITS file Fetch the OB from the BOB panel and start it.	The OB can be defined with the P2PP GUI and executed without errors from BOB.
DFS002	On the on-line archive WS verify that the FITS files produced with the last OB executed have been transferred.	The FITS files are on the on-line archive WS disk.

5 REFERENCE

This section contains the manual pages of the test scripts/procedures implemented.

5.1 xxinsTestClean

�

�xxinsTestClean��

��

�NAME

xxinsTestClean - cleanup all directories for Instrument XXXX

�SYNOPSIS

xxinsTestClean

�DESCRIPTION

This utility deletes all files used by the instrument XXXX.

It must be called if one wants to be sure that the instrument

is really built from scratch.

### generated by docDeroff ###

5.2 xxdTest

�

�xxdTest��

��

�NAME

�� xxdTest - DCS self-test

�SYNOPSIS

�� xxdTest

�DESCRIPTION

�� It performs a complete self-test of each DCS present in the instrument.

�� It particular:

�� 1) It starts DCS up

�� 2) It tests the state transitions:

�� ONLINE --> OFF --> STANDBY --> ONLINE

�� 3) It executes exposures in all main read-out modes

�� 4) It brings the system to STANDBY (for safety reasons)

�� 5) It does a shutdown of DCS

�� 6) It displays the header of the FITS files produced by DCS

�SEE ALSO

�� xxdTestTccd xxdTestFiera xxdTestIrace

### generated by docDeroff ###

5.2.1 xxdTestIrace

�

�xxdTestIrace��

��

�NAME

�� xxdTestIrace - IRACE DCS self-test

�SYNOPSIS

�� xxdTestIrace

�DESCRIPTION

�� It performs a complete self-test of the IRACE DCS

�� It particular:

�� 1) It starts DCS UP

� �2) It tests the state transitions:

�� ONLINE --> OFF --> STANDBY --> ONLINE

�� 3) It executes exposures in all main read-out modes

�� 4) It brings the system to STANDBY (for safety reasons)

�� 5) It perfroms a shutdown of DCS

### generated by docDeroff ###

5.2.2 xxdTestTccd

�

�xxdTestTccd��

��

�NAME

�� xxdTestTccd - TCCD DCS self-test

�SYNOPSIS

�� xxdTestTccd

�DESCRIPTION

�� It performs a complete self-test of the TCCD DCS

�� It particular:

�� 1) It starts DCS UP

�� 2) It tests the state transitions:

�� ONLINE --> OFF --> STANDBY --> ONLINE

�� 3) It executes exposures in all main read-out modes

�� 4) It brings the system to STANDBY (for safety reasons)

�� 5) It perfroms a shutdown of DCS

### generated by docDeroff ###

5.2.3 xxdTestFiera

�

�xxdTestFiera��

��

�NAME

�� xxdTestFiera - FIERA DCS self-test

�SYNOPSIS

�� xxdTestFiera

�DESCRIPTION

�� It performs a complete self-test of the FIERA DCS

�� It particular:

�� 1) It starts DCS UP

�� 2) It executes exposures in all main read-out modes

�� 3) It perfroms a shutdown of DCS

### generated by docDeroff ###

5.3 xxidevTest

�

�xxidevTest��

��

�NAME

�� xxidevTest - xxidev device self-test

�SYNOPSIS

�� xxidevTest

�DESCRIPTION

�� It performs a complete self-test of the yyyy device.

�� It particular:

�� 1) It tests the state transitions:

�� ONLINE --> OFF --> STANDBY --> ONLINE

�� 2) It repeats till all possible device positions have been tested:

�� SETUP + STATUS

�� 3) It brings the system to STANDBY (for safety reasons)

### generated by docDeroff ###

5.4 xxiTest

�

�xxiTest��

��

�NAME

�� xxiTest - ICS self-test

�SYNOPSIS

�� xxiTest

�DESCRIPTION

�� It performs a complete self-test of ICS, using the ic0SelfTest utility.

�SEE ALSO

�� ic0SelfTest

### generated by docDeroff ###

5.5 xxoTest

�

�xxoTest��

��

�NAME

�� xxoTest - OS self-test

�SYNOPSIS

�� xxoTest

�DESCRIPTION

�� It performs a complete self-test of OS

�� It particular:

�� 1) It starts up OS and its sub-systems

�� 2) It tests the state transitions:

�� STANDBY --> ONLINE --> STANDBY --> ONLINE

�� 3) It executes one exposure for each instrument mode

�� 4) It brings the system to STANDBY (for safety reasons)

�� 5) It performs a shutdown of OS and its sub-systems

### generated by docDeroff ###

5.6 xxoTestAlarms

The code and the file do not exist yet. The man page is temporarily replaced with a summary of what the script does.

This is a VLT Sequencer script, which exercises one by one all alarm conditions:

� If the alarm is triggered by hardware conditions (e.g. one switch is activated), it waits for the hardware simulation to be activated.

� If the alarm is triggered by software simulation, it activates the conditions to generate the alarm, waits a few seconds and reset the same conditions.

___oOo___