CHANGE RECORD
|
Issue
|
Date
|
Affected
Paragraphs(s)
|
Reason/Initiation/Remarks
|
|
1
|
2003/01/01
|
all
|
First draft
|
|
|
2003/01/09
|
All
|
Some refinement
|
|
|
2003/03/03
|
many
|
Integrated comments from ALO
|
|
|
2004/04/30
|
8; Annex 2
|
Merge tat-eccs; removed Annex 2
|
TABLE OF CONTENTS
1. SCOPE AND PURPOSE............................................................................................................................................................... 4
1.1 Reference Documents................................................................................................................................................................. 4
1.2 List of Abbreviations/Acronyms................................................................................................................................................ 5
2. Getting started........................................................................................................................................................................ 5
2.1 Contact persons for trouble-shooting
and questions......................................................................................................... 5
2.2 Useful web pages and machines to be
used for development........................................................................................ 6
3. ENVIRONment: PECS (Pluggable
Environment Contribution System)............................................... 6
3.1 Setting up the user environment.............................................................................................................................................. 6
3.2 Dealing with pecs......................................................................................................................................................................... 6
4. directory structure............................................................................................................................................................ 9
4.1 MODROOT..................................................................................................................................................................................... 9
4.1.1 Definition of a module......................................................................................................................................................... 9
4.1.2 Module name...................................................................................................................................................................... 10
4.2 INTROOT....................................................................................................................................................................................... 10
5. CMM (Configuration Management
Module)........................................................................................................ 11
5.1 Some useful cmm commands................................................................................................................................................ 12
5.2 Working with branches............................................................................................................................................................. 13
6. Makefile and programming standards............................................................................................................... 14
6.1 System wide make definitions:
vltMakefile......................................................................................................................... 14
6.2 Software module Makefile........................................................................................................................................................ 15
6.3 Programming standards........................................................................................................................................................... 15
7. Dealing with real-time environMEnts:
vcc........................................................................................................ 16
8. tools for automated testing (TAT).......................................................................................................................... 17
8.1 Overview......................................................................................................................................................................................... 17
8.2 Limitations.................................................................................................................................................................................... 17
8.3 How TAT works........................................................................................................................................................................... 17
8.4 Cookbook....................................................................................................................................................................................... 19
8.5 Commands to remember.......................................................................................................................................................... 21
8.6 Some additional features.......................................................................................................................................................... 21
8.6.1 Logfiles.................................................................................................................................................................................. 21
8.6.2 How to filter the test output............................................................................................................................................ 21
8.6.3 Advanced features: eccsTestDriver.............................................................................................................................. 22
9. Software Problem Report (SPR) system........................................................................................................... 22
9.1 Overview......................................................................................................................................................................................... 22
9.2 Login into the system................................................................................................................................................................ 22
9.3 Submitting an SPR.................................................................................................................................................................... 22
9.4 Querying the system................................................................................................................................................................. 23
9.5 Changing the login password.................................................................................................................................................. 23
9.6 VLT SPR System workflow..................................................................................................................................................... 23
10. documentation......................................................................................................................................................................... 26
10.1 Comments inside the code................................................................................................................................................. 26
10.2 Header of each source files to generate man pages................................................................................................... 26
10.3 ChangeLog............................................................................................................................................................................... 26
10.4 Release Notes........................................................................................................................................................................ 26
10.5 Manuals.................................................................................................................................................................................... 27
10.5.1 Note about the issue number and the cmm version of the
document............................................................... 27
10.6 Procedure to get a DOC ID................................................................................................................................................. 27
10.7 Procedure to submit a finished document to the Archive.......................................................................................... 28
Annex 1: VLT Directory Structure................................................................................................................................ 29
Annex 2: Document types and PSCs......................................................................................................................... 40
This document gives an
overview of the basic tools and methods used at ESO-Garching
as well as at the Observatories to develop and maintain software within the VLT
software project. It is addressed to all people at ESO and consortia who start
working for the first time with the VLT software but the document can also be
useful for people who already have little or good experience in working within
this project.
These are the topics that
will be discussed in the following chapters:
- getting started: preparing the UNIX account
- environment
- directory structures
- version control
- Makefile and programming standards
- dealing with real-time environments
- tools for automated testing
- software problem report system
- documentation
Note that examples and practical cases are referred
to the development environment as it is at the head-quarter in Garching. Further extension of the present document can be
foreseen to include the other ESO sites. Consortia will maintain their own site
policy with regard to desktop configuration, accounts, mailing lists
definitions. In Chapter 2 some information are ESO (and Garching)
specific, but the rest of the manual can be followed at whatever site and
consortium.
The developing environment
is UNIX-based (in particular, we develop on HP-UX, SUN-Solaris and Linux
Red-Hat). In what follows, we take for granted a basic knowledge of the UNIX
operating system.
At ESO-Garching,
every developer will receive a PC with all the usual Microsoft tools (and many
others…) and the possibility to connect to the UNIX machines via X-server (the
standard product used is Starnet X-Win32).
[1]
VLT Software Programming Standard VLT-PRO-ESO-10000-0228
ftp://ftp.eso.org/pub/vlt/vlt/pub/add-doc/VLT-PRO-ESO-10000-0228.pdf
[2] Configuration Management User Manual VLT-MAN-ESO-17200-0780 ftp://ftp.eso.org/pub/vlt/vlt/pub/releases/MAR2002/doc/vol-1b/VLT-MAN-ESO-17200-0780.pdf
[3]
Introduction to VLT User and Programming Environment LSO-MAN-ESO-80060-0001
[4]
VLT Software Environments Common Configuration VLT-MAN-ESO-17210-0855 http://www.eso.org/projects/vlt/sw-dev/wwwdoc/MAR2001/VLT-MAN-ESO-17210-0855/Output/FronCoverNew.html
[5] Tools for Automated Testing User Manual VLT-MAN-ESO-17200-0908 http://www.eso.org/projects/vlt/sw-dev/wwwdoc/MAR2001/VLT-MAN-ESO-17200-0908/Output/FrontCoverNew.html
[6]
VLT Common Software – Overview VLT-MAN-ESO-17200-0888 http://www.eso.org/projects/vlt/sw-dev/wwwdoc/MAR2001/VLT-MAN-ESO-17200-0888/Output/FrontCoverNew.html
[7]
VLT Software Management Plan VLT-PLA-ESO-00000-0006
ftp://ftp.eso.org/pub/vlt/vlt/pub/add-doc/VLT-PLA-ESO-00000-0006.pdf
CCS Central Control Software
CMM Configuration
Management Module
ESO European Southern Observatory
LCU Local Control Unit
PC Personal Computer
PECS Pluggable
Environment Contribution System
PSC Product Structure Code
SCCB Software Configuration Control Board
SE Software Engineering
SPR Software Problem Report
SW Software
TAT Tools for Automated Testing
VCC VLT Central Configuration
VLT Very Large Telescope
WS Workstation
The first step is to obtain
a UNIX account. Normally your supervisor should take care of asking to the
system administrators the creation of such an account. What follows is specific
to ESO.
The standard format for the
username is: first letter of the first name + family name up to 7 letters.
Example: for John Smith it
will be jsmith, for Peter Forester it will be pforeste and so on.
Your e-mail account will be
of the type: <username>@eso.org
Be aware that there are
mailing lists to ease the communication among the group. The first one you
should belong to is gar-tecsoft@eso.org.
Ask your supervisor for being added to this mailing list and any other
important one. At Paranal, the correspondent mailing
list is: par-vltsoft@eso.org, at La Silla: ls-vltsoft@eso.org
.
There are also other tools
used within the group for communication purposes, like Yahoo Messenger, that
should be already installed on your PC. (Note: the usernames on Yahoo can not
always be compliant with the naming standards).
Within the TEC Division
Software Group, the UNIX machines are administrated by vltmgr.
For any problems concerning your account, environment, UNIX matters, home
directory etc. send a mail to vltmgr@eso.org
(or dial 6421). He can also help you in setting up your workstation at the very
beginning, for example to configure the X-server.
For any problem or question
concerning cmm, SPR system, (see later in the
document) VLTSW in general, contact vltsccm@eso.org.
For any other problem
different from the above or out of the scope of our system administrators and vltsccm, contact the helpdesk: helpdesk@eso.org or dial 6333.
The entry point for many
issues concerning the work with the VLTSW can be found at:
http://www.eso.org/projects/vlt/sw-dev/
From this point you can
access, among others,
-
the documentation kit
delivered with the VLTSW (take care of referring to the latest release)
-
the Release Notes
(click on “VLT Common Software”)
-
some procedures you
will have to deal with sooner or later when working in our group (click on
“Procedures”)
Another important link is
“Machine survey” (http://www.eso.org/projects/vlt/sw-dev/admin/vltsw-installed-machines.html).
This page gives you the list of the machines available in Garching,
with their basic characteristics (operative system, version, which VLTSW has
been installed and when). The integration machines are reserved to the
integration group; the others are available for the development. The web page
gives also information about the latest VLTSW installation (which version,
which date and so on.)
The home directories of the
users are NFS exported, so they are accessible from each of the machines listed
in the web page.
You should configure your
X-Server to reach one or more of the development machines in the list.
3.
ENVIRONment: PECS (Pluggable Environment Contribution System)
The user environment is
supplied with a software developed in-house called PECS and based on bash (which is the default shell for every user).
The first time you log into
a machine you should prepare your user in order to have all the environment
variables, needed to work with the VLTSW, available. (It can happen that the
system administrator already prepared your account for you, just check for the
existence of the directory $HOME/.pecs; if it exists,
you don’t need to repeat the steps described below).
Once you are logged into the
machine, execute the following (the script will ask for some values, just
accept the default):
$ /etc/pecs/bin/pecssh mklinks –i
PECS_ROOTDIR
[/etc/pecs]: "<CR>"
PECS_RELEASE
[000]: "<CR>"
[...]
Do you wish
to install VUE support files? [y]: "n"
Logout and login again (if
you are using the CDE, exit and re-login).
Thanks to PECS you will get a set of standard environment variables
and you do not need to source any file or doing any manual additional step.
Only if you are enough experienced with the system and need to change some of
the standard values or add new environment variables, you will have to edit the
files in the directory $HOME/.pecs, which should exist
and contain (comments-only) example files.
PECS supports personal settings for the following types
of settings:
- environment
variables (type=env)
- X resources (type=xrdb)
- GUI root window menu items (type=wmrc)
- shell
aliases (type=ali)
The
‘application-scope’ of the setting can be:
- apps:
the setting is related to a specific application, or project like the VLT
project (e.g. VLTROOT, INTROOT, GNU_ROOT, NOCCS, RTAP_EXISTS)
- misc: any other type of setting (NNTPSERVER, LESS, MAIL, PATH=$HOME/bin:$PATH).
The 'host-scope' of the setting can be:
- applicable only on certain hosts (host-scope=<name-of-host>)
- applicable on all hosts
(host-scope=all)
Once you have decided the three
attributes 'type', 'application-scope' and 'host-scope' the right file where to
put the setting is:
~/.pecs/<application-scope>-<host-scope>.<type>
e. g.: to change your VLTROOT and to have the new
value on all the machines you log into set VLTROOT in ~/.pecs/apps-all.env
with the command:
export
VLTROOT=<path to the new vltroot>
To activate the change the
general procedure is to run:
make_xdefaults
then log out and back in. But
this can vary according to the type of change you made. For example, make_xdefaults has to be run for non-GUI logins only, because for CDE (or VUE) logins, the Xdefaults are automatically updated with the login
procedure.
Let's look at few examples;
consider each of the following settings, look at the values it
has for each attribute, and see the name of the file it goes
in.
Example #1:
changing VLTROOT
Suppose you're working on a machine where VLTROOT is set to
/vlt/MAR2001/CCS, and you need to point it at FEB2000 instead just for a quick
test. Well,
-
it's an environment
variable (type=env)
-
it relates to VLTSW,
which is a PECS-aware application (application-scope=apps)
-
you only need it for a quick
test on host 'te13' (host-scope=te13)
So, having worked that out, the setting belongs in the file:
~/.pecs/apps-te13.env
So, in the file you just put:
export VLTROOT=/vlt/FEB2000/CCS
To activate the setting, it
is enough to log out and back in. Opening another xterm
should also work.
Example #2:
the 'which' alias
The 'which' command under Bourne-like shells does not work quite the
same as it did under Tcsh. Under Bash, the nearest
equivalent to 'which' is 'type' or 'type -all'. So to make 'which' an alias for
'type -all':
-
it's a shell alias
(type=ali)
-
it's not related to a
PECS-aware application, it's just personal setting (application-scope=misc)
-
you want it everywhere
(host-scope=all)
So, having worked that out, the setting belongs in the file:
~/.pecs/misc-all.ali
So, in the file you just put:
alias which='type -all'
Aliases are read per-shell-process, so it is not necessary to log out;
your next new xterm will see the alias.
Note that Bash aliases have an '=' between the alias and its value,
unlike Tcsh.
Example #3:
you want to add 'top' and 'xv' to your 'User Menu'
PECS provides a GUI root window sub-menu entitled 'User
Menu'. Suppose you want to create the menu to contain the command
'top'
-
it's a GUI root window
menu item (type=wmrc)
-
it's not related to a
PECS-aware application (the user menu never is) (application-scope=misc)
-
you want to see this
menu everywhere (host-scope=all)
So, having worked that out, the setting belongs in the file:
~/.pecs/misc-all.wmrc
So, in the file you put:
Menu user_menu
{
"My
Menu" f.title
"Top"
f.exec "xterm -T top
-n top -e top"
"Xv"
f.exec "xv"
}
Note that 'top' isn't on all systems, so simply
calling 'top' is a bit naive.
To activate the settings select 'Restart' from the GUI root window menu.
Example #4:
you don't like the Xclock updating every second
PECS allows you to specify new values for X resources,
but it also allows you to 'unset' existing ones (this is not a standard behaviour of X).
You will probably find your Xclocks showing a
second hand, because of the X resource:
XClock*update: 1
To cancel this setting, just provide a blank value for it. So,
-
it's an X resource
(type=xrdb)
-
it's related to a
PECS-aware application (yes, this resource is defined by VLTSW) (application-scope=apps)
-
you want to see this
menu everywhere (host-scope=all)
So, having worked that out, the setting belongs in the file:
~/.pecs/apps-all.xrdb
So, in the file you put:
XClock*update:
To activate the change you need to log out and log in again.
Example #5:
how to write a function. You don't like to use
"export
VARIABLE=VALUE"
and you
want to keep using
"setenv VARIABLE VALUE"
Very bad
idea, but if you are so obstinate, you should write a function, because aliases
which require embedded parameters must be written as functions, but should
still be put in the ".ali" file. Here's an
example:
export_function()
{
export
$1=$2
}
alias
setenv=export_function
To ease the work of the
developers, a pre-defined set of standard directories can be created using a
simple command:
$ getTemplate
This is an interactive
utility which provides templates for many different purposes. In this case we
are interested in choosing the option “directoryStructure”.
Then a choice among
different types of directory structures is proposed. Basically you will be
interested in using two types:
- MODROOT (that can be WS type only, LCU type only or
both WS and LCU according to the type of code you have to develop) and
- INTROOT (integration area where the developed code get
installed after running “make install”)
Another important area is
called VLTROOT. The directory structure is basically the same as for the
INTROOT (a part from the Source directory) but the meaning of the area is different:
the VLTROOT is the repository for the entire VLT software. There, all the VLT
libraries, applications and programs are installed and available for every
user, who can access that area through the environment variable $VLTROOT
($VLTROOT/bin is automatically added to the PATH). Only the responsible persons
for the preparation of the VLTSW release can create and populate a VLTROOT.
This is done using the software checked into the archive and tested, basically
the software “released” to the community of developers. The ownership and
permission of the files into the VLTROOT should not allow other users different
from the integrator users or vltmgr (who performs the
installations) to modify that area.
MODROOT and INTROOT are
instead totally handled by each developer, who can create and populate them or
delete them.
The usual location for a MODROOT
is the user home directory. Each MODROOT corresponds to a software module
containing a set of standard subdirectories. A very good definition and explanation
of “module” can be found in [1] chapter 2. For sake of simplicity, we repeat here
some basic concepts.
A software module is a piece
of software (code and documentation) able to perform functions and having an
interface available to an external user to access the functions provided.
Technically
a module is a way to organize functions in homogeneous groups. The interface
hides the implementation and system dependencies from the user.
Managerially
the module is the basic unit for planning, project control and configuration
control.
There is no rule to define how
big a module shall be. Common sense and programming experience should be enough
to identify what can be gathered and treated as a unique item. Examples of
modules are: a driver for a specific board (the driver itself, install utility,
configuration data files, etc.), the message system of CCS (Central Control
Software, see document VLT-MAN-ESO-17210-0619 at the web page http://www.eso.org/projects/vlt/sw-dev/wwwdoc/MAR2002/dockit.html
to know more) which contains library,
utility for debug and display, etc., the sequencer (sequence interpreter,
editor, etc.) (see http://www.eso.org/projects/vlt/sw-dev/wwwdoc/MAR2002/VLT-MAN-ESO-17220-0737/Output/FrontCover.html
if you need to know more about the sequencer; this link refers to the MAR2002
release who was ready at the time this document was written; if you want a more
recent revision of the document, start from http://www.eso.org/projects/vlt/sw-dev/
and choose the appropriate release!).
Each module is identified by
a name. The module name length can be minimum 2, maximum 6, suggested 4
characters (a-z, 0-9) and shall be unique in the VLT project. Names equal or
too similar to UNIX names shall be avoided. The case cannot be used to build
different names, i. e. the following are referring to
the same module: xyz, XYZ, xYz.
The module name is used in
the naming of all elements that belong to the software module according to the
rules stated in [1] section 3. The usage of the module name in
uppercase/lowercase depends on the type of element: file, procedure, type, etc.
The module name is defined
during the design phase. In the Design Review the proposed names are checked
against the existing names and, if ok, accepted.
Once a MODROOT has been
created with getTemplate you will work under the
different directories of the MODROOT, keeping or removing what is not needed.
Be aware that some directories are mandatory:
src
is the directory where you will be putting the sources you are working on
include is
the directory where you will be putting the “.h” files
lib is
where the libraries get installed (after running “make all”)
bin is
where the binaries get installed (after running “make all”)
idl
is for the Interface Definition language files
man is for
the man pages (they are installed after running “make man”)
object is
where the dependencies files get installed (when running “make all”)
doc is for
other automatic generated (again with “make
man”) documentation (for example, .text
files to be imported in WORD documents)
test is
where the test source code has to be put
Refer to [1] to have a complete overview about the way of working
with modules and in particular chapter 3 of [1] for the Naming Conventions for the files belonging to
the modules.
The INTROOT is a set of
directories (among others: bin, lib and include) where all the software written
under MODROOT/src (binaries, libraries, include files
…) gets installed when running make
install (libraries, binaries, includes
etc. are copied from the MODROOT to the INTROOT).
The usual location for the
INTROOT is /introot/<username>. This path
should be passed to the program “getTemplate”, after choosing the options “directoryStructure” -> “createINTROOTarea”.
Then the variable $INTROOT
must be made available to the user environment. As we saw in chapter 3, you should write in one of your startup files under
$HOME/.pecs the line:
export INTROOT=/introot/<username>
and log out and in
again.
Other information can be
found in Annex 1: VLT
Directory Structure. The same information is also accessible running
$ man vltDirectoryStructure
Once the files are installed
in the INTROOT and the user has defined the INTROOT in his set of environment
variables, the files (binaries, libraries etc.) in the INTROOT have precedence
on the corresponding files in the VLTROOT. The PECS takes care of redefining the PATH for the binaries
and the LD_LIBRARY_PATH (on Sun and Linux) or the SHLIB_PATH (on HP) for the
libraries in order to have first the INTROOT and then the VLTROOT.
Remark: according
to the policy adopted in Garching, the users home
directories are NFS exported, so if the MODROOT is under the user’s home
directory, it will be seen from any machine, no matter the operative system, of
the pool of machines listed in http://www.eso.org/projects/vlt/sw-dev/admin/vltsw-installed-machines.html
The INTROOT is, on the
contrary, always local to a machine. You can have an INTROOT on te16 but not on
te35 and so on. If you want an INTROOT on all the machines, you will have to
create it using getTemplate on each of the desired
machine and define the environment variable $INTROOT accordingly (basically in
the file ~/.pecs/apps-all.env
or ~/.pecs/apps-<hostname>.env).
The
cmm software has been developed to store all the
software produced in a centralized location, to make this software available
and easily accessible to all developers in the group, to keep track of any
modification performed and of the history for every software module.
To
use the cmm software and access the archive (where
all the software modules are stored) you need to have an access keyword. Just
send a mail to vltsccm@eso.org.
Once
you received the keyword, you have to create a file $HOME/.cmmrc
and write inside the record:
<your_username> keyword
Then
you can start using cmm.
Basically
you will have to produce some software, organized in a software module called,
for instance, mod1. When you begin working to a new software module, it
does not exist yet in the cmm archive. You will need again the help of vltsccm to create mod1. In this case
you have to provide vltsccm with the following
information:
- name of
the module (please refer to [1] for the module name conventions)
- type:
software module or document. In case of a software module you can also
specify, if you want, whether it is a ws only, lcu only or both ws and lcu module
- responsible
person for that module
- short
description (one line)
(All
this information is stored in a file maintained by vltsccm
and can be accessed through the UNIX utility mod.)
Once
the module has been created, you can retrieve it from the archive running:
$ cmmModify mod1
It
will be an empty directory structure as we saw in 4
Then
you start developing and populating your module. When you are satisfied with
your software, it means that
-
it works and
-
it has been accordingly tested and
-
a repeatable test suite has been produced
-
as well as all the necessary documentation,
you
will have to archive the module in the cmm archive. First
run:
$ cd mod1/src
$ make clean_dist (if
applicable)
$ cd ../..
$ cmmCheckForArchive mod1
This
utility helps you in checking that the module is OK before archiving it (no
backup files are present, the ChangeLog has been
modified, no files have been forgotten under the object directory etc.)
It
is very important to always run “make
clean_dist” and cmmCheckForArchive before
actually archiving a module.
When
everything is OK and mod1 has passed the check, to actually archive the module
in the archive run:
$ cmmArchive mod1 <reason> <version>
<reason>
should be a short comment explaining briefly the modification you performed.
<version>
can be explicitly indicated. All the modules are created with version 0.0. If
you do not indicate another number (that must be higher than 0.0) the module
will be archived with the minor number automatically increased of 1 unit, i.e.
as 0.1. With the option <version> you can decide when to change the major
number (normally after a major change into the software).
To
know more about cmm, refer to [2].
Important
remark
The policy for
working with cmm is that:
only the
responsible person for a module can run cmmModify and
cmmArchive on that module, unless explicitly agreed
otherwise by the module responsible person together with the developer.
Here
follows a short description of other cmm commands
(credit [3]). Similar information can be obtained using the man
pages for each command.
cmmHistory mod1
This
command prints to the standard output the history of a software module.
cmmLast mod1
This
command lets you obtain the number of the latest version of a module. If you
omit the name of the module, you will get the number of the latest versions of
all modules existents into the archive.
cmmCopy mod1 <version>
This
command will give you a read only copy of the version specified of a software
module without locking the module (others developers will be able to run cmmCopy or cmmModify on that
module).
cmmCancel mod1
This
command cancels a modification made in a software module and restores the last
version saved into the archive. This command will prompt you asking whether to
delete your local copy of the module or not.
cmmCompare mod1 <new version> <old version>
This
command allows you to compare two versions of a module and to display the
changes between both versions.
If
you want to experiment with cmm, you can use a module
call “dummy” where you
can do all the mess you like!
It
is possible for a module to have a tree of versions instead of one single
trunk. Without branching, each file version has only one descendant, the next
version. With branching, each file version may have several descendants.
only one branch branches
2.57
2.57
2.58 2.58 2.57.1.1 2.57.2.1
There
is always one branch called the (main) trunk: in the above example, version
2.57 and 2.58 belong to the main trunk. But version 2.57.1.1 belongs to branch
2.57.1 and version 2.57.2.1 belongs to branch 2.57.2. Branches allow parallel
development and especially urgent bug fixing. It is nevertheless good practice
to deliver to the integration group a module archived in the main trunk. If
branches exist, they should be merged into the main trunk software as soon as
possible. (Note that this requires some manual work, cmm
does not provide an automatic way for merging branches to the main trunk.)
The
commands to be issued to work with branches are:
cmmBranch mod1 <version>
This
command creates a writable copy of the module mod1 in the current directory. If
the retrieved version is, for instance, 2.57 the branch 2.57.1 will be created
and once the module is archived, it will get the version 2.57.1.1. From that
point on, any further modification to the branch and archiving will increase
the fourth digit of 1 unit.
Example:
cmmBranch mod1 2.57
=> I create the branch 2.57.1
The
next time I want to create a branch from the trunk version 2.57, I will run
again:
cmmBranch mod1 2.57 => I create the branch 2.57.2
and so on.
cmmArchiveBranch mod1 <reason>
This
command checks in a module after the creation of a branch.
Remark: once the
branch has been created and archived the first time, any other modification to
that branch have to be issued with the usual command cmmModify and cmmArchive; the only
difference with working with the main trunk is that in case of a branch with cmmModify you must
specify the branch id, in the example 2.57.1, or 2.57.2 and so on.
So,
for instance, with cmmBranch I created
2.57.1. Then I archive this branch with cmmArchiveBranch: I get in the
cmm archive the version 2.57.1.1. When I want to go
on with the modification on that branch I will run:
cmmModify mod1 2.57.1
I
do my modification then I archive with
cmmArchive mod1 <reason>
and
I will have into the archive the version 2.57.1.2, and so on.
cmmCancelBranch mod1
This
command allows you to cancel the corresponding cmmBranch mod1 request. Nothing is archived, no
branches are created and the user module directory is deleted.
cmmCloseBranch mod1 <reason> <branch id>
This
command allows you to close a module branch. Once this command is issued, no
other modifications are allowed to the corresponding branch. It is also
possible to forbid any modification
on the specify module (on the main trunk). In this case, specify as <branch
id> the value “all”.
An example of when branching
should be used is when a SPR (see Chapter 9) is issued, reporting a severe bug in a module after
a major VLTSW release. If meanwhile the main trunk of that module has been
modified e.g. to implement pending Change Requests, it becomes necessary to
create a branch starting from the module version contained in the VLTSW
release, to avoid mixing up the urgent bug fixing with the new features (and
possibly new bugs) meanwhile implemented in the main trunk.
Because of the nature of a
branch, it is a good practice not to leave a branch open for too long time. The
branch should be open for making the fix, archive the fix and that’s it.
To grant homogeneity in the
development of the software for the VLT project, the GNU make must be used at
every site or consortium.
This is by default the case on any system installed
according to the VLT standards.
A wide set of make
definitions have been coded and made available through a file called “vltMakefile” (see 6.1).
Analogously, every developer
should provide the src directory of its software
module with a Makefile (see 6.2) where he will indicate the actions to be taken when
running “make all man install”. This Makefile has to be
created starting from the utility “getTemplate” and choosing “code” and then “Makefile_for_WS” (if the code to be produced has to run on a UNIX
workstation) or “Makefile_for_LCU” (if the code has to be produced using the VxWorks cross compiler).
The module Makefile must include the vltMakefile.
(The template contains the adequate instruction).
The vltMakefile
sets common definitions that are valid for the whole VLT software. It also
finds out on which platform and which operating system the software is being
built on and sets variables accordingly.
In addition, vltMakefile provides a set of activities normally required by
every module (generation of automatic dependencies, clean, man pages, install).
It knows hot to deal with source code in any of the VLT standard languages (see
6.3). The scope of such standard actions is controlled by
the calling Makefile via a set of variables (see 6.2).
The variables set by vltMakefile depend on the value of some shell-environment
variables (see the ENVIRONMENT section in the man pages) and on the operating system
(type and version). Make defaults can apply as well.
By default vltMakefile works for UNIX files. If the variable MAKE_VXWORKS
is defined, vltMakefile works to produce VxWorks applications. (You will find this variable already
defined in the Makefile_for_LCU obtained from getTemplate).
To know in detail all the
definitions it provides, please refer to the man pages:
$ man vltMakefile
Recently, extensions of
the vltMakefile to include new programming languages
like java have been performed. To know how the java implementation works refer
to:
$ man javaMakefile
To know the structure and
use of the Makefile, please refer to the man pages:
$ man Makefile
Again the starting point is
the utility getTemplate with the option “code”.
After this choice, a set of
templates are available per each type of supported programming language. Among
others:
-
c-main
-
c-procedure
-
h-file
-
c++-file
-
c++-small-main
-
c++-class-file
-
c++-h-file
-
dbl-file
-
java-file
-
script
-
tclScript
Every time you have to write
a new piece of code, start from one of the templates. Some more information
about the standards to be followed can be found in [1].
Note that the initial part
of the template for source files is the so called header and has to be
carefully filled in. This part will be used to generate the man pages for the
corresponding program. It consists of a series of sections. NAME, SYNOPSIS and
DESCRIPTION sections are always present and mandatory. Depending on the type of
file, other sections are present, some mandatory and others optional.
Furthermore, on a module basis, other sections can be added according to
specific needs. Should this happened, it shall be stated in the Software Design
Documentation.
If any mandatory section is
empty, its header is kept with one of the following: “Not Applicable” or
“None”.
If any optional section is
empty, its header is omitted.
Remark: the one-line
description under the NAME section should contain the essential keywords to
identify the functionality performed because the apropos searching feature
is based on such keywords.
It is a good practice to
document the changes performed on each file belonging to a module. For this,
besides the header, every developer who worked at the file should add a line
like the following:
# who when what
# -------- ----------
----------------------------------------------
# gfilippi 1993-07-08 created
# gfilippi 1997-04-23 support <lib>_LDFLAGS for libraries
# eallaert
1999-03-16 use -Xlinker options for sharedLibName
# rschmutz
1999-04-03 use $CC instead of gcc
# mzampare
2001-12-03 added support for
library-specific libraries
in the initial part of the
file.
A real-time environment,
briefly environment (not to be confused with the user environment corresponding
to the set of environment variables) is a set of processes that can be run on
different units, WSs or LCUs,
local or remote and can mutually communicate exchanging messages.
Every environment is
identified with a unique name and consists of a set of configuration files that
have to be stored in a standard location, basically
$VLTDATA/ENVIRONMENTS/<name_of_the _environment>
The environment can be of
two types:
-
Workstation environment
CCSLite
-
LCU environment
A third type for the
workstation environments, called “Full CCS” and based on the commercial product
RTAP has been deprecated starting with the APR2003 VLTSW release.
To know more about the
naming convention and characteristics of the environments, please refer to [4].
To identify an environment,
information about the network, the name of the machine where the environment
will run, the IP address of the machine and so on is also needed.
This information is stored
in a configuration database based on mini-sql. Only
one database is necessary to store the information for the whole network.
Basically, one machine within a pool of machines on the same network will
receive this database. From any other machine, one can refer to the configuration
database’s machine using the environment variable $ACC_HOST. This variable is
automatically set by PECS. The database is actually a file called accData.sql and put under the path $VLTDATA/msql.
A tool has been developed in
house, called vcc to create, initialize, start, stop
and delete environments. Here follows a quick reference about the most
important commands supplied with vcc. Please refer
also to [4] for a more detailed explanation and to the on-line
documentation (man pages). Note also that the commands are different whether
the ACC_HOST and the configuration database are used or not. In the former case,
the command can be called passing the name of the environment only, other
arguments are not needed.
vccEnvCreate –e <environment_name>
This command will create the
environment directory under $VLTDATA/ENVIRONMENTS and populate it will the
configuration files taken from the templates.
vccEnvInit –e <environment_name>
With this command you can initialize
the environment and (in the case of a CCSLite
environment) load the on-line database.
vccEnvStart –e <environment_name>
This command will start the
environment. In case of an LCU, the bootScript will
be installed.
vccEnvStop –e <environment_name>
Stops the environment (for LCUs, the bootScript is
de-installed).
vccEnvDelete –e <environment_name>
The environment directory
under $VLTDATA/ENVIRONMENTS/<environment_name>
is deleted.
All those commands can also
be accessed through the graphical interface vccEnv. Launching this command, you will have a menu-driven panel which will
help you choosing the environment and the right parameters to associate to the
environment.
For Garching
people: whenever you need a new environment (WS and/or LCU), you should decide
the name, the machine where the environment has to run and in case of LCUs, the WS the LCU has to boot from. Send all these
information to vltmgr@eso.org and he will
update the msql database.
For each written piece of
code, a corresponding test must also be written. The test will consist in one
or more programs that can be repeatable on whatever machine (and whatever
supported operative system) by whatever user. But first of all, the test suite
has to be run by the developer before archiving the software module with the
new piece(s) of code.
At ESO a tool has been
developed to help organizing the test suite in a standard way, easily
repeatable by an independent user, namely the integration user.
This tool is called tat. A
manual has been written explaining all the features of this tool. Please refer
to [5]. Here follows a quick tutorial about tat.
The Tools for Automated Test
(TAT) is a framework which helps running a test suite with only one command and
reports the result of the test suite in a simple and clear way: the word PASSED
or FAILED is printed to the standard output for every test belonging to the
suite as well as the final result, PASSED or FAILED (it’s enough that one test
in the suite fails to make the entire suite fail).
TAT can be easily integrated
with existing test structures. This test structure can be a collection of
scripts/programs in whatever language (supported within the project) which
provide an output that has to be compared with a reference output.
The test structure has to be
prepared in a software module under the directory test and the Makefile there has to be compliant with the project SE
standards. Using this Makefile, executables and
scripts will be compiled and installed in the bin directory of the module. They
should be local. What this means is that
they get installed under the bin directory of the module only. In the Makefile they are individuated using the suffix “_L”.
Tat handles tests based on
batch programs, not interactive, and without manual interventions through GUIs,
although it is possible to use GUIs whenever this is automatic (i.e., the GUI
starts and exits automatically).
The test driver is the
conductor of the automated tests. It does - almost - everything: its features
provide a good overview of the test software.
The test driver:
- looks in the test directory of a module for a
file named TestList.lite specifying initial and
final scripts, environments, and tests programs;
- executes
“make clean all” to generate the test software;
- source a tcl script
containing the environment variables needed for the test (if it exists);
- executes a prologue script (if it exists);
- allocates and creates environments (if
environments are needed);
- executes the test and compares the output with
the test reference;
- executes an epilogue script (if it exists);
- executes
“make clean”;
- deletes and frees environments (if needed).
The TestList.lite
file can contain five types of directives:
SOURCE, PROLOGUE, ENVIRONMENT, <Test_program_name>, EPILOGUE. The <Test_program_name>
is the only mandatory directive; you can have one only or many test programs
directives to be executed. The other directives are optional. SOURCE, PROLOGUE
and EPILOGUE must be unique while one can have as many ENVIRONMENT directives
as needed.
Here is an example of a TestList.lite file:
SOURCE tcl_script
PROLOGUE myPrologueScript arg1 arg2
ENVIRONMENT wsTat QS
ENVIRONMENT lcuTat LCU
ccsTat
EPILOGUE myEpilogueScript arg1 arg2
1. The SOURCE directive
will be followed by the name of a script written in tcl
language containing environment variables to be sourced at the very beginning.
An example: a test needs to work with an INTROOT, doing every sort of dirty
operation there. The developer normally has an INTROOT defined in his or her
environment but doesn’t want to screw it up with the test. With the tcl script to be sourced, a different INTROOT can be
defined for the test time frame that can then be removed at the end of the test
(the ‘rm –rf $INTROOT’ command can be put in the epilogue script, for
instance).
2. The PROLOGUE
directive is followed by the name of a script or executable to be launched before the environment creation and after ‘make all’. The program
can have one or more arguments, passed as single words separated by blanks. It
can be useful, for example, to start only once processes which will be used by
the different test scripts. (With the EPILOGUE script, see below, you can stop
those processes).
3. The ENVIRONMENT
directive looks like:
ENVIRONMENT
wsTat QS
ENVIRONMENT
lcuTat LCU
The
first word identifies the directive, the second is a symbolic name (chosen by
the developer) for a workstation or lcu environment,
the third word identifies the type of environment and can be QS for a workstation
environment or LCU for an LCU environment. (It is also possible to create a
workstation environment on a remote machine, in this case the environment is
identified with RQS and the variable RHOSTQS=remote_machine_name
must be defined in the developer’s set of environment variables).
Environments
should not be hard-coded in test scripts. If so, it would be practically
impossible to execute a test on another computer with a different LCU (because
the LCU environment name is based on the LCU name). As a consequence,
environments shall only be referred to with environment variables: this is the
rule for all environments, whether they are local QS, remote RQS, or LCU. In
the ENVIRONMENT directive, use symbolic names (like in the example). It is then
up to the TAT program to associate real existing environments (chosen
automatically among a pool of test LCU and WS environments) to the one needed
for the test.
When
starting a test, the test driver allocates environments from the test environment
pools and assigns the chosen environment names to the corresponding environment
variables. This method also has the advantage of freeing the developer to look
for given environments before running each test.
The
pools of available LCUs are identified through an
environment variable called LCUROOT automatically set at login for every user.
For the WS tat environments, no additional variables are needed. Both the two
types of pools (WS and LCU) are handled by the vltmgr.
The
association between real and symbolic environments is recorded in a file called
.testSession. Here is an example of such a file:
QS
wsTat wte16b
LCU
lcuTat lte10
(Refer to [5] for understanding how the names to the tat
environments are assigned.)
Environments
may be customized by creating files in <module_name>/test/ENVIRONMENTS/<envName>: when creating environments, tat will first search
files in these directories before searching the standard directories where the
templates are stored.
At
the end of the test, the test driver deletes the environments that it has
created and gives them back to the pool, so that they can be reused by anyone.
4. The TEST
directive is the only mandatory one. It is a line containing the name of an
executable command to be called. This command cannot have parameters and
identifies the test, in the example:
ccsTat
The
number of TEST directives is unlimited.
A
test may call any program, script, or utility provided that this utility is not
interactive and portable among supported platforms: these prerequisites ensure
that the test output is repeatable and may be used to make a test reference.
The test driver calls the single test and records the output in <module_name>/test/tatlogs/run<pid>/<test_name>.out.
A
special case is when the test driver is instructed to build the reference file:
the output of each single test is recorded in <module_name>/test/ref/<test_name>.ref.
The
output may also be filtered to remove non repeatable output (like dates, times,
etc.) by the test driver. To do this you need to create two files (only one of
the two or both) based resp. on the grep and sed UNIX commands. This is explained in 8.6.2.
5. The EPILOGUE
directive is followed by the name of a script or executable to be launched after the environment deletion and before ‘make clean’. The program
can have one or more arguments, passed as single words separated by blanks.
We will see an example of a
tat test without environments.
Let’s suppose we have a
module called tattest
with the standard directory structure. Let’s
have a script which prints “hello”.
This script is the test for our software
module.
The name of the script is
testscript.sh
and looks like:
#!/usr/bin/ksh
echo
"hello"
exit 0
We create a TestList.lite under tattest/test
which will contain the simple line
testscript.sh
First, we try our script to
see whether it works or not. When we are satisfied with the result, confident
that the test has a good coverage of our code, and certain the test can be
repeatable on any system by any user, we can proceed and generate the reference
file.
To generate the test
reference, type:
$ tat -g testscript.sh
Reference file testscript.sh.ref generated
Reference file
generated.
Tat has generated the
reference file testscript.sh.ref
in the ref
subdirectory of tattest/test:
$ cat ref/testscript.sh.ref
hello
From now on, the test can be
repeated just by typing:
$ tat testscript.sh
TEST testscript.sh PASSED.
PASSED.
At this point, when the test
(or test suite) is finisged, TAT will automatically
compare the result of the actual test with the reference (the output file(s)
under the ref directory) and will print the result on the console. If the
actual output is identical to the reference, the test is successful (PASSED). If not, it failed (FAILED). (If you have a
test suite, made up different test scripts, it is enough that one test fails to
give the final result FAILED.)
One can add as many
scripts/programs as wanted to TestList.lite. If we
have another script called testagain.sh which
prints “goodbye”, we add it to TestList.lite as the
second line.
Then we generate the
reference file:
$ tat -g testagain.sh
Reference file testagain.sh.ref generated
Reference file
generated.
Next, we run the tat test:
$ tat testagain.sh
TEST testagain.sh PASSED.
PASSED.
Then we can also run the
suite of tests (two in our example) with a unique command:
$ tat
TEST testscript.sh PASSED.
TEST testagain.sh PASSED.
PASSED.
When the option “–v” is
passed to tat, the test(s) is run in verbose mode and more information is
printed to the console.
tat
executes make, follows the
actions found in the TestList.lite file (sourcing
file, executing prologue script, making
environments, executing the test suite, comparing the result with the
reference, executing the epilogue script, stopping and deleting the
environments, running “make clean”)
tat makeEnv
performs all the preliminary
actions up to the test which is excluded.
tat <name_of_a_single_test_in_the_test_suite>
executes the test specified
only
tat –g
executes the test preparing
reference files under <module_name>/test/ref
tat cleanEnv
performs the final actions
starting from stopping/removing the environments.
All of the above commands
can be run with the option –v (verbose) which adds more information
to the standard output.
Remark: do
not interrupt the command tat while it is cleaning up the environments. This phase
is very important because it will remove lock files and directories that, if
left over, will prevent you or other users from correctly dealing with the
environments when running tests. If you chose to run separately the creation of
the environment (with “tat makeEnv”) from the
real test (“tat”), remember to always run after the test has finished
“tat cleanEnv” to release environments and lock files.
When TAT starts, it creates
a directory under test, called tatlogs/run$$, where
$$ is the PID of the process. In this directory whenever the test fails, the
output file of the test run within $$ and the differences found between the
output file and the reference are stored.
On every run, a directory
run$$ is created. If a test is successful the corresponding directory run$$ is
removed. These files can be inspected in case of test failure.
Sometimes the output of a
test contains records that are not exactly reproducible elsewhere (for example
timestamps, hostnames, etc.).
In this case, it is possible
to filter out those types of records using the syntax of grep
and sed. TAT gives the possibility of using two files
(only one of the two or both), called:
TestList.grep
and TestList.sed
When these files are present
under the test directory, the standard output and the standard error of the
test scripts are first processed by:
- grep -v -f TestList.grep
<output>
- sed -f TestList.sed
<output>
then are redirected into
./tatlogs/run<process_id>/<testid>.out (or
ref/<test_script_name>.ref).
Each line of TestList.grep will correspond to the word(s) that have to be grepped out before generating the reference or output
files.
TestList.sed will contain records written in sed
(a regular expression Unix program) syntax.
The tool eccsTestDriver
offers some useful features that, starting from the tat released with APR2004
(tat 1.91) have been merged within tat. The tat man pages have been updated and
a description of these new features are available on the web under the APR2004
Release Notes:
http://www.eso.org/projects/vlt/sw-dev/vltsw/APR2004/APR2004_RelNotes.Kit \
The SPR system is built using the commercial tool
Action Remedy (c) and has a Web Browser interface.
The
SPR System is supposed to be used by internal or external users of the VLT
software (or other software projects) in case an error in some code or in the
documentation is found or a change to improve the behaviour of the existing
software seems needed.
Access is granted to registered users only via a
login procedure.
To get a login send a mail to vltsccm@eso.org with the following information:
1)
Login name
2)
Full Name
3)
Institute
address and phone number
4)
Full email
address
Refer to vltsccm for any
other problem/question concerning the system.
Run netscape (or another
Web browser), connect to
the VLT Software development page:
http://www.eso.org/projects/vlt/sw-dev/
and select “VLT Software Problem Report”.
The login page is shown. Provide your identification
in terms of username and password.
If you have problems accessing the system or you have
forgot your password contact vltsccm@eso.org
To submit an SPR use the following procedure:
- login
into the VLT SPR system
- choose
the link "New" for the VLT SPR schema
- the
submit page should be displayed. Fill it as suitable. (You can also use
the on-line help). The fields whose labels are displayed in bold are
mandatory, the others optional.
- click “Submit”.
The SPR will be added to the archive. The initial status is "Open".
Note: Please
remember to specify the Consortium/project you belong to on the Location field
The query functionalities are available using the
following procedure:
- login
into the VLT SPR system
- choose
the link "Find" for the VLT SPR schema
- the
Search page should be displayed
From there on is possible to perform the following
main operations:
- Get a
list of SPR
The selection can be performed using one or more of
the available fields.
Once the searching rules are set, click on “Run
Search”. As result of the selection a list of the SPR(s) which match the search
criterium is displayed.
- Display
a specific SPR
Specify the SPR number and press “Run Search” or if
the SPR appears already on the list of displayed SPRs
(obtained at point 4), simply click on “Display” for the desired SPR entry in
the list.
- Add a
Remark
To add a remark to a selected SPR click on “Modify”.
The Modification page should be displayed. Add any remark on the Worklog field and click “Modify”.
- login
into the system
- choose
"Find" for the "User" schema
- type
your login in the "Login name" field
- run “Search”
- choose “Modify”
- change
the password field
- click “Modify”
Here we briefly summarise the basic
workflow of the system:
A Software Problem Report
is submitted
|
Assigned by default to vltsccm
|
Notification sent to all relevant people (according to the package the
SPR belongs to)
|
Comments added by any
known user
|
The SPR is evaluated in
the SCCB
meeting and, if accepted, a Responsible Person is appointed for the problem
|
Responsible works on the problem
|
Responsible can close the
SPR (must add a final remark on it)
When a SPR is submitted, the vltsccm, a list of people defined by the package and any
names/addresses in the 'cc' field will be notified with all details of the
problem. After this point, any change in 'status' will result in all the listed
people above and the 'Responsible' being notified of the changes on all problem
details.
Among all the possible statuses, the
following ones are used for the VLT SPR System Workflow:
1.
Open: the initial status
2.
Assigned: during the SCCB meeting, a responsible person for
the SPR has been appointed
3.
Progress: the SPR has been assigned and work on the problem
is in progress
4.
Closed: the responsible person finished his implementation
and test
5.
Suspended: obvious meaning
Upon closing, a 'closed status'
value must be set and a remark must be added on the Workflow field. If those
fields are not filled, an error is generated and the problem is not closed.
Once those fields are completed the problem can be successfully closed. The
possible closed statuses are:
1.
deleted: the SPR was submitted by mistake;
2.
solved: the implementation has been performed and
accomplished;
3.
clarified: the problem has been clarified without doing a
real implementation;
4.
rejected: the problem has not been accepted.
When a problem is submitted to the
Problem Reporting Tool, it is assigned to vltsccm
with status “open”. This user is the only one who can progress the 'status' of
the report from 'open' to 'progress' assigning the SPR to a responsible person,
and therefore initiate the continuance of the workflow. After this point, the 'Responsible' user as
well as the vltsccm can progress the 'status' of a
problem.
Important
remark: changes in ANY VLTSW module are allowed only if covered by a SPR and
authorised by SCCB. Changes done without any SPR coverage are therefore
forbidden.
Fields on
Submit page:
(In bold the mandatory fields, which have to be filled in)
Originator
This field is automatically filled
by the system using the login name
Location
The Originator should indicate the
site or consortium he belongs to.
Package
This field specifies to which
Package the SPR is related. If the SPR doesn't fit in any package, select <undefined>. The list of people defined on the Package
name (as well as any additional e-mail in the cc list) will be notified with
all details of the problem.
Type
It could be: sw-bug,
doc-error, change-request
Module Name
This Field should be filled with the
name of the module to which the Software problem is related. This name is the
one used in the VLT Software Archive (CMM Archive)
Module version
This Field should be filled with the
cmm version of the module where the problem has been
found.
cc
This Field should be filled with all
the people not included in the Package list that need to be notified by e-mail
about the SPR progress
Synopsis
This field is a brief description to
quickly identify the SPR.
Remember that this field will be
used later on when selecting SPRs by keyword. Choose
meaningful words!
Description
The complete statement of the
problem
Priority
The Originator can choose a value in
the range 1-5, with 1 for the highest priority.
Additional
Fields on Query Page:
Status
The status values of the problem
report:
-
open: the SPR has been
entered into the database
-
assigned: a responsible person
has been appointed
-
progress: the SPR has been
assigned and work is in progress.
-
suspended: the SPR has been
discussed and suspended. To be discussed again.
-
closed: the SPR is not being
worked on and no further work is envisaged.
Closed Status
This field is associated with the
closed state and indicates the circumstances under which the SPR was
closed. The values for this field are:
- deleted: the problem is
incorrectly submitted or duplicated.
- solved: action has been taken and
the problem has been solved.
- clarified: problems that are user
error or already fixed.
- rejected: the problems is not
accepted.
Responsible
It is the person assigned by the
SCCB to work on the problem. He can modify the status of the SPR after it as
been assigned to him by the vltsccm. The Responsible is asked to provide the
evidences that the SPR can be closed.
Before closing it, he must add a remark explaining how and why the SPR
is closed.
Originator
It is the one who submitted the
problems via web interface.
Worklog
In this field any user can add a
remark on the SPR (as long as needed). It must be filled any time the status of
the SPR is changed.
The appropriate documentation
has to be written together with the code.
We can individuate many
levels and types of documentation:
- Comments inside the code
- Header of each source files to generate man
pages
- ChangeLog
- Release Notes
- Manuals
You can use your preferred
editor to write comments into your code, vi and emacs
being the most common ones. For developers, emacs
offers a set of utilities and customizations to ease and improve the
developer’s work.
For official documents (see 10.5 Manuals), we use FrameMaker
or Microsoft Word.
In chapter 4 and 5 of [1] under the paragraph “Comments” you will find some
information for writing comments in C programs and script files. The same
conventions can be extended to the other supported languages mutatis mutandis!
Please, refer to [1] paragraphs 2.4.3 and 2.4.4 for the detailed
description of each section in the file header.
10.3
ChangeLog
This file must exist in
every module under <mod_name>/ChangeLog. It has to be updated before archiving the module
(if not the cmmArchive command fails). It is good
practice to list all the files that have been modified for releasing that
version of code, with a brief comment (what the modification consists of).
For every major release of
the VLTSW, the complete set of Release Notes for all the VLTSW applications and
programs has to be produced. It is up to the software responsible to organize
the Release Notes at package level or module level. (For an overview on the
VLTSW and its subdivision in packages, see [6]).
A template for writing Release
Notes is available from getTemplate
-> code -> RELEASE_NOTES.
Once the Release Notes have
been written, they should go in a centralized repository (a module called vltsw under configuration control). Afterwards, they are
delivered with the VLTSW release to Observatories and Consortia and they are
also published on the web at http://www.eso.org/projects/vlt/sw-dev/vltsw/index.html.
The procedure to check in
and out the module and to update the web pages can be found at http://www.eso.org/projects/vlt/sw-dev/procedures/release_notes.txt
In the “Software Management
Plan” for the VLT project (see [7] paragraph 4.2) all types of documents to be produced
together with the software are described. These documents can be written at
module level as well as at package level and can cover the entire software
process, from the Requirements phase (Software Requirements Specification) to
the Design (Functional Specification and Software Design Description) to the
User documentation (Software User Manual and Software Maintenance Manual).
Whenever you have to write a
document, you can start from the utility getTemplate to obtain the templates for the editors we support
in our group: FrameMaker or Microsoft Word.
The documents should go
under configuration control exactly as any other software module. As explained
in chapter 5, ask vltsccm for the creation of a
document module. The name of the document module should correspond to the
document identification (DOC ID) number. There is a procedure to get a DOC ID
and it is explained in the following paragraph 10.6.
The convention for documents
is to have a 1-digit issue number, for example: VLT-MAN-ESO-17000-0642 issue 2
and so on. But in cmm, the modules have got a
two-digit revision number. What has been agreed is that
issue number = major number of the revision number
For example, you are working
to a document and you make modification in cmm up to
revision 1.15.
When you are satisfied and
ready to release the document, for example for the VLTSW RELEASE APR2003, you
will archive the document specifying the revision 2.0 and having written into
the documents ”issue 2”.
For the following release,
OCT2003, you will modify the document up to revision 2.6 then for OCT2003 you
archive it with revision 3.0 and issue number 3 and so on.
A document is identified by
a title chosen by the author and by a DOC ID which is made by alpha-numerical
characters.
The ESO document official ID
number is made up of 5 parts:
PROJ - TYPE - ESO - PSC – chronological_four_digit_number
An example of DOC ID is:
VLT-MAN-ESO-17200-0642
- VLT -> name of the project the document
belongs to
- MAN -> type of the document (see Annex 3: Document types
and PSCs for the list of possible types)
- ESO -> obvious meaning
- 17200 -> PSC (Product Structure Code) (see Annex 3: Document types
and PSCs for the PSCs list)
You
(or your supervisor) should decide the first 4 identification parts of the document.
- 0642 -> This number will be assigned by the
Archive group.
To get the number, send a
mail to tecarch@eso.org asking for a chronological
four-digit number, specifying:
- the document TYPE,
- the PSC,
- the document title,
- author name(s),
- indicate whether the document has to be
distributed outside the TEC
division or not.
- indicate whether the document has to be
distributed outside ESO or
not.
The same procedure is
available on the web: http://www.eso.org/projects/vlt/sw-dev/procedures/index.htm,
click on the link “How to get a document ID”.
Once the document is ready,
don’t forget that:
- A hard copy must be delivered to the Archive
people (deliveries to the Technical Archive should be put in the Technical
Archive mailbox opposite office #249)
- Attach to your document the distribution list (a sheet of paper with the list of people
you want to ship the document to). Our secretary (Veronique Ziegler)
should have a copy of it.
- The copy must have your signature and the
signature(s) of your supervisor(s)
Annex 1: VLT Directory Structure
#*******************************************************************************
NAME
vltDirectoryStructure - VLT Software standard directory
structures
DESCRIPTION
This man-page is part of the VLT Programming Standard and
supersedes app.C
pag.59 of VLT Programming Standard (VLT-PRO-ESO-10000-0228
- 1.0 10/03/93)
The following areas are defined:
- module
development area (MODROOT)
-
integration area (INTROOT)
- VLT
System area (VLTROOT)
- data
area (VLTDATA)
For each area a set of standard subdirectories is
defined. The subdirectories are named consistently, so no matter the area, they
contain always the same type(s) of files. The standardized subdirectory names
are:
ALARMS =
Alarm Definition File (<mod>_ALARMS)
ALARMS/HELP =
Alarm Help Files (<modAlarmMnemonic>.hlp
CDT =
Command Definition Table (<process>.cdt)
CIT =
Command Interpreter Table (<process>.cit)
ENVIRONMENTS = one subdirectory for each ws or lcu environment
ERRORS =
Error Definition (<mod>_ERRORS) and index (<mod>_ERRORS.IDX)
ERRORS/HELP =
Error Help Files (<modErrorMnemonic>.hlp
System =
startup/login files
Sources =
original files at installation time (to support debugging)
app-defaults = Xresource files
for GUI
bin = for executable (C, C++, scripts, tcl-scripts, panels, etc.)
bin/$CPU = VxWorks executable (FEB99: CPU=MC68040|PPC604|MC68000)
bitmaps =
bitmaps files used by graphical applications
sounds =
sounds files used by interactive applications
config = configuration data files
dbl =
On-Line Database files (*.db, *.class)
doc =
documentation (User/Maintenance Manual)
idl = Interface definition language files
include = for
".h" files
lib = for libraries:
_ar_chive files, tcl
libraries
lib/$CPU = VxWorks libraries (FEB99: CPU=MC68040|PPC604|MC68000)
man = for manpages, organized in subdirectory :
-
man1 for commands accessible by the user of the system
- man2 not used
-
man3 subroutines
-
man4 not used
-
man5 file formats
-
man6 not used
-
man7 development tools
-
man8 not used
- mann not used
-
manl local man-pages
object =
output of compilation, other intermediate files (.d, .dx,
etc)
src = source files (C, C++, scripts, tcl-scripts,
panels, etc)
templates =
templates for documents, source files, etc.
test = as src, but for test software
tmp = temporary files
vw = sub-root for VxWorks
directories (LCU applications).
Not all the subdirectories are present in all areas and
may be empty.
-------------+----------+---------+------------+---------+-----------+-----------+
Sub-directory|
MODROOT INTROOT INTROOT/vw VLTROOT
VLTROOT/vw
VLTDATA
-------------+----------+---------+------------+---------+-----------+-----------+
ALARMS = *
* *
ALARMS/HELP = *
* *
CDT = *
* *
CIT = * * *
ERRORS = *
* *
LOGS = *
* *
ERRORS/HELP = *
* *
ENVIRONMENTS =
*
System = *
Sources = *
*
app-defaults =
* * *
bin = *
* * * *
bin/MC68000 = * *
bin/MC68040 = * *
bin/PPC604
= * *
bitmaps = *
* *
sounds = *
* *
config = * * * *
doc = *
dbl = *
* * * *
idl = * * * * *
include = *
* * * *
lib =
* * * * *
lib/MC68000 = * *
lib/MC68040 = * *
lib/PPC604 = * *
man =
* * * * *
object = *
src = *
test = *
templates = *
tmp = * *
vw = * * *
-------------+----------+---------+------------+---------+-----------+-----------+
MODULE DEVELOPMENT
AREA
It is the area where the code of a module is developed
and test and is under the responsibility of a developer.
Development areas can be created on any machine and in
multiple copies.
The root directory of each area is called module root.
The command 'setmod' allows you to set the
environmental variable MODROOT and to add MODROOT/bin to PATH).
There are two types of module structure, according to the
type of code the developer has to write (for Unix workstations only, for LCUs using the VxWorks cross
compiler or both):
- simple : the
module has code only for one type of operative system.
<mod>/
|------src/
|------...
:
- complex: the
module is splitted in complementary parts among two
or more
operative system. At present, the following
cases are defined:
<ws>
HP or Sun workstation running
UNIX
<lcu>
Local Control Unit running VxWorks
<ace> Transputer
boards running OCCAM software
Complex modules are organized as one complete subdirectory tree
for
each implementation:
<mod>/
|-------/ws
| |------src/
| |------...
|
|-------/lcu
|------src/
|------...
Any activity in the development area of a module shall be
based on the standard structure and all paths shall be relative to the module
root.
No reference to such areas can be made from other
modules.
Each area (MODROOT: <mod>, <mod>/ws, <mod>/lcu) has the the following subdirectory tree:
$MODROOT/
|------src/ <------ MANDATORY
| |------Makefile <------ MANDATORY
| |------aaaa.c
| |------bbb.c
| |------xxxx.c
| |------script1
| |------ .
|
|------include/
| |------mod.h
| |------modPrivate.h
| |------modErrors.h
| |------
.
|
|------dbl/
| |------modClass1.class
| |------ .
| |------modBranch.db
| |------ .
|
|---app-default/
| |------XapplName
| |------ .
|
|---bitmaps/
| |------rightArrow
| |------leftArrow
| |------ .
|
|---sounds/
| |------laugh.au
| |------soundsWarning.au
| |------ .
|
|------CDT/
| |------modProc1.cdt
| |------ .
|
|------CIT/
| |------modProc1.cit
| |------ .
|
|---ALARMS/
| |------mod_ALARMS
| |---HELP/
| |---modXXXXXXX.hlp
| |--- .
|
|---ERRORS/
| |------mod_ERRORS
| |------modERRORS.IDX
| |---HELP/
| |---modINVACCC.hlp
| |--- .
|-----LOGS/
| |------mod_LOGS
| |------modLOGS.IDX
|
|------config/
| |------mod....
| |------ .
|
|------object/
| |------aaaa.o
| |------aaaa.d
| |------ .
| |------bbb.o
| |------bbb.d
| |------llll.da
| |------xxxx.dx
| |------ .
|
|------bin/
| |------xxxx
| |------script1
| |------ .
|
|------lib/
| |
| |------libllll.a
| |------ .
|
|------idl/
| |
| |------aaaa.idl
| |------ .
|
|------man/man1/
| |------man1/
| | |------llll.1
| | |------script1.1
| | |------xxxx.1
| | .
| |------man3/ .
| | |------aaaa.3
| | |------bbb-1.3
| | |------bbb-2.3
| . |------ .
| .
| |------mann/
|
|
|------doc/
| |------llll.inc
| |------llll.text
| | .
|
|------test/
| |------Makefile <------ MANDATORY
| |------yyyy.c
| |------scriptXxxx
| |------ .
|
|------tmp/
|------ ....
REMARK: any
modification to the shown structure shall be documented in the Maintenance Manual.
INTEGRATION AREA
It is an intermediate area, personal or shared among a
group of developers, where to install (from the development areas) the module
code in order to perform the integration activities.
Integration areas are defined only on development
computers.
It is possible to have many integration areas but only
one at a time can be active: the one defined in the environmental variable
$INTROOT.
In integration areas only and to allow debugging, special
directories, namely $INTROOT/Sources and $INTROOT/vw/Sources,
are storing the source files of the module currently installed in the $INTROOT.
When "make install" is issued and INTROOT is
defined, vltMakefile copies:
..../<mod-i>/src/* --copied
into--> $INTROOT/(vw/)Sources/<mod-i>/src/*
..../<mod-i>/test/* --copied into--> $INTROOT/(vw/)Sources/<mod-i>/test/*
..../<mod-i>/include/* --copied into--> $INTROOT/(vw/)Sources/<mod-i>/include/*
where <mod-i> can be the
module name or <mod>/ws, <mod>/lcu, etc.
$INTROOT/
|---ALARMS/
| |---HELP/
|
|------CDT/
|ENVIRONMENTS/
|---ERRORS/
| |---HELP/
|
|-----LOGS/
|------app-defaults/
|------bin/
|------bitmaps/
|------sounds/
|------config/
|------include/
|------dbl/
|------idl/
|------lib/
|------man/
| |-----man1/
| |-----man2/
| |-----..../
|
|------Sources/
| |----mod1/
| | |----src/
| | |----include/
| | |----test/
|
|----mod2/
| | |----ws/
| | |
|----src/
| | |
|----include/
| | |
|----test/
| | |----lcu/
|
| |----src/
| | |----include/
| | |----test/
| |
| |----..../
|
|----vw
|------BOOT/
|------CIT/
|------bin/
| |-----MC68000
| | |----..../
| |-----MC68040
| | |----..../
| |-----PPC604
| |----..../
|
|------include/
|------dbl/
|------lib/
| |-----MC68000
|
| |----..../
| |-----MC68040
| | |----..../
| |-----PPC604
| |----..../
|
|------man/
| |-----man1/
| |-----man2/
| |----..../
|
|------src/
| |----mod1/
| |----mod2-lcu/
| |----..../
|
|------test/
|----mod1/
|----mod2-lcu/
|----..../
VLT SYSTEM AREA
contains software that has been officially released
(i.e., coming from the archive, integrated and tested). It will not undergo
other changes, it is frozen.
At least one VLT System area is defined on each computer,
both on target and development ones. (TBD whether to use physical copies or
remote access via NFS).
It is possible to have many VLT System areas but only one
at time can be active: the one defined in the environmental variable $VLTROOT.
$VLTROOT/
|---ALARMS/
| |---HELP/
|
|------CDT/
|ENVIRONMENTS/
|---ERRORS/
| |---HELP/
|
|-----LOGS/
|---System/
|------app-defaults/
|------bin/
|------bitmaps/
|------sounds/
|------config/
|------include/
|------dbl/
|------idl/
|------lib/
|------man/
| |-----man1/
| |----- .
|
|----vw
| |------BOOT/
| |------CIT/
| |------bin/
| | |-----MC68000
| |
| |----..../
| |
|-----MC68040
| |
| |----..../
| |
|-----PPC604
| | |----..../
|
|------include/
| |------dbl/
| |------lib/
| |
|-----MC68000
| |
| |----..../
| |
|-----MC68040
| |
| |----..../
| |
|-----PPC604
| | |----..../
| |------man/
| |
|-----man1/
| .
|-----.
|
|
|-templates/
HOW THEY ARE USED
The environmental variables shall be defined as the root
directory of:
$MODROOT the development
area where you are now working
$INTROOT the integration
area currently in use
$VLTROOT the VLT SW root
currently in use
$MODROOT
can be dinamically set using the command 'setmod'.
You do not need to have a proper environment variable “$MODROOT”.
$INTROOT
should be
defined at login time by one of your startup files using:
- for Bourne/Korn/bash shell:
INTROOT=<directory>; export INTROOT
$VLTROOT
should be
defined at login time by the system startup files (for test purpose you can
redefine it in your personal startup files)
The hierarchy in using files is:
development,
integration, system
and is obtained using the following search paths:
search path
for commands: $MODROOT/bin $INTROOT/bin $VLTROOT/bin
for .h files: $MODROOT/include $INTROOT/include
$VLTROOT/include
for libxxx.a:
$MODROOT/lib $INTROOT/lib $VLTROOT/lib
The same hierarchy (development, integration, system)
applies for data files, like ERRORS, HELP, etc.
The 'make install' command always copies files from the
current area (if you are working under MODROOT/src,
make will look for ../bin, ../lib etc.) to either the integration area (if
INTROOT is defined it has the precedence) or the system area.
during
development:
- INTROOT is
defined (normally in the .pecs/apps-all.env ) and
'make install'
is issued
from $MODROOT/src. So, files are taken from the
current
module and
installed in the integration area.
during
installation of a machine with the released VLTSW:
- only VLTROOT
is defined. So, files are copied into the VLT System area.
Each release of a software module can be in only one of
the following status:
- UNDER
DEVELOPMENT
the sw is tested locally into the development area.
- UNDER
INTEGRATION
the active
part of the sw, i.e., executable, libraries, headers,
manpages, etc., is copied ('make install') from the
development area
to the
integration area, therefore it is available to everybody which
is making
reference to that integration area.
- ACCEPTED
the
software has past the acceptance test and then all the files
forming the
module are moved from the development area to the archive.
A release of a software module is INSTALLED when the
active part of the sw has been copied in the VLTROOT
area following the installation procedure, as from the Module User Manual.
SECURITY
There are three main aspects related to security: backup,
editing and protection.
Backup
------
Regular backup shall be provided at system level at least
for:
- archive
- development
areas (all the user home directories)
- data files
under root.
Editing
-------
Changes can be made only in development areas. Except for
data files, changes on archive or root files are not permitted.
Protection
----------
It is based on the standard UNIX file protection system
(using username and permission bits):
- directories are open for read and write.
- files are readable from everybody, but writable only
from the username that performed the 'make install' (*)
- data files shall be protected or not, according to the
need.
Being based on the UNIX protection, all the commands to
override such system of rules (su, chmod, etc.) are valid and can be used. Be careful when you
step out of the defined rules!
------
(*) This implies
that a modification can be done only by the developer responsible for a module.
So, if during integration you discover an error in somebody else software, you
should pass this information to him, so it can be fixed, or, if you can fix it
and you need it urgently, fix the problem in a local copy and send it to him so
local test can be repeated before installation into the integration area. Due
to the hierarchy in the search paths your local copy will have the precedence.
When the problem is fixed in the integration area (or in the root area),
remember to delete your local copy.
CAUTIONS
Some general considerations:
- do not make copies from the root or from the
integration into your development area of software that is not in the scope of
the module you are developing. The local copy will override new versions eventually
made available in the root or in integration.(see above for exception).
- for the same reason, do not copy from root into the
integration area software that is not in the scope of what you are integrating
(unless you need a version of a software that is older than the one now available
in the root).
#--------------------------------------------------------------------------------
Annex 2: Document types and PSCs
DOCUMENT TYPE ACRONYM DESCRIPTION
CRE Change Request - Official
request to change an item which is under configuration control
DNO Discrepancy Notice -
Notification that an item under configuration control is not compliant with the
specification or ICD
ICD Interface
Control Document - Document describing the requirements and design of the
interface between two configuration items
INS Instruction - Guidelines on how
to perform a certain task or process
LIS List Document - giving an
enumeration of items.
MAN Manual Document - describing a
product. Can focus on specific groups, e.g. user, maintenance, installation
etc.
MIN Minutes of Meeting - Meeting
report, can include action item list
PLA Plan - Official document
describing an intended scheme or (sub-) project
PRO Procedures - Mandatory
description of how a certain task or process should be executed
RFW Request for Waiver - Official
request to be exempted from a requirement
SOW Statement of Work - Document
describing what tasks should be carried out by a defined entity (person,
company, institute)
SPE Specification - Document
describing the required performance of a product
REP Report - Document giving an
official written account, including technical documents
MEM Memorandum - Unofficial
document, can address any subject
VER Verification Document/Test Protocol
- Official document describing a test procedure
DWG Drawing/ Drawing List/Parts
List/Schematic - Document presenting a graphical representation of a physical
part, or: Document which enumerates all drawings that describe a single product
or a logical or functional part of a product; or enumerates all parts including
unique type codes (e.g. manufacturer’s type number), used in a single product
or a logical or functional part of a product; or is a technical drawing showing
a schematic representation of an electrical circuit, hydraulic system etc.
PSCs
|
Structure
|
Title
|
Issue Date 26.11.02
|
|
|
|
00000
|
VLT Management
|
|
|
|
|
10000
|
VLT Observatory
|
|
|
|
|
10100
|
AIV - Assembly/Integration/Verification
|
|
|
|
|
10200
|
Commissioning
|
|
|
|
|
11000
|
Telescopes
|
|
|
|
|
11100
|
M1/M3 Unit
|
|
|
|
|
11110
|
M1 Mirror
|
|
|
|
|
11120
|
M1 cell/M3 Tower
|
|
|
|
|
11130
|
M3 Mirror/cell
|
|
|
|
|
11200
|
M2 Unit
|
|
|
|
|
11210
|
M2 Electromechanical Unit
|
|
|
|
|
11220
|
M2 Mirror/cell
|
|
|
|
|
11300
|
Structure
|
|
|
|
|
11310
|
Main Structure
|
|
|
|
|
11315
|
Alarm Connection Points
|
|
|
|
|
11320
|
Local Control Units
|
|
|
|
|
11321
|
Altitude and Azimuth LCUs
|
|
|
|
|
11322
|
Hydrostatic bearing and cooling system
|
|
|
|
|
11400
|
Adaptors/Rotators
|
|
|
|
|
11410
|
Cassegrain adaptor/rotator
|
|
|
|
|
11411
|
Cassegrain adaptor/rotator no 1
|
|
|
|
|
11412
|
Cassegrain adaptor/rotator no 2
|
|
|
|
|
11413
|
Cassegrain adaptor/rotator no 3
|
|
|
|
|
11414
|
Cassegrain adaptor/rotator no 4
|
|
|
|
|
11420
|
Nasmyth adaptor/rotator (A & B)
|
|
|
|
|
11421
|
Nasmyth adaptor/rotator 1
|
|
|
|
|
11422
|
Nasmyth adaptor/rotator 2
|
|
|
|
|
11423
|
Nasmyth adaptor/rotator 3
|
|
|
|
|
11424
|
Nasmyth adaptor/rotator 4
|
|
|
|
|
11425
|
Nasmyth adaptor/rotator 5
|
|
|
|
|
11426
|
Nasmyth adaptor/rotator 6
|
|
|
|
|
11427
|
Nasmyth adaptor/rotator 7
|
|
|
|
|
11428
|
Nasmyth adaptor/rotator 8
|
|
|
|
|
11500
|
Coude
beam/focus
|
|
|
|
|
11510
|
Coude
Train M4-M8 General
|
|
|
|
|
11514
|
M4 Mirror Assembly
|
|
|
|
|
11515
|
M5 Mirror Assembly
|
|
|
|
|
11516
|
M6 Mirror Assembly
|
|
|
|
|
11517
|
M7 Mirror Assembly
|
|
|
|
|
11518
|
M8 Mirror Assembly
|
|
|
|
|
11519
|
M9 Mirror Assembly
|
|
|
|
|
11520
|
Coude
Focus Status
|
|
|
|
|
11521
|
Rotating platform in Coude room
|
|
|
|
|
11522
|
Coude
focus electromechanical devices
|
|
|
|
|
11523
|
M9 Exchanger
|
|
|
|
|
11530
|
M10 Mirror Assembly
|
|
|
|
|
11531
|
M11 Mirror Assembly
|
|
|
|
|
11535
|
M9 M10 M11 Towers
|
|
|
|
|
11540
|
Mirrors M4-M7 'B' and mountings
|
|
|
|
|
11550
|
Mirrors M8 and mounting
|
|
|
|
|
11560
|
Mirrors M9 and mounting
|
|
|
|
|
11570
|
Mirrors M10 and mounting
|
|
|
|
|
11580
|
Mirrors M11 and mounting
|
|
|
|
|
11600
|
Adaptive Optics
|
|
|
|
|
11610
|
Coude
adaptive optics
|
|
|
|
|
11620
|
ADONIS
|
|
|
|
|
11630
|
Laser guide Star Studies
|
|
|
|
|
11640
|
MACAO
|
|
|
|
|
11650
|
NAOS
|
|
|
|
|
11660
|
Low noise fast readout CCD for AO
|
|
|
|
|
11670
|
Quad cell APDs for AO (STRAP)
|
|
|
|
|
11680
|
AO data reduction
|
|
|
|
|
11690
|
IR wave front sensor
|
|
|
|
|
11700
|
VLT Technical CCD Systems
|
|
|
|
|
11710
|
Small CCD Systems
|
|
|
|
|
11720
|
Large CCD Systems
|
|
|
|
|
11750
|
Second Generation TCCDS
|
|
|
|
|
11751
|
Reserved for Second Generation TCCDS
|
|
|
|
|
11752
|
Reserved for Second Generation TCCDS
|
|
|
|
|
11753
|
Reserved for Second Generation TCCDS
|
|
|
|
|
11754
|
Reserved for Second Generation TCCDS
|
|
|
|
|
11755
|
Reserved for Second Generation TCCDS
|
|
|
|
|
11800
|
VLT Laser Guide Star Facility
|
|
|
|
|
11810
|
LGS Laser Room
|
|
|
|
|
11811
|
Platform
|
|
|
|
|
11812
|
Clean room
|
|
|
|
|
11813
|
Services & Interlocks
|
|
|
|
|
11814
|
Dye Pump Enclosure
|
|
|
|
|
11820
|
LGS Laser Bench (PARSEC)
|
|
|
|
|
11830
|
LGS Beam Relay System
|
|
|
|
|
11831
|
Fibre
Relay
|
|
|
|
|
11832
|
BR Input
|
|
|
|
|
11833
|
BR Output
|
|
|
|
|
11840
|
LGS Launch Telescope System
|
|
|
|
|
11841
|
Launch Telescope Assembly
|
|
|
|
|
11842
|
LTS/M2 Interface
|
|
|
|
|
11843
|
Aircraft Monitor
|
|
|
|
|
11844
|
LTA Shutter
|
|
|
|
|
11845
|
LTS Control Electronics
|
|
|
|
|
11850
|
LGS Safety & Maintenance
|
|
|
|
|
11851
|
LGSF Safety Systems
|
|
|
|
|
11852
|
Maintenance Equipment
|
|
|
|
|
11853
|
Compliance & Documentation
|
|
|
|
|
11860
|
LGS AIV, Commissioning, Operations
|
|
|
|
|
11870
|
LGS Control System
|
|
|
|
|
11871
|
Workstation Software
|
|
|
|
|
11872
|
LCU Software
|
|
|
|
|
11873
|
Computer Hardware
|
|
|
|
|
11890
|
LGS solid state lasers
|
|
|
|
|
11891
|
Fibre
Raman laser
|
|
|
|
|
11895
|
Sum frequency laser
|
|
|
|
|
11900
|
Maintenance/support equipment
|
|
|
|
|
11910
|
M1 Handling/transport equipment
|
|
|
|
|
11911
|
M1 Carriage
|
|
|
|
|
11912
|
M1 Lifting Platform
|
|
|
|
|
11913
|
M1 Handling tools
|
|
|
|
|
11914
|
M1 Transporter
|
|
|
|
|
11920
|
M2 handling equipment
|
|
|
|
|
11930
|
M3 handling equipment
|
|
|
|
|
11940
|
Optic. Integration/maintenance tools
|
|
|
|
|
11941
|
Optical Alignment tools
|
|
|
|
|
11942
|
Optical maintenance equipment
|
|
|
|
|
11943
|
Paranal Optical Lab
|
|
|
|
|
11950
|
Coating facility
|
|
|
|
|
11951
|
Washing Unit
|
|
|
|
|
11952
|
coating unit 8m
|
|
|
|
|
11953
|
Coating unit 2m
|
|
|
|
|
11954
|
Clean room
|
|
|
|
|
11960
|
VLT Test Cameras
|
|
|
|
|
11961
|
VLTTC opto-mechanics
|
|
|
|
|
11962
|
VLTTC scientific CCD
|
|
|
|
|
11970
|
General Handling Equipment
|
|
|
|
|
11971
|
Cassegrain carriage
|
|
|
|
|
11972
|
Telescopic working platform
|
|
|
|
|
11973
|
Flying carpet
|
|
|
|
|
11974
|
Service Platform for M1 Cell Assembly
|
|
|
|
|
11980
|
M1 unit mass dummy
|
|
|
|
|
12000
|
INFRASTRUCTURE/BUILDINGS/ENCLOSURES
|
|
|
|
|
12100
|
Infrastructure
|
|
|
|
|
12110
|
Site Development
|
|
|
|
|
12111
|
Levelling
|
|
|
|
|
12112
|
Roads/Parking
|
|
|
|
|
12113
|
Airstrip
|
|
|
|
|
12114
|
Storage Areas
|
|
|
|
|
12115
|
Paranal Central Alarm System
|
|
|
|
|
12120
|
Supply Systems
|
|
|
|
|
12121
|
Electrical Power Generation
|
|
|
|
|
12122
|
Thermal energy Production
|
|
|
|
|
12123
|
Water supply/treatment
|
|
|
|
|
12125
|
Energy feasibility study
|
|
|
|
|
12126
|
Sewage treatment
|
|
|
|
|
12127
|
Irrigation
|
|
|
|
|
12128
|
Vehicle fuel supply
|
|
|
|
|
12130
|
Distribution Networks
|
|
|
|
|
12131
|
Electrical Power Distribution
|
|
|
|
|
12132
|
Thermal Network
|
|
|
|
|
12133
|
Water Network
|
|
|
|
|
12134
|
Communications Network
|
|
|
|
|
12135
|
Compressed air Network
|
|
|
|
|
12140
|
Construction site equipment
|
|
|
|
|
12141
|
Base camp
|
|
|
|
|
12142
|
Cranes
|
|
|
|
|
12143
|
Lifting Devices
|
|
|
|
|
12144
|
Vehicles
|
|
|
|
|
12150
|
Local communications (Chile)
|
|
|
|
|
12200
|
Buildings
|
|
|
|
|
12210
|
Buildings astronomical functions
|
|
|
|
|
12211
|
Tel. Piers/enclosure foundations #1
|
|
|
|
|
12212
|
Tel. Piers/enclosure foundations #2
|
|
|
|
|
12213
|
Tel. Piers/enclosure foundations #3
|
|
|
|
|
12214
|
Tel. Piers/enclosure foundations #4
|
|
|
|
|
12215
|
Combined Coude lab.
|
|
|
|
|
12216
|
Interferometry complex
|
|
|
|
|
12217
|
Light beam ducts
|
|
|
|
|
12218
|
Aux. Tel. Tracks/stations
|
|
|
|
|
12219
|
Control/service building
|
|
|
|
|
12220
|
Buildings support functions
|
|
|
|
|
12221
|
Mirror maintenance, building
|
|
|
|
|
12223
|
Utility tunnels/ducts
|
|
|
|
|
12224
|
Dormitories
|
|
|
|
|
12225
|
Warehouse, workshops
|
|
|
|
|
12227
|
Hotel facilities
|
|
|
|
|
12228
|
Office Building
|
|
|
|
|
12229
|
Office, Board and Lodging Facilities
|
|
|
|
|
12230
|
Telescope Piers
|
|
|
|
|
12231
|
Telescope Pier #1
|
|
|
|
|
12232
|
Telescope Pier #2
|
|
|
|
|
12233
|
Telescope Pier #3
|
|
|
|
|
12234
|
Telescope Pier #4
|
|
|
|
|
12240
|
Enclosure foundations
|
|
|
|
|
12241
|
Enclosure foundations #1
|
|
|
|
|
12242
|
Enclosure foundations #2
|
|
|
|
|
12243
|
Enclosure foundations #3
|
|
|
|
|
12244
|
Enclosure foundations #4
|
|
|
|
|
12300
|
Enclosures
|
|
|
|
|
13000
|
OPTICAL INSTRUMENTS
|
|
|
|
|
13100
|
UV-Vis focal reducer instrument
|
|
|
|
|
13110
|
Focal reducer spectrograph (FORS)
|
|
|
|
|
13111
|
FORS 1
|
|
|
|
|
13112
|
FORS 2
|
|
|
|
|
13120
|
Scientific FORS CCD Systems
|
|
|
|
|
13121
|
FORS 1 CCD System
|
|
|
|
|
13122
|
FORS 2 CCD System
|
|
|
|
|
13200
|
UV-Vis Echelle
Spectrograph Instrument
|
|
|
|
|
13210
|
UV-Vis Echelle
Spectrograph (UVES)
|
|
|
|
|
13220
|
Scientific UVES CCD System
|
|
|
|
|
13221
|
UVES CCD System - red
|
|
|
|
|
13222
|
UVES CCD System - blue
|
|
|
|
|
13300
|
Multi-fibre area spectrograph instrument
|
|
|
|
|
13310
|
Multi-fibre area spectrograph
|
|
|
|
|
13311
|
Spectrograph
|
|
|
|
|
13312
|
Fibre
positioner unit
|
|
|
|
|
13320
|
Scientific CCD System
|
|
|
|
|
13400
|
Visible High Angular Resolution Camera
|
|
|
|
|
13510
|
Beam combiner (visible)
|
|
|
|
|
13520
|
High res. Spectrograph instrument
|
|
|
|
|
13600
|
VLT Scientific CCD System
|
|
|
|
|
13610
|
CCD Detectors
|
|
|
|
|
13620
|
Cryostats
|
|
|
|
|
13630
|
PULPO
|
|
|
|
|
13640
|
Fiera
CCD Controller
|
|
|
|
|
13650
|
ACE CCD Controller
|
|
|
|
|
13700
|
FLAMES
|
|
|
|
|
13710
|
FLAMES Corrector
|
|
|
|
|
13720
|
FLAMES OzPoz
|
|
|
|
|
13730
|
FLAMES GIRAFFE
|
|
|
|
|
13740
|
FLAMES Fibre
|
|
|
|
|
13750
|
FLAMES/UVES Link
|
|
|
|
|
13760
|
FLAMES OS
|
|
|
|
|
14000
|
INFRARED INSTRUMENTS
|
|
|
|
|
14100
|
Med. Res. IR Spectrograph/imager (ISAAC)
|
|
|
|
|
14200
|
Near IR High res. Camera (CONICA)
|
|
|
|
|
14300
|
Mid IR Imager/Spectrometer (VISIR)
|
|
|
|
|
14400
|
Multi-channel IR FTS
|
|
|
|
|
14500
|
Cryogenic IR echelle Spectrometer (CRIRES)
|
|
|
|
|
14510
|
MACAO for CRIRES
|
|
|
|
|
14600
|
Vis.
And near IR wide Field multi object spectrograph instruments
|
|
|
|
|
14610
|
Visible multi object spectrograph (VIMOS)
|
|
|
|
|
14611
|
VIMOS S/W
|
|
|
|
|
14612
|
VIMOS H/W
|
|
|
|
|
14613
|
VIMOS Electronics
|
|
|
|
|
14614
|
VIMOS Detector System
|
|
|
|
|
14620
|
Near IR Multi object spectrograph (NIRMOS)
|
|
|
|
|
14630
|
Mask manufacturing unit (MMU)
|
|
|
|
|
14640
|
Scientific CCD Systems
|
|
|
|
|
14650
|
IR detector systems
|
|
|
|
|
14650
|
Xshooter
|
|
|
|
|
14660
|
KMOS
|
|
|
|
|
14670
|
MUSE
|
|
|
|
|
14675
|
AO for MUSE
|
|
|
|
|
14680
|
FALCON
|
|
|
|
|
14690
|
Planet Finder
|
|
|
|
|
14700
|
Sinfoni
|
|
|
|
|
14710
|
MACAO for SINFONI
|
|
|
|
|
14720
|
SPIFFI
|
|
|
|
|
14721
|
2K Camera for SPIFFI
|
|
|
|
|
15000
|
VLT Interferometer (VLTI)
|
|
|
|
|
15100
|
Auxiliary Telescope System (ATS)
|
|
|
|
|
15110
|
Telescope
|
|
|
|
|
15120
|
Transporter
|
|
|
|
|
15130
|
Enclosure
|
|
|
|
|
15140
|
Tools & GSE
|
|
|
|
|
15150
|
ESO Control System
|
|
|
|
|
15160
|
Station equipment
|
|
|
|
|
15170
|
Rails
|
|
|
|
|
15180
|
AMOS Control System
|
|
|
|
|
15200
|
Delay Lines System
|
|
|
|
|
15201
|
Delay Line High-Level Control Software
|
|
|
|
|
15210
|
Basic Delay Line
|
|
|
|
|
15220
|
Variable curvature mirror
|
|
|
|
|
15240
|
Long Supporting Bench
|
|
|
|
|
15300
|
Interferometer Imaging Beam Combiner
|
|
|
|
|
15400
|
Interferometer control system
|
|
|
|
|
15410
|
Central Control
|
|
|
|
|
15420
|
OPD Controller
|
|
|
|
|
15430
|
Fringe sensor Unit
|
|
|
|
|
15431
|
FINITO Detector System
|
|
|
|
|
15440
|
Alignment Units
|
|
|
|
|
15441
|
Pupil Alignment Units
|
|
|
|
|
15442
|
Image alignment units
|
|
|
|
|
15443
|
Delay Constant Metrology
|
|
|
|
|
15444
|
LEONARDO (LEO)
|
|
|
|
|
15445
|
Interferometer Alignment Sensor (IAS)
|
|
|
|
|
15450
|
VLTI Tilt sensor
|
|
|
|
|
15500
|
VLT Transfer Optics
|
|
|
|
|
15510
|
M12 Units
|
|
|
|
|
15511
|
M12 Assembly
|
|
|
|
|
15512
|
M12 Mechanism
|
|
|
|
|
15513
|
M12 Bench
|
|
|
|
|
15514
|
M12 Control System
|
|
|
|
|
15515
|
M12 Tools
|
|
|
|
|
15520
|
M16 Units
|
|
|
|
|
15521
|
M16 Assembly
|
|
|
|
|
15522
|
M16 Mechanism
|
|
|
|
|
15523
|
M16 Bench
|
|
|
|
|
15524
|
M16 Control System
|
|
|
|
|
15525
|
M16 Tools
|
|
|
|
|
15530
|
Beam Comressors
|
|
|
|
|
15531
|
BC Assembly
|
|
|
|
|
15532
|
BC Bench
|
|
|
|
|
15533
|
BC Tools
|
|
|
|
|
15540
|
Beam Switchyard
|
|
|
|
|
15541
|
BS Assembly
|
|
|
|
|
15542
|
BS Mechanism
|
|
|
|
|
15543
|
BS Bench
|
|
|
|
|
15544
|
BS Control System
|
|
|
|
|
15545
|
BS Tools
|
|
|
|
|
15550
|
FSU Feeding Optics
|
|
|
|
|
15551
|
FO Assembly
|
|
|
|
|
15552
|
FO Mechanism
|
|
|
|
|
15553
|
FO Bench
|
|
|
|
|
15554
|
FO Control System
|
|
|
|
|
15555
|
FO Tools
|
|
|
|
|
15560
|
VINCI Feeding Optics
|
|
|
|
|
15561
|
FO Assembly
|
|
|
|
|
15562
|
FO Mechanism
|
|
|
|
|
15563
|
FO Bench
|
|
|
|
|
15564
|
FO Control System
|
|
|
|
|
15565
|
FO Tools
|
|
|
|
|
15570
|
MIDI Feeding Optics
|
|
|
|
|
15571
|
FO Assembly
|
|
|
|
|
15572
|
FO Mechanism
|
|
|
|
|
15573
|
FO Bench
|
|
|
|
|
15574
|
FO Control System
|
|
|
|
|
15575
|
FO Tools
|
|
|
|
|
15580
|
AMBER Feeding Optics
|
|
|
|
|
15581
|
FO Assembly
|
|
|
|
|
15582
|
FO Mechanism
|
|
|
|
|
15583
|
FO Bench
|
|
|
|
|
15584
|
FO Control System
|
|
|
|
|
15585
|
FO Tools
|
|
|
|
|
15600
|
MACAO FOR VLTI
|
|
|
|
|
15700
|
PRIMA
|
|
|
|
|
15710
|
Star Separators
|
|
|
|
|
15720
|
Differential Delay Lines
|
|
|
|
|
15730
|
PRIMA Metrology System
|
|
|
|
|
15731
|
Light Source
|
|
|
|
|
15732
|
Beam Launcher
|
|
|
|
|
15733
|
Metrology end Points
|
|
|
|
|
15734
|
Beam Combiner
|
|
|
|
|
15735
|
Phase Meter
|
|
|
|
|
15736
|
Control HW/SW
|
|
|
|
|
15740
|
PRIMA Fringe Sensor Unit
|
|
|
|
|
15800
|
Interferometer instruments
|
|
|
|
|
15810
|
Instrument #1 - VINCI
|
|
|
|
|
15811
|
Basic instrument
|
|
|
|
|
15812
|
Software
|
|
|
|
|
15813
|
Local control unit
|
|
|
|
|
15814
|
Data/image processing hardware
|
|
|
|
|
15815
|
Data/image processing software
|
|
|
|
|
15820
|
Instrument #2 - MIDI
|
|
|
|
|
15821
|
Basic Instrument
|
|
|
|
|
15822
|
Software
|
|
|
|
|
15823
|
Local Control Unit
|
|
|
|
|
15824
|
Data/image processing hardware
|
|
|
|
|
15825
|
Data/image processing software
|
|
|
|
|
15830
|
AMBER
|
|
|
|
|
15890
|
General data/image processing
|
|
|
|
|
15891
|
Hardware
|
|
|
|
|
15892
|
Software
|
|
|
|
|
15900
|
Interferometer Auxiliary equipment
|
|
|
|
|
15910
|
Alignment Equipment
|
|
|
|
|
15911
|
Tunnel Alignment Reference
|
|
|
|
|
15912
|
Light Duct Alignment Reference
|
|
|
|
|
15913
|
Interferometric Lab Alignment Reference
|
|
|
|
|
17000
|
CENTRAL CONTROL
|
|
|
|
|
17100
|
Computer Environment
|
|
|
|
|
17120
|
LANs
|
|
|
|
|
17130
|
LCUs
|
|
|
|
|
17140
|
Control room installation Paranal
|
|
|
|
|
17200
|
Software
|
|
|
|
|
17210
|
Central Control Software
|
|
|
|
|
17220
|
High level operation software
|
|
|
|
|
17230
|
Telescope control software
|
|
|
|
|
17240
|
Instrument control software
|
|
|
|
|
17300
|
Time reference system
|
|
|
|
|
17400
|
Astronomical Site monitors
|
|
|
|
|
17410
|
Seeing and sky monitor
|
|
|
|
|
17411
|
ASM Tower
|
|
|
|
|
17412
|
ASM enclosure
|
|
|
|
|
17413
|
Seeing and coherence monitor
|
|
|
|
|
17414
|
Cloud and extinction monitor
|
|
|
|
|
17415
|
IR emissivity monitor
|
|
|
|
|
17416
|
Turbulence profiler
|
|
|
|
|
17420
|
Meteorological Station
|
|
|
|
|
17421
|
Mast
|
|
|
|
|
17422
|
Meteorological Sensors
|
|
|
|
|
17423
|
Airborne particle sensor
|
|
|
|
|
17430
|
Control Hardware
|
|
|
|
|
17431
|
Local Control Unit
|
|
|
|
|
17432
|
Control Electronics Cabin
|
|
|
|
|
17433
|
ASM Workstation
|
|
|
|
|
17440
|
ASM Software
|
|
|
|
|
17441
|
ASM Application Software
|
|
|
|
|
17442
|
Modelling Software
|
|
|
|
|
17443
|
Prediction software
|
|
|
|
|
17450
|
Communication Equipment (External meteo
data)
|
|
|
|
|
18000
|
REMOTE SENSING
|
|
|
|
|
18100
|
Communcation Equipment
|
|
|
|
|
18200
|
WAN
|
|
|
|
|
18300
|
Installations Paranal
|
|
|
|
|
18310
|
Multiplexers/modems
|
|
|
|
|
18320
|
Site add-on software
|
|
|
|
|
18400
|
Installations Garching
|
|
|
|
|
18410
|
Multiplexers/modems
|
|
|
|
|
18420
|
Computers
|
|
|
|
|
18430
|
Remote operation software
|
|
|
|
|
19000
|
DFS General
|
|
|
|
|
19100
|
Proposal Handling
|
|
|
|
|
19200
|
Observation handling
|
|
|
|
|
19300
|
Science Archive
|
|
|
|
|
19400
|
Astronomical Catalogue
|
|
|
|
|
19500
|
Data Pipeline
|
|
|
|
|
19600
|
Quality Control
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
21000
|
VST
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
23000
|
OmegaCAM
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
27000
|
VST Enclosure
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
33000
|
HARPS
|
|
|
|
|
34000
|
TIMMI
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
