Approved:

TABLE OF CONTENTS *

1 INTRODUCTION *

2 OVERVIEW *

3 TEST DESCRIPTION *

4 TEST EXECUTION *

5 REFERENCE *

INTRODUCTION

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.

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 italic should be removed.

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

 

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

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

GLOSSARY

No special definition is introduced in this manual

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.

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].

NAMING CONVENTIONS

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

PROBLEM REPORTING/CHANGE REQUEST

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

OVERVIEW

HARDWARE REQUIREMENTS

SOFTWARE REQUIREMENTS

• 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.

TEST DESCRIPTION

DOCUMENTATION

This section describes the documents produced for PAE.

Instrument Software Acceptance Test Plan

It is prepared and reviewed before PAE.

It consists of the present document.

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.

Instrument Software Acceptance Test Report

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

STANDARDS

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

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.

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.

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.

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.

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.

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).

Rules and package for templates (STD007)

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

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.

Users name (STD009)

INSTALLATION

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

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

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

Usage of pkgin to build the Instrument Software (INS002)

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

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.

Installation failures check (INS004)

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

Instrument package for P2PP (INS005)

SUB-SYSTEMS TEST

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

DCS test (DCS001)

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.

ICS special device test (ICS002)

ICS test (ICS003)

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

GRAPHICAL USER INTERFACE

DCS stand-alone GUI (GUI001)

ICS stand-alone GUI (GUI002)

OS Control GUI (GUI003)

OS Status GUI (GUI004)

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

GUIs layout (GUI005)

OS

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

Startup/Shutdown (OS001)

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

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.

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.

MS

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

Technical templates (MS001)

All MS procedures are implemented in form of technical templates.

Exceptions should be justified and agreed upon.

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).

ALARMS

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

Emergency cases (ALM001)

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

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.

Configure alarm conditions (ALM003)

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

DATA FLOW

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

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.

Interface OS-Archive (DFS002)

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: -> xxidevTest "/iser0"	The program executes without errors all what specified in 3.4.2
ICS002	Run: xxidevSelfTest	The program executes without errors all what specified in 3.4.3
ICS003	Run: ic0SelfTest	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 3.5 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.3): 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.4): 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.

 

REFERENCE

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

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 ###

 

xxdTest

xxoTest

xxoTestAlarms