|
|
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: 4
Date: 31/03/2004
Name Date Signature
Prepared: A.Longinotti 31/03/2004
Name Date Signature
Approved: K.Wirenstrand
Name Date Signature
Released: M.Cullum
VLT PROGRAMME * TELEPHONE:
(089) 3 20 06-0 * FAX: (089) 3 20 06 514
CHANGE RECORD
|
ISSUE |
DATE |
SECTION/PAGE AFFECTED |
REASON/INITIATION DOCUMENTS/REMARKS |
|
1 |
|
All |
First issue |
|
2 |
|
All |
MAR2002 |
|
3 |
|
All |
APR2003 |
|
4 |
|
1.2 3.9 4.2 |
Added Control Model tests. APR2004 |
TABLE OF CONTENTS
TABLE
OF CONTENTS 3
1 INTRODUCTION 5
1.1 PURPOSE 5
1.2 SCOPE 5
1.3 APPLICABLE DOCUMENTS 5
1.4 REFERENCE DOCUMENTS 6
1.5 ABBREVIATIONS AND ACRONYMS 6
1.6 GLOSSARY 7
1.7 STYLISTIC CONVENTIONS 7
1.7.1 Data Flow and Processor Model Diagrams 7
1.8 NAMING CONVENTIONS 7
1.9 PROBLEM REPORTING/CHANGE REQUEST 7
2 OVERVIEW 8
2.1 HARDWARE REQUIREMENTS 8
2.2 SOFTWARE REQUIREMENTS 8
3 TEST DESCRIPTION 9
3.1 DOCUMENTATION 9
3.1.1 Instrument Software Acceptance Test Plan 9
3.1.2 Instrument Software User and Maintenance
Manual (DOC001) 9
3.1.3 Instrument Software Acceptance Test Report 9
3.2 STANDARDS 9
3.2.1 Programming Standards (STD001) 9
3.2.2 Standard Architecture (STD002) 9
3.2.3 DCS packages (STD003) 9
3.2.4 ICS package (STD004) 9
3.2.5 OS package (STD005) 9
3.2.6 Startup procedures (STD006) 9
3.2.7 Rules and package for templates (STD007) 9
3.2.8 Instrument Configuration files (STD008) 9
3.2.9 Users name (STD009) 10
3.3 INSTALLATION 10
3.3.1 Make sure that the Instrument Software is
built from scratch (INS001) 10
3.3.2 Usage of pkgin to build the Instrument
Software (INS002) 10
3.3.3 Access to cmm Archive (INS003) 10
3.3.4 Installation failures check (INS004) 10
3.3.5 Instrument package for P2PP (INS005) 10
3.4 SUB-SYSTEMS TEST 10
3.4.1 DCS test (DCS001) 10
3.4.2 ICS special device LCU test (ICS001) 10
3.4.3 ICS special device test (ICS002) 11
3.4.4 ICS test
(ICS003) 11
3.5 GRAPHICAL USER INTERFACE 11
3.5.1 DCS stand-alone GUI (GUI001) 11
3.5.2 ICS stand-alone GUI (GUI002) 11
3.5.3 OS Control GUI (GUI003) 11
3.5.4 OS Status GUI (GUI004) 11
3.5.5 GUIs layout (GUI005) 11
3.6 OS 11
3.6.1 Startup/Shutdown (OS001) 12
3.6.2 Single exposure (OS002) 12
3.6.3 Templates (OS003) 12
3.6.4 Interface P2PP-BOB (OS004) 12
3.7 MS 12
3.7.1 Technical templates (MS001) 12
3.7.2 Results format (MS002) 12
3.8 ALARMS 12
3.8.1 Emergency cases (ALM001) 12
3.8.2 Simulate alarms (ALM002) 12
3.8.3 Configure alarm conditions (ALM003) 12
3.9 VLT CONTROL MODEL 12
3.9.1 Make sure that the Instrument Software is
built from scratch (VCM001) 12
3.9.2 Build the Instrument Software for the VCM
(VCM002) 13
3.9.3 Templates (VCM003) 13
3.9.4 Interface P2PP-BOB (VCM004) 13
3.9.5 Interface OS-Archive (VCM005) 13
4 TEST EXECUTION 14
4.1 AT THE AIV PREMISES 14
4.2 IN THE VLT CONTROL MODEL 17
5 REFERENCE 19
5.1 xxinsTestClean 19
5.2 xxdTest 20
5.2.1 xxdTestIrace 21
5.2.2 xxdTestTccd 22
5.2.3 xxdTestFiera 23
5.3 xxidevTest 24
5.4 xxiTest 25
5.5 xxoTest 26
5.6 xxoTestAlarms 27
Purpose of Preliminary Acceptance Europe (PAE) is to verify
the readiness of an instrument, in terms of fulfilling requirements, before
being shipped to
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.
The present document describes all tests foreseen for PAE,
to verify the completeness of the instrument software before shipment to
The Software PAE normally takes place at the location where the instrument has been assembled and integrated.
The execution of a sub-set of the tests also in the VLT
Control Model in Garching, e.g. to verify the interface with TCS or the Data
Flow Software (Archive, Observation Handling Tool), is considered integral part
of the PAE and is mandatory for all new instruments.
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.
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 |
|
GEN-SPE-ESO-19400-0794 |
2.0 |
|
DICB – Data Interface Control Document |
|
|
VLT-SPE-ESO-10000-0011 |
2.0 |
|
VLT Software Requirements Specification |
|
|
VLT-PRO-ESO-10000-0228 |
1.0 |
|
VLT Software Programming Standards |
|
|
VLT-PLA-ESO-10000-0441 |
1.0 |
|
VLT Science Operation Plan |
|
|
VLT-MAN-ESO-17210-0667 |
1.0 |
|
Guidelines for VLT applications. |
|
|
VLT-SPE-ESO-17212-0001 |
2.0 |
|
INS Software Specification |
|
|
VLT-SPE-ESO-17240-0385 |
2.1 |
|
INS Common Software Specification |
|
|
VLT-ICD-ESO-17240-19400 |
2.6 |
|
ICD between VCS and Archive |
|
|
VLT-ICD-ESO-17240-19200 |
1.3 |
|
ICD between VCS and OH |
|
|
TEC-TSW-00/0044 |
Memo |
|
Software
documentation for Instrum. Projects |
|
|
TEC-TSW-00/0045 |
Memo |
|
Rtap policy for Instrumentation Control
Software |
|
|
VLT-PLA-ESO-00000-0006 |
2.0 |
|
VLT Software Management Plan |
The following documents are referenced in this document.
|
Reference |
Document Number |
Issue |
Date |
Title |
|
VLT-MAN-ESO-17200-0888 |
1.0 |
|
VLT Common Software Overview |
|
|
VLT-MAN-ESO-17200-0642 |
2 |
|
VLT Common Software Installation Manual |
|
|
VLT-SPE-ESO-17120-1355 |
1.2 |
|
Final Lay-out of VLT Control LANs |
|
|
VLT-MAN-SBI-17210-0001 |
3.6 |
|
LCU Common Software User Manual |
|
|
VLT-MAN-ESO-17210-0600 |
1.7 |
|
Motor Control sw User Manual API/ACI |
|
|
VLT-MAN-ESO-17210-0669 |
1.4 |
|
Motor Engineering Interface User Manual |
|
|
VLT-MAN-ESO-17210-0619 |
2.2 |
|
Central Control Software User Manual |
|
|
VLT-MAN-ESO-17210-0707 |
1.6 |
|
On Line Database Loader User Manual |
|
|
VLT-MAN-ESO-17210-0771 |
1.8 |
|
EVH User Manual |
|
|
VLT-MAN-ESO-17210-0770 |
1.8 |
|
Extended CCS User Manual |
|
|
VLT-MAN-ESO-17210-0690 |
4.3 |
|
Panel Editor User Manual |
|
|
VLT-MAN-ESO-17240-0853 |
1.4 |
|
INS Common sw – oslx User Manual |
|
|
VLT-MAN-ESO-17240-0672 |
1.6 |
|
CCD Detectors Control Software User Manual |
|
|
VLT-MAN-ESO-14100-1878 |
1.1 |
|
IRACE-DCS User Manual |
|
|
VLT-MAN-ESO-17240-0934 |
3 |
|
Base ICS User Manual |
|
|
VLT-MAN-ESO-17240-2265 |
1.1 |
|
Base OS Stub User Manual |
|
|
VLT-MAN-ESO-17240-1913 |
2 |
|
Installation Tool for VLT Sw packages |
|
|
VLT-MAN-ESO-17240-2153 |
2 |
|
Startup Tool Stub User Manual |
|
|
VLT-MAN-ESO-17220-0737 |
3 |
|
HOS – Sequencer User Manual |
|
|
VLT-MAN-ESO-17220-1999 |
2 |
|
Broker for Observation Blocks User Manual |
|
|
VLT-MAN-ESO-13640-1388 |
1.2 |
|
FIERA CCD Controller Software User Manual |
|
|
VLT-MAN-ESO-17240-2240 |
2 |
|
Common Software for Templates User Manual |
|
|
VLT-MAN-ESO-17240-1973 |
3 |
|
Template Instrument User Manual |
|
|
VLT-MAN-ESO-17240-2606 |
2 |
|
Base ICS GUI User Manual |
|
|
VLT-MAN-ESO_17200-0908 |
1.4 |
|
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:
|
AIV |
Assembly Integration and Verification |
|
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 |
|
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 |
|
P2PP |
Phase 2 Proposal Preparation |
|
RAM |
Random Access Memory |
|
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) |
|
VCM |
VLT Control Model |
|
VLT |
Very Large Telescope |
|
VLTI |
VLT Interferometer |
|
VME |
Versa Module Eurocard |
|
WS |
Workstation |
No special definition is introduced in this manual
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].
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.
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.
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
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.
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.
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.
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 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 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.
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
All tests described in this section must be
executed at the AIV premises as user xxxxmgr
3.3.1 Make sure that the Instrument Software is built 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.zip (observations) and XXXX_tec.zip (maintenance), as defined by P2PP, are produced and placed in $INTROOT/config.
All tests described in this section must be
executed at the AIV premises as user xxxx
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 device LCU test (ICS001)
Run for each ICS special 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
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
All tests described in this section must be executed at the AIV premises as user xxxx
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
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).
The OS Status GUI shows the detailed status of the whole instrument and its devices.
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.
All tests described in this section must be executed at the AIV premises as user xxxx