|
|
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: 5
Date: 13/01/2005
Name Date Signature
Prepared: A.Longinotti 13/01/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 |
|
All |
First issue |
|
2 |
|
All |
MAR2002 |
|
3 |
|
All |
APR2003 |
|
4 |
|
1.2 3.9 4.2 |
Added Control Model tests. APR2004 |
|
5 |
|
1.2 3.9 3.10.6 3.4.1 3.4.3 3.4.4 3.6.2 3.6.3 3.7.1 3.10.4 3.10.5 Chapter 4 Chapter 5 |
Added tat tests Examples changed Added reference to document on DFS in the VCM Added TAT001 and VCM006 Updated according to new test scheme (VLTSW20040158) Removed unnecessary manual pages |
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 12
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 AUTOMATIC REGRESSION TESTS 13
3.9.1 Full cycle (TAT001) 13
3.10 VLT CONTROL MODEL 13
3.10.1 Make sure that the Instrument Software is
built from scratch (VCM001) 13
3.10.2 Build the Instrument Software for the VCM
(VCM002) 13
3.10.3 Templates (VCM003) 13
3.10.4 Interface P2PP-BOB (VCM004) 13
3.10.5 Interface OS-Archive (VCM005) 13
3.10.6 Automatic Regression Tests (VCM006) 13
4 TEST EXECUTION 14
4.1 AT THE AIV PREMISES 14
4.2 IN THE VLT CONTROL MODEL 18
5 REFERENCE 19
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 10], 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.
The availability of automatic regression test procedures is
also considered mandatory for all new instruments and their successful
execution is also part of the Software PAE run.
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 |
3.0 |
In preparation |
DICB – Data Interface Control Document |
|
|
VLT-SPE-ESO-10000-0011 |
3 |
In preparation |
VLT Software Requirements Specification |
|
|
VLT-PRO-ESO-10000-0228 |
2 |
In preparation |
VLT Software Programming Standards |
|
|
VLT-PLA-ESO-10000-0441 |
1.0 |
|
VLT Science Operation Plan |
|
|
VLT-MAN-ESO-17210-0667 |
1.2 |
|
Guidelines for VLT applications. |
|
|
VLT-SPE-ESO-17212-0001 |
4 |
|
INS Software Specification |
|
|
VLT-SPE-ESO-17240-0385 |
4 |
|
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 |
|
|
VLT-PLA-ESO-00000-0006 |
3 |
In preparation |
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 |
4 |
|
VLT Common Software Installation Manual |
|
|
VLT-SPE-ESO-17100-3439 |
1 |
In preparation |
Paranal Network/Computers Design Description |
|
|
VLT-MAN-SBI-17210-0001 |
3.7 |
|
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.6 |
|
Motor Engineering Interface User Manual |
|
|
VLT-MAN-ESO-17210-0619 |
2.4 |
|
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 |
5 |
|
Panel Editor User Manual |
|
|
VLT-MAN-ESO-17240-0853 |
3 |
|
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.4 |
|
IRACE-DCS User Manual |
|
|
VLT-MAN-ESO-17240-0934 |
5 |
|
Base ICS User Manual |
|
|
VLT-MAN-ESO-17240-2265 |
4 |
|
Base OS Stub User Manual |
|
|
VLT-MAN-ESO-17240-1913 |
4 |
|
Installation Tool for VLT Sw packages |
|
|
VLT-MAN-ESO-17240-2153 |
4 |
|
Startup Tool Stub User Manual |
|
|
VLT-MAN-ESO-17220-0737 |
3 |
|
HOS – Sequencer User Manual |
|
|
VLT-MAN-ESO-17220-1999 |
4 |
|
Broker for Observation Blocks User Manual |
|
|
VLT-MAN-ESO-13640-1388 |
3 |
|
FIERA CCD Controller Software User Manual |
|
|
VLT-MAN-ESO-17240-2240 |
4 |
|
Common Software for Templates User Manual |
|
|
VLT-MAN-ESO-17240-1973 |
5 |
|
Template Instrument User Manual |
|
|
VLT-MAN-ESO-17240-2606 |
3 |
|
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 for Paranal 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 xxxxmgr
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.
An example is provided in xxmmpe/test/xxmmpeTestDCS.
It must be possible to run the same test under tat
(see [RD 25]).
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 xxmmpe/test/xxmmpeTestICS.
It
must be possible to run the same test under tat (see [RD 25]).
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 xxmmpe/test/xxmmpeTestICS.
It must be
possible to run the same test under tat (see [RD 25]).
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 xxxxmgr
3.6.1 Startup/Shutdown (OS001)
Run the startup/shutdown procedure, based on the stoo package, for the whole instrument.
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 xxmmpe/test/xxmmpeTestOS.
It must be
possible to run the same test under tat (see [RD 25]).
Execute through a
dedicated test
An example is
available in xxmmpe/test/xxmmpeTestTPL.
It
must be possible to run the same test under tat (see [RD 25]).
Purpose is not to verify the scientific
result, but just the technical result.
In particular, the run time of such an
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
3.6.4 Interface P2PP-BOB (OS004)
Verify that the P2PP and the Instrument Package are properly installed on the Observation Handling Workstation.
Define an
For test purposes P2PP can be installed and
started on the Instrument Workstation (see manual page of utilities
inscP2PPClean, inscP2PPInstall and inscP2PPStart)
All tests described in this section must be executed at the AIV premises as user xxxxmgr
3.7.1 Technical templates (MS001)
All MS procedures are implemented in form of technical templates.
Exceptions should be justified and agreed
upon.
An example is
available in xxmmpe/test/xxmmpeTestMS.
It must be possible
to run the same test under tat (see [RD 25]).
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).
All tests described in this section must be executed at the AIV premises 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 AUTOMATIC REGRESSION TESTS
All tests described in this section must be executed at the AIV premises as user xxxxmgr
It must be
possible to verify with an automatic procedure, i.e. with no user interactions,
that the
complete Instrument Software can be rebuilt from scratch, the environments can
be created and started and all sub-systems tests are
performed successfully. This procedure must be based on the VLT standard Tool
for Automatic Tests (tat, see [RD 25]).
An
example is available in xxmmpe/test/TestList.lite
All tests described in this section must be
executed on the VLT Control Model (VCM) in Garching as user xxxxmgr.
3.10.1 Make sure that the Instrument Software is built from scratch (VCM001)
See INS001.
3.10.2 Build the Instrument Software for the VCM (VCM002)
Because of the different hardware available in the VCM, the installation module to be used in xxmgar. Files in this module contains all the definitions characterizing the Garching configuration.
Execute through a
dedicated test
3.10.4 Interface P2PP-BOB (VCM004)
Verify that P2PP
is running on the VCM OH Workstation and OBs can be transferred to BOB (see
instructions under http://websqa.hq.eso.org/tecsw/bin/view/VLTSW/IWSDFSSetup).
3.10.5 Interface OS-Archive (VCM005)
Verify that all FITS files
generated when running an
3.10.6
Automatic Regression Tests (VCM006)
Execute the
automatic regression test procedure (same scope as for 0) for the VCM configuration.
An example is
available in xxmgar/test/TestList.lite
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.
It is assumed
that the installation module for the location where AIV takes place is named
xxmmpe. It must be changed according to the actual AIV location.
|
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 as user xxxxmg: mv $HOME/XXXXSource $HOME/XXXXSource.old mkdir $HOME/XXXXSource cd $HOME/XXXXSource cmmCopy xxmmpe cd xxmmpe/test; make export TARGET=INTEGRATION ../bin/xxmmpeTestClean
|
$INTROOT, $INS_ROOT $VLTDATA/ENVIRONMENTS are empty. $VLTDATA/config/lxx* files do not exist. Same check on DCS SLCUs, if any. |
|
|
INS002 |
Run as user xxxxmgr: cd
$HOME/XXXXSource export TARGET=INTEGRATION pkginBuild
xxmmpe |
No errors from pkginBuild. INTROOT and INS_ROOT contain all files needed to run the instrument software. |
|
|
INS003 |
Check contents of xxmmpe/config/xxmmpeINSTALL.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 does not contain errors. |
|
|
INS005 |
Check contents of $INTROOT/config |
The following files exists: XXXX.zip XXXX_tec.zip |
|
|
DCS001 |
Run as user xxxxmg: cd
$HOME/XXXXSource/xxmmpe/test ../bin/xxmmpeTestDCS |
The script terminates without errors. |
|
|
ICS001 |
Login on the LCU lxxics2: rlogin lxxics2 From the vxWorks shell run: -> lcubootAutoLoadNoAbort 1,”xxidev”,0 -> xxidevTestVx “/iser0” |
The program executes without errors all what specified in 0 |
|
|
ICS002 ICS003 |
Run as user xxxxmg: cd $HOME/XXXXSource/xxmmpe/test ../bin/xxmmpeTestICS |
The program executes without errors all what specified in 3.4.3 and 3.4.4 |
|
|
GUI001 |
Run as user xxxx: xxinsStart –panel TCCD xxinsStart –panel FIERA xxinsStart –panel IRACE xxinsStart –panel TCCD_RTD xxinsStart –panel FIERA_RTD xxinsStart –panel IRACE_RTD |
It is possible to execute all operations described in 0 on each of the DCS panels |
|
|
Run as user xxxx: xxinsStart –panel ICS |
It is possible to execute all operations described in 3.5.2 |
|
|
|
GUI003 |
Run as user xxxx: xxinsStart –panel OS_CONTROL |
It is possible to execute all operations described in 3.5.3 |
|
|
GUI004 |
Run as user xxxx: xxinsStart –panel OS_STATUS |
It is possible to execute all operations described in 3.5.4 |
|
|
GUI005 |
Run as user xxxx: 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 OS002 |
Run as user xxxxmgr: cd
$HOME/XXXXSource/xxmmpe/test ../bin/xxmmpeTestOS |
The script executes without errors all what specified in 3.6.2 Verify that the results are stored in FITS file(s) and check contents. |
|
|
OS003 |
Load from BOB panel the file XXXX_gen_tec_SelfTest.obd Run from BOB panel that Verify that this |
The |
|
|
OS004 |
Start p2pp as user xxxxmgr (see 3.6.4) Build an Fetch the |
The |
|
|
MS001 |
Load from BOB panel the file XXXX_gen_tec_MSTest.obd Run from BOB panel that Verify that this |
The |
|
|
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 as user xxxxmgr: cd
$HOME/XXXXSource/xxmmpe/test ../bin/xxmmpeTestAlarms |
All foreseen software alarms are one by one triggered. Verify that alarms simulated by HW trigger software alarms |
|
|
ALM003 |
Run as user xxxx: xxinsStart –panel ALARM |
It is possible to configure through a GUI alarm conditions |
|
|
TAT001 |
Run as
user xxxxmgr: cd $HOME/XXXXSource/xxmmpe/test export
TARGET=INTEGRATION tat |
PASSED |
|
|
VCM001 |
Run as user xxxxmgr: mkdir –p $HOME/XXXXSource cd $HOME/XXXXSource rm –rf xxmgar cmmCopy xxmgar cd xxins/test; make export TARGET=CM_FULL ../bin/xxmgarTestClean |
$INTROOT, $INS_ROOT $VLTDATA/ENVIRONMENTS are empty. $VLTDATA/config/lxx* files do not exist. Same check on DCS SLCUs, if any. |
|
|
VCM002 |
Run as user xxxxmgr: cd
$HOME/XXXXSource export TARGET=CM_FULL pkginBuild
xxmgar |
No errors from pkginBuild. INTROOT and INS_ROOT contain all files needed to run the instrument software. |
|
|
VCM003 |
Make sure that TCS is online Start the Instrument Software. Run: xxinsStart Load from BOB panel the file XXXX_gen_tec_SelfTest.obd Run from BOB panel that Verify that this |
The |
|
|
VCM004 |
Start p2pp on the OH WS (see 3.10.4). Build an Fetch the |
The |
|
|
VCM005 |
Make sure that the on-line archive is active (see 3.10.5) On the on-line archive WS verify that the
FITS files produced with the last |
The FITS files are on the on-line archive WS disk. |
|
|
VCM006 |
Run: export
TARGET=CM_FULL cd $HOME/XXXXSource/xxmgar/test tat |
PASSED |
|
This section contains the
manual pages of the test scripts/procedures implemented.
Only manual pages providing additional information needed
to properly execute the tests have to be presented here.
___oOo___