CHANGE RECORD
|
ISSUE
|
DATE
|
SECTION/
PAGE
AFFECTED
|
REASON/INITIATION
DOCUMENTS/REMARKS
|
|
1.0 / prep 1
|
20/12/2000
|
All
|
NOVEMBER 2000 - First Version by Eszter Pozna
|
|
Update for MAR2001 RELEASE
by E. Pozna
|
|
1.1
|
08/04/2001
|
20,22,23,49,
52,81
|
VLTSW20010019-18:
OCS.SUBSYST setup keyw no
longer supported
|
|
20 (49)
|
VLTSW20010017: always use
INS.MODE is compulsory in the first SETUP
|
|
11,31,36,54,80
|
VLTSW20010014:
STOP cmd is not supported
|
|
15,18,83
|
VLTSW20010054 : OCS.OCS.* à
OCS.OS.*
|
|
26,27,28
|
VLTSW20010012: no alias
tables
|
|
30
|
VLTSW20010044: db
classes for each subsystem interface
|
|
18,26,79
|
Config kw not supported
OCSi.OCS.ALIAS
|
|
25,26,42,51,77
|
Configuration file
xxoControl.cfg->xxmcfgINS.cfg
|
|
36
|
Cancel inactive exposures
using command END
|
|
37
|
Added description to
FORWARD
|
|
41
|
Added new sections in
chapter 9.8 in SOS
|
|
52
|
New section 11.10 db point/structure (FAQ)
|
|
38
|
New section – binary tables
|
|
Update for MAR 2002 RELEASE
by E. Pozna
|
|
ISSUE
|
DATE
|
SECTION
|
REASON/INITIATION/REMARKS
|
|
1.2
|
20/03/2002
|
4
|
VLTI module
|
|
9.8.6.2
|
VLTSW20010618 : Multiple ICS headers
|
|
9.4.5
|
VLTSW20010575 : Wait
–first
VLTSW20020051 : reply to wait command (9.4.5)
|
|
9.5
|
VLTSW20010044:Life cycle
(present in MAR2001 but not
mentioned in doc)
|
|
9.8.6
|
VLTSW20010691:
Partial header files (New section)
|
|
9.8, 9.8.5.3, 9.8.6.3, 9.8.4
|
SOS (new feature in MARCH2002)
Sos interaction new
section 9.8.4
|
|
9.7.2
|
Exposure status
|
|
9.7.4
|
VLTSW20010724:
substates
|
|
9.7.1
|
last expoId (updates)
|
|
9.4.3.1,9.4.3.2,
9.4.3.5
|
VLTSW20010104 : SETUP
(new sections)
While exp running; repeate ; redeclare
|
|
9.4.6
|
VLTSW20010535: END
cmd
|
|
9.4.7
|
VLTSW20010682:
Forward
|
|
9.9.2
|
VLTSW20010013
:default startup
|
|
7.7
|
VLTSW20010494:
default mode
|
|
9.2,10.2
|
User specifed cfg
keyword (AppConfigure argument)
|
|
7
7.2
7.5,
7.3, 7.6
|
Configuration (VLTSW20010010/13, VLTSW20010448)
DBROOT, DBIFROOT
OCS.INSi.HDRCAT ,
default values for DCS/OS cfg kw.
|
|
7.4
|
VLTSW20010448: TELESCOP fits kw (OCS.TEL.ID)
|
|
13
|
Maintenance of boss
|
|
11
|
FAQ added questions
|
|
Reference
|
updated
|
|
Appendix
|
updated
|
|
Update for APR2003 RELEASE
by E. Pozna
|
|
ISSUE
|
DATE
|
SECTION
|
REASON/INITIATION/REMARKS
|
|
3
|
30/03/2003
|
7.7
|
VLTSW20020342- max number
of modes
|
|
10.1.1
|
VLTSW20020180
added overload able function SetupPostProc
|
|
10.6
|
VLTSW20010458/VLTSW20020360/
VLTSW20020583
Operation bypassing the OS/SOS (new section)
|
|
9.4.3.4
|
VLTSW20020256 SETUP –noExposure
(new subsection )
|
|
9.4.5
9.7.5
11.16
|
VLTSW20010669: WAIT -header
Synchronization (new section)
|
|
11.6.2
|
VLTSW20020478
additional fits header keywords at SOS level (new section)
|
|
9.6.1
|
VLTSW20020427: supplementary
'arf' files are removed
|
|
7.3
|
VLTSW20020281: added
optional detector configuration keyword: OCS.DETi.WIPING to set wiping
|
|
7.3
|
VLTSW20020280: added
optional detector configuration keyword: OCS.DETi.STOP to leave detector
ONLINE
|
|
9.6
|
VLTSW20020431: auto add cfg and setup kws to FITS
header
VLTSW20010669: each exposure starts with a new empty
header
|
|
9.7.4
|
Added new substates
|
|
6.6
10.2
|
New section about
dictionaries
Updated with
dictionary info
|
|
11.17
|
FAQ special online
action
|
|
9.4.3.3
|
Default mode (1 mode)
– new section
|
|
Appendix
|
CDT,dict,cfg updated
|
|
Update for APR2004 RELEASE
by E. Pozna
|
|
ISSUE
|
DATE
|
SECTION
|
REASON/INITIATION/REMARKS
|
|
4
|
30/03/2004
|
7.1
|
VLTSW20030249
- added new cfg kw OCS.CON.LOGLEVEL
|
|
8
|
VLTSW20020505 - new 'image
file naming' scheme is applied as default : "Standard-Naming"
|
|
9.4.5
|
VLTSW2003312 - added new parameter '-cond' to command WAIT
|
|
9.4.5
|
VLTSW2003350 - added new parameter '-all' to command
WAIT
|
|
7.1
|
VLTSW20030387 – new configuration
keyword OCS.ARC.TIMEOUT
|
|
9.4.3.4
|
VLTSW20030119 - SETUP
cmd without paremeter '-expoId' specified is considered as –noExposure
|
|
10.1.1
|
VLTSW20030388 - Added overloadable empty functions
ApplImageHandleProc()
|
|
7.3
|
VLTSW20030149 - When
cfg kw OCS.DETi.STOP is set, cmd ONLINE is only sent when state is not yet
ONLINE.
|
|
9.4.9
|
VLTSW20030250 New command ACCESS
|
|
9.10
|
New section: archiver
process
|
|
11.16
|
FAQ updates
|
|
Appendix
|
Manpage,CDT,
dictionary update
|
|
Update for JAN2006 RELEASE
by E. Pozna
|
|
ISSUE
|
DATE
|
SECTION
|
REASON/INITIATION/REMARKS
|
|
5
|
06/12/2005
|
7.3
9.6.3
|
VLTSW20040364 Handling of
multiple files during one exposure (e.g. IR mosaic mode)
|
|
6.1
9.4.5
9.7.2
9.10
|
VLTSW2004025, VLTSW20030523 Sequential handling of archiver
process queue ;
VLTSW20040387 Check
existence of Archiver process
VLTSW20050050 Performance
test of Archiver process (9.10
new section)
|
|
9.4.2
|
VLTSW20040155 Check TCS state during ONLINE
VLTSW20050122 Report error
of sub-command
|
|
7.5
9.7.5
|
VLTSW20020714 ICS Check for ICS substate before
internal commands (EXPEND/EXPSTART) are sent
VLTSW20050161 - Collect all available headers in case of error after
image has been generated
|
|
9.4.6
|
VLTSW20050161 - Command
END is allowed in STANDBY state.
|
|
6.12.
|
Default loglevel - no
long on stdout.
|
|
8
|
Usage of OCS.DET.IMGEXT in setting the filename.
|
|
7.2
|
Maximum number of
dictionaries per interface
|
|
10.1, 10.1.2
|
Overloading boss (new
section)
|
|
Update for FEB2007 RELEASE
by E. Pozna
|
|
ISSUE
|
DATE
|
SECTION
|
REASON/INITIATION/REMARKS
|
|
6
|
09/02/2007
|
9.6.3
|
VLTSW20060018- Sort the
fits extentions into Alphabetical order (OCS.DETi.ARCMODE MERGEALL)
|
|
9.4.8
|
VLTSW20060232-Support
ADDFITS command options -extnum –extname
|
|
9.6.3
|
VLTSW20050387 Handle DIT
files without merging
(OCS.DETi.ARCMODE NORMAL)
|
|
9.4.5.1, 7.3
|
VLTSW20060119 Support of Optimised sequence of exposures on IRACE
detector (OCS.DET.OPTSEQ).
|
|
|
|
TABLE OF
CONTENTS
1 Scope................................................................................................................................................................................................ 3
2 Documents and Acronyms................................................................................................................................................ 3
2.1 Applicable Documents................................................................................................................................................ 3
2.2 Reference Documents.................................................................................................................................................. 3
2.3 Acronyms............................................................................................................................................................................ 3
3 Introduction.............................................................................................................................................................................. 3
4 Overview....................................................................................................................................................................................... 3
5 User’s Guide.................................................................................................................................................................................. 3
6 Getting Started........................................................................................................................................................................ 3
6.1 The processes of the Observation Software............................................................................................... 3
6.2 Initializing......................................................................................................................................................................... 3
6.3 Server class....................................................................................................................................................................... 3
6.4 State handling................................................................................................................................................................ 3
6.5 Configuration.................................................................................................................................................................. 3
6.6 Dictionary.......................................................................................................................................................................... 3
6.7 Command handling...................................................................................................................................................... 3
6.8 Database events............................................................................................................................................................ 3
6.9 Interfaces........................................................................................................................................................................... 3
6.10 Exposures............................................................................................................................................................................ 3
6.11 OS as Super OS.................................................................................................................................................................... 3
6.12 Logging.................................................................................................................................................................................. 3
7 Configuration Guide.............................................................................................................................................................. 3
7.1 General system configuration
keywords................................................................................................... 3
7.2 Configuration of the subsystems....................................................................................................................... 3
7.3 Additional detector configuration keywords........................................................................................ 3
7.4 Additional TCS configuration keywords..................................................................................................... 3
7.5 Additional ICS configuration keywords....................................................................................................... 3
7.6 OS Subsystem Configuration Keywords.......................................................................................................... 3
7.7 Instrument modes......................................................................................................................................................... 3
8 Setup Guide.................................................................................................................................................................................... 3
9 Programmer’s Guide.............................................................................................................................................................. 3
9.1 Initialisation................................................................................................................................................................... 3
9.2 The Server class.............................................................................................................................................................. 3
9.3 Interface classes.......................................................................................................................................................... 3
9.4 Standard commands.................................................................................................................................................. 3
9.4.1 STATE Command and related functions....................................................................................................................... 3
9.4.2 State changing commands.............................................................................................................................................. 3
9.4.3 SETUP Command.............................................................................................................................................................. 3
9.4.4 START Command.............................................................................................................................................................. 3
9.4.5 WAIT Command................................................................................................................................................................. 3
9.4.6 Other exposure control commands................................................................................................................................ 3
9.4.7 FORWARD command........................................................................................................................................................ 3
9.4.8 Commands operating on fits file.................................................................................................................................... 3
9.4.9 ACCESS command............................................................................................................................................................ 3
9.4.10 Commands VERSION and DEBUG........................................................................................................................... 3
9.5 Database and database events.......................................................................................................................... 3
9.6 The final image................................................................................................................................................................ 3
9.6.1 Partial header files........................................................................................................................................................... 3
9.6.2 Binary Tables..................................................................................................................................................................... 3
9.6.3 Handling of multiple files during one exposure.......................................................................................................... 3
9.7 Exposure............................................................................................................................................................................... 3
9.7.1 The exposure table............................................................................................................................................................ 3
9.7.2 Exposure status................................................................................................................................................................. 3
9.7.3 Functions accessing
the exposure table...................................................................................................................... 3
9.7.4 Main steps of exposure..................................................................................................................................................... 3
9.7.5 Synchronization................................................................................................................................................................ 3
9.8 Super Observation Software (SOS)...................................................................................................................... 3
9.8.1 Configuration of OS subsystem...................................................................................................................................... 3
9.8.2 Hierarchical setup keywords.......................................................................................................................................... 3
9.8.3 Dictionary for SOS............................................................................................................................................................ 3
9.8.4 SOS interaction................................................................................................................................................................. 3
9.8.5 Command handling.......................................................................................................................................................... 3
9.8.6 Creating the finale image file by SOS........................................................................................................................... 3
9.8.7 Not-BOSS-based OS as a subsystem of SOS................................................................................................................. 3
9.9 Startup of Main process........................................................................................................................................... 3
9.9.1 Command line options..................................................................................................................................................... 3
9.9.2 Default Startup.................................................................................................................................................................. 3
9.10 Archiver process............................................................................................................................................................ 3
9.10.1 Startup of Archiver Process....................................................................................................................................... 3
9.10.2 Command queue.......................................................................................................................................................... 3
9.10.3 Performance
of Archiver process.............................................................................................................................. 3
10 Observation Software Based on BOSS.................................................................................................................... 3
10.1 Function overloading................................................................................................................................................ 3
10.1.1 Functions to be overloaded....................................................................................................................................... 3
10.1.2 Overload of non empty functions.............................................................................................................................. 3
10.2 Additional configuration keyword................................................................................................................ 3
10.3 Additional setup keyword...................................................................................................................................... 3
10.4 Add new command........................................................................................................................................................ 3
10.4.1 Send a message............................................................................................................................................................ 3
10.5 Modifying existing command callbacks....................................................................................................... 3
10.5.1 Declare mode, detector, subsystem, exposure status............................................................................................. 3
10.6 Operation bypassing the OS/SOS............................................................................................................................ 3
11 FAQ and Troubleshooting................................................................................................................................................ 3
11.1 Manual start up of BOSS OS.................................................................................................................................... 3
11.2 Parameter ‘-expoId’ in the commands............................................................................................................. 3
11.3 Subsystem list or instrument mode is not declared in the setup................................................. 3
11.4 Usage of command STATUS...................................................................................................................................... 3
11.5 Usage of command ADDFITS..................................................................................................................................... 3
11.6 Add additional keyword to the fits header.............................................................................................. 3
11.6.1 Example-1: Add keyword to OS image.................................................................................................................... 3
11.6.2 Example-2: Add keyword to SOS image file........................................................................................................... 3
11.7 Dictionary for OS........................................................................................................................................................... 3
11.8 Parameter ‘-detId’ in command........................................................................................................................... 3
11.9 Place of pre-processing functions...................................................................................................................... 3
11.10 Instrument with no detector............................................................................................................................... 3
11.11 Data base point ‘NewData’..................................................................................................................................... 3
11.12 Additional Action when Exposure fails, succeeds or aborted...................................................... 3
11.13 Interface for subsystem that does not fall into any of the given
categories.................. 3
11.14 What to do when OS subsystem of SOS is not based on BOSS............................................................. 3
11.15 TCS in the SOS structure............................................................................................................................................ 3
11.16 File merging........................................................................................................................................................................ 3
11.17 Add Special Online Action........................................................................................................................................ 3
12 Installation Guide................................................................................................................................................................. 3
13 Maintenance................................................................................................................................................................................ 3
14 Reference...................................................................................................................................................................................... 3
14.1 Manpage of the bossControl................................................................................................................................. 3
14.2 Manpage of the bossSERVER class....................................................................................................................... 3
14.3 Manpage of bossAbortCB, bossStartCB, bossPauseCB…....................................................................... 3
14.4 Manpage of bossEXPOSURE class.......................................................................................................................... 3
14.5 Manpage of bossINSMODE class............................................................................................................................ 3
14.6 Manpage of bossINTERFACE_DCS............................................................................................................................ 3
14.7 Manpage of bossINTERFACE_CCD............................................................................................................................ 3
14.8 Manpage of bossArchiver................................................................................................................................... 3
This
page has been left intentionally blank.
This document describes the BOSS package.
The following documents, of the exact issue shown, form a
part of this document to the extent specified herein. In the event of conflict
between the documents referenced herein and the contents of this document, the
contents of this document shall be considered as a superseding requirement.
|
Reference
|
Document Number
|
Issue
|
Date
|
Title
|
|
[AD 01]
|
GEN-SPE-ESO-19400-0794
|
2.0
|
31/10/1997
|
DICB - Data Interface Control Document
|
|
[AD 02]
|
VLT-SPE-ESO-10000-0011
|
2.0
|
30/09/1992
|
VLT
Software Requirements Specification
|
|
[AD 03]
|
VLT-PRO-ESO-10000-0228
|
1.0
|
10/03/1993
|
VLT
Software Programming Standards
|
|
[AD 04]
|
VLT-PLA-ESO-10000-0441
|
1.0
|
01/05/1995
|
VLT
Science Operation Plan
|
|
[AD 05]
|
VLT-MAN-ESO-17210-0667
|
1.0
|
03/12/1997
|
Guidelines
for VLT applications.
|
|
[AD 06]
|
VLT-SPE-ESO-17212-0001
|
2.0
|
23/02/1995
|
INS
Software Specification
|
|
[AD 07]
|
VLT-SPE-ESO-17240-0385
|
2.1
|
15/07/1996
|
INS
Common Software Specification
|
|
[AD 08]
|
VLT-ICD-ESO-17240-19400
|
2.6
|
17/11/1997
|
ICD
between VCS and Archive
|
|
[AD 09]
|
VLT-ICD-ESO-17240-19200
|
1.0
|
29/10/1996
|
ICD
between VCS and OH
|
|
|
|
|
|
|
The following documents contain additional information and
are referenced in the text:
|
Reference
|
Document Number
|
Issue
|
Date
|
Title
|
|
[RD 01]
|
VLT-MAN-ESO-17240-1973
|
2.0
|
03/01/2001
|
|
|
[RD 02]
|
VLT-SPE-ESO-15400-0886
|
2.0
|
18/12/1996
|
XXXX
ICS
|
|
[RD 03]
|
VLT-MAN_ESO-17110-0771
|
1.7
|
30/09/1999
|
CCS-Event Tool Kit –EVH
|
|
[RD 04]
|
VLT-MAN_ESO-17240-0853
|
1.1
|
06/05/1996
|
Objective SLX-OSLX
|
|
[RD 05]
|
|
|
|
VLT
SW Installation
|
|
[RD 06]
|
VLT-ICD-ESO-17240-19400
|
2.0
|
17/11/97
|
VLT
Archive System
|
|
[RD 07]
|
VLT-MAN-ESO-17240-0672
|
1.6
|
25/09/98
|
CCD
Detectors Control Software-User Manual
|
|
[RD 08]
|
VLT-MAN-ESO-13640-1388
|
1.1
|
22/11/99
|
FIERA
CCD Controller –Software User Manual
|
|
[RD 09]
|
VLT-MAN-ESO-14100-1878
|
1.2
|
13/12/99
|
IRACE
DCS User Manual
|
|
[RD-10]
|
VLT-MAN-ESO-17240-2325
|
1.0
|
10/10/2000
|
Configuration
Tool User Manual
|
|
[RD-11]
|
VLT-MAN-ESO-17240-
2153
|
1.3
|
|
Startup
Tool
|
This document employs several abbreviations and acronyms to
refer concisely to an item, after it has been introduced. The following list is
aimed to help the reader in recalling the extended meaning of each short
expression:
|
|
|
|
OS
|
Observation Software
|
|
BOSS
|
Base
Observation Software Stub
|
|
XXXX
|
Template
instrument
|
|
XXXX ICS
|
Template
instrument ICS
|
|
XXXX OS
|
Template instrument OS
|
|
OS
|
Observation Software
|
|
SOS
|
Super OS. An OS that also controls OS.
|
|
<CAT>
|
Category denoting detector, instrument, telescope or OS subsystem
|
|
single exposure
|
One exposure.
|
|
parallel exposure
|
Exposures started at the same time
|
|
semi-parallel exposure
|
Exposures running simultaneously. Started separately from
each other.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This version of the UM describes the behavior of the BOSS
package JAN2006 version.
The Observation software is responsible for taking exposures.
Typically there is one image file generated during an exposure, and the
exposures are executed sequentially. The concept of exposure refers to a whole
series of procedures which begins with the setup of the instrument,
preparation/start/monitoring of observation, handling of any user or system
input, and ends with the finale handling of the image file during which all
relevant information is saved into the header of the fits file and the image is
sent to archive.
Nevertheless due to diverse requirements the OS is also
capable of handling situations such as:
-
more data files are generated during one exposures
-
exposures are executed simultaneously on different
detectors
-
queuing the final handling of the image files for
optimized exposure sequence
-
setup of new exposures while previous one is still
running
-
controlling special subsystem
-
ignoring part of the system
-
supervising other OS-es.
The OS coordinates the communication between the subsystems
of an instrument (ICS-es, DCS-es) and the telescope, handles user interaction
with the system at any times (such as
ending or aborting an exposures) and reports any unexpected events or errors
occurring at all levels at any time.
The BOSS software (BOSS is short for base observation
software stub) is designed to incorporate the common features of all
observation software, while the OS that is based on BOSS should incorporate the
specialties characterizing the instrument.
The observation software of a specific instrument
therefore consists of a
·
an instrument independent part (BOSS), and
·
an instrument specific part (OS).
Boss includes the implementation of all the standard
commands [AD 07]. In special cases, the default
process can be extended. The communication with the subsystems takes place
through interfaces. The package includes suitable interfaces for the most
commonly used subsystems. When an exposure is finished, the VOLAC system [RD 06] is informed about the event (through a database
point) to archive the image.
During the development of an OS one must exploit the
features and functionality of BOSS as much as possible. This would make sure
that the application OS-es have the least size, and therefore make the
maintenance of the software easier.
The development of an OS is described through an example [RD 01]. The implementation of the most commonly used extra
features (such as additional command or keyword) are described in Chapter 10.
Before going through the details of BOSS, it is recommended
to install template instrument [RD 01] and run
some templates. This would allow you to try out the features described in the
following chapters and gain better understanding of the responsibilities of theerstanding what ang to it and sending it to
archive and clean up t OS.
The BOSS software package consist of the following modules:
|
Module
|
Description
|
|
ibac
|
Instrument Basic Application Classes
Includes handling of logs, bits, strings, list ..
|
|
ixac
|
Instrument Extended Application Classes
This module contains classes to handle common VLT data
types (e.g. Short Fits Keywords, Database,…)
|
|
boss
|
Base Observation Software Stub
Incorporates the implementation of the common properties
of OS
|
|
osb
|
Interface module including the dictionary and CDT of
boss
(
ESO-VLT-DIC.BOSS, bossSERVER.cdt)
|
|
bossvlti
|
Necessary only for VLTI instruments
This small module contains the interface for ISS.
|
Release versions numbers:
MAR2001: boss 1.35.1.3, osb
1.12, bossvlti 1.2, ixac 1.37, ibac
1.26
MAR2002: boss 1.81, osb
1.20, bossvlti 1.5, ixac 1.43, ibac
1.29
APR2003: boss 1.106, osb
1.24, bossvlti 1.5, ixac 1.45, ibac
1.29
APR2004: boss 1.129, osb
1.28, bossvlti 1.6, ixac 1.46, ibac
1.30
JAN2006: boss 1.153, osb
1.36, bossvlti 1.6, ixac 1.49, ibac
1.33
FEB2007: boss 1.163, osb
1.39, bossvlti 1.6, ixac 1.51 , ibac 1.33
The Template
Instrument User Manual [RD 01] introduces a virtual instrument XXXX with
the basic characteristics of real instruments, and also incorporates an
observation software based on BOSS. Users are suggested to install and startup
the template instrument and experience the effect of the OS commands by running
a BOB template. Having an instrument running you gives a chance to test immediately
the various features described below.
The Observation Software of an instrument consists of two
processes:
·
‘Main Control Process’
It is a multipurpose process the functionality of which is
described in detail in this document.
The name of the process is ‘xxoControl’ where xx is the instrument ID. Only in case of complex instruments (handling
more then one instruments by a super OS) it is allowed to have more then one OS
Main process in the system.
·
‘Archiver Process’
The ‘File Handler
Process’ is an auxiliary process that handles the post-processing of data, i.e.
merging image file with header files. The process also takes care of informing
VOLAC when the final image is ready. The name of this auxiliary process is
composed of the string ‘bossArchiver_’ and the instrument id, e.g.:
‘bossArchiver_xxo’.
BOSS takes care
of the communication between the ‘Main Control Process’ and the ‘Archiver
Process’. There should be only one Archiver process for each control process.
The existence of the Archiver process is checked by the Main process when the
instrument is set to ONLINE and also at the start of the image taking
exposures.
The subtasks of
merging (i.e. names of header files, binary tables to be merged/appended
/deleted) are sad ged / appended extendees u have ty running a
BOB template. ved in a supplementary file with extension ‘<imageFileName>.arf’,
which is removed after the final image is ready. (When the process is started
up in debug mode the supplementary files are renamed as ‘.arf_’ after successful
handling, however all the ‘<imageFileName>.arf_’ files are removed during
the startup of the Archiver process.)
BOSS also takes
care of queuing the commands for the Archiver process should the requests from
the Main process come faster then they are processed by the Archiver (see also 9.4.5).
The processes of
the Instrument OS must be started at the same time.
For more information on the
Archiver process see 9.10.
There is a
support class (bossCtrlMain.C) included in BOSS to support initialising and exiting CCS, initialising
the boss ‘Main Control Process’, and setting the verbose level according to the
command line options (see Chapter 9.1). The developers are recommended to apply it
following the pattern of the main function of the template instrument [RD 01].
The heart of the
boss package is the bossSERVER class. The default functionalities of BOSS can
be altered when necessary.
The bossSERVER
class includes special (normally empty) functions. In these functions (i.e. in
their overloads) the implementation of the additional properties of the
instruments should be placed.
Note that overloading
other functions is also possible (as most of the function of the bossSERVER are
declared virtual),
however it is not recommended.
In some cases the default properties of BOSS fully satisfies
the requirement of an instrument. In this case the instrument can be startup
based on its configuration and database using the auto startup functionality
(see section 9.9.2).
The bossSERVER takes care of handling the states and
sub-states of the instrument.
The states of the subsystems are [AD 07]: OFF, LOADED,
STANDBY, ONLINE.
The state of the instrument is normally associated with the
state of its subsystems and it represents the minimum states of all the
subsystems. Therefore when one of the subsystems is state OFF, the global state
of the instrument is also OFF.
Whether the OS is running (i.e. it is loaded or shutdown)
can be checked separately from the global state. OS process is alive,
thus it is either ONLINE or OFF.
When the global state of the instrument is ONLINE the OS is
ready to accept commands, the execution of which is reflected in the substate
of the instrument: e.g. SETUP, OBSERVING, PAUSED, IDLE, see also section 9.7.4.
The instruments are configured via Application Configuration
Files. These files (that should be placed in a separate module) contain
information about the individual subsystems and the OS of the instrument and
also startup options.
The configuration of the OS of an instrument (Section 7) consists of the declaration of its subsystems
(Section 7.2, 7.3, 7.6) and the instrument modes (Section 7.7).
The configuration and setup keywords are declared in
dictionaries, where the configuration keywords are checked during startup and
the setup keywords are checked during runtime.
The
common configuration and setup keywords regarding the OS are specified in
dictionary
ESO-VLT-DIC.OSB.
Any additional instrument specific configuration and setup keywords
must be specified by the user.
The additional configuration keywords should be included in
the dictionary ESO-VLT-DIC.<INSNAME>_CFG.
Note that as the
configuration file is handled by the configuration tool (ctoo) the dictionary
(which contains the additional configuration keyword) must be also set as part
of the instrument configuration [RD-10]. Section 10.2 explains how to add additional configuration
keywords.
Additional setup keywords (see also 10.3) should be specified in the dictionary named:
ESO-VLT-DIC.<INSNAME>_OS.
The
following dictionaries are automatically loaded by BOSS:
ESO-VLT-DIC.OBS
ESO-VLT-DIC.OSB
ESO-VLT-DIC.TPL
ESO-VLT-DIC.<INSNAME>_OS
ESO-VLT-DIC.DPR
BOSS supports the
handling of the following commands:
ABORT, ADDFITS, ACCESS,
COMMENT, CONT, DEBUG, END, EXIT, FORWARD, OFF, ONLINE, PAUSE, PING,
SETUP, STANDBY,
START, STATE, STATUS, WAIT, VERSION
Normally the
commands are declared in templates and sent to an OS by BOB. Nevertheless the
commands can be also sent directly to the OS (using e.g. testscripts or GUI).
Handling these commands
BOSS takes care of the necessary communication between its subsystem. It sends
(synchronous and asynchronous) messages to the subsystems and synchronises
their replies.
The state and
substate of the OS is updated according to the actions of the given command.
The default
implementation of the commands callbacks are placed in the class bossSERVER.
For more
information about the details of the procedures see Chapter 9.4.
During the initialization BOSS attaches database events to
some of the database points of the subsystems of the instrument. These database
events are playing an important role in the synchronization process of BOSS.
The addresses of the relevant database points - status,
state, newdata - are given in the configuration file.
For more details see Chapter 9.5.
BOSS includes several interface
classes through which the communication between OS and the instrument’s
subsystems can take place. These are:
bossINTERFACE, bossINTERFACE_ICS,
bossINTERFACE_TCS,
bossINTERFACE_OCS, bossINTERFACE_DCS,
bossINTERFACE_CCD,
bossINTERFACE_IRACE, bossINTERFACE_TCCD, bossINTERFACE_FIERA
The subsystems are declared in
the configuration file however the interfaces for them have to be declared in
SERVER class of the instrument (see Chapter 9.2). Each subsystem must be coupled to an interface. It
is also essential to build the database according to the subsystems.
BOSS stores the declared
interfaces on its internal subsystem list. The interfaces are identified by the
name of their belonging subsystem. (The names of the subsystems are given in
the configuration file.)
The exposures that can be handled by BOSS fall into the
following categories:
Single exposure: Single
exposure.
The looping TCCD (without
image is saved) belongs to also this category.
Parallel
exposures: Two or more exposures are handled
simultaneously. Exposures are started at the same time, and have the same
expoId. Only one single START command is used to start the exposures (see Figure 1).
Semi-Parallel
exposure: Exposures are running simultaneously (see Figure 2), however they are handled independently from each other, and
each exposure has its unique exposure id. The exposures are started separately.
Figure 1 Example for parallel exposure
Figure 2 Example for semi-parallel exposure
Each time an exposure is declared by the user (through the
command SETUP) BOSS adds the exposure to its internal exposure table, that is
also represented in the database. The exposure table is updated each time when
the state, mode, filename, etc of an exposure is modified (see also Section 9.7.1, Table
9). In case of error it could be useful to check
exposure table.
The exposures are identified by their exposure id-s. Before
an exposure can be started the detector (or detectors) with which the exposure
is taken must be uniquely identified. (See also declaration of mode, and
parameter detId of the commands).
An OS become SOS (see Chapter 9.8) when one or more of its subsystem is an OS. The
configuration of an SOS (Chapters 7.6, 9.8.1) is similar to the configuration of a normal OS.
To setup the parameters of the subsystems on lower levels
hierarchical keywords are used (see section 9.8.2)
Logging can help detecting bugs or understanding the
behavior of the code. The different type of logs are declared in the module
ibac. There are five types of logs, which will appear according to command line
or start up options. Developers are recommended to apply these logs in the OS
application. Please see below the application of these logs (for more
information, see man pages of ibac
and ibacLog):
Note that as default nothing is looged on the stdout. The
loglevel can be changed via commandline option and the command DEBUG.
Warning log:
Log data into the standard VLT log file and to the stdout
(if verbose is specified). The level is put to 1. This procedure is called when
there are errors or abnormal events for application
WarningLog
("A configuration file has to be specified");
WarningLog
("Could not read database attribute %s.",dbaddr);
Info log:
Log data into the standard VLT log file and to the stdout
(if verbose is specified). the level is put to 2. This procedure is called when
operational mode is modified.
InfoLog("Checking
FITS header file '%s'", fitsHdrFile);
InfoLog("Getting
TCS FITS header at start of exposure");
Action log:
Log data into the database attribute dependent on the level
specified. Log data into the standard VLT log file and to the stdout.
ActionLog(1,
"Cleaning up done.");
ActionLog(1,
"%s command failed", msg.Command());
Test log:
Log data into the standard VLT log file and to the stdout
(if verbose is specified). The level is put to 3.
TestLog("
expoId: %d ; detector :%s ",expoId, (char*)detId);
TestLog("Handling
the DB event from attribute '%.80s'",dbaddr);
Debug log:
Log data into the standard VLT log file and to the stdout
(if verbose is specified). The level is put to 5. This procedure is called when
users want more detailed debugging information.
Recommended to add at the beginning of each function.
ExtDbgLog("bossSERVER::OnlineCB()");
ExtDbgLog("bossEXPOSURE::GetSubsystems(expoId
:%d)",expoId);
The OS is configured via configuration file [AD 07].
In this configuration file the basic information about the
instrument (name, prefix, database) and its subsystems (that are to be
controlled by the OS) must be declared.
The subsystems that can be handled by BOSS fall into the
following categories:
DET: detector subsystem
INS: instrument subsystem
OS: OS subsystem (in case of SOS)
TEL: telescope
These categories are also referred as <CAT> below. If
there are more than one subsystem belonging to the same category they must be
indexed.
Some keywords must be declared for all type of subsystems
(Chapter 7.2) while others only for certain type of subsystems.
Many configuration parameters have default values. When the default value is
applicable the keyword can be omitted from the configuration. The optional
keywords are written by italic letters in the tables.
The instrument modes (see Chapter 7.7) must be also declared in the configuration file to
make the SETUP simpler.
The configuration file is handled by the bossSERVER class.
It configures the interface classes for the given subsystems, and stores the
defined modes in its internal mode table, that is also represented in the
database. (See classes bossINS_MODES and bossMODES_TABLE_ENTRY on figure Figure 3.)
For an example of a complete configuration of an instrument
please take a look at the configuration of the template instrument OS [RD 01]
in the Appendix 1.
Note that the configuration of the ICS [AD 06, AD 07,RD 02]
itself is also placed togethere with the OS configuration but here only the
keywords relationg to the OS are described.
Here only the keywords that are relevant to the OS are
described.
Table 7.1 Configuration of the subsystems
|
Configuration
keyword
|
Short description
|
|
INS.CON.ID
|
Instrument identifier
|
|
INS.CON.PREFIX
|
Name prefix for modules and
servers
|
|
OCS.CON.OSDBROOT
|
Database point of the intrument OS itself
(optional).
|
|
OCS.CON.ORIGIN
|
Origin
|
|
OCS.CON.RELEASE
|
Release date
|
|
OCS.ARC.TIMEOUT
|
Archiver timeout
(optional).
|
|
OCS.CON.LOGLEVEL
|
Log level (optional).
|
The name of the instrument and the two letter instrument
code always have to be supplied in the configuration.
Name of the
instrument:
INS.CON.ID "XXXX";
Two letter
instrument code:
INS.CON.PREFIX "xx";
Database address of
the OS of the instrument:
OCS.CON.OSDBROOT
“<alias>xxo”;
The default value for OSDBROOT is: “:Appl_data:<INS.CON.ID>:OS”;
Archiver timeout:
OCS.ARC.TIMEOUT 60;
The support process of the OS -called the ‘archiver process’- takes
care of the merging of the images. Via this keyword the time -as default 60
sec- allowed to handle one image can be
altered.
Loglevel:
OCS.CON.LOGLEVEL 1;
This is an optional configuration keyword, which only taken into
account if the logging level otherwise not specified as command line option
(see section 11.1).
Value of this keyword should be 1 to 5 which corresponds to the gradual
increase of Acton/Log/Verbose level (see also 6.12).
Default value is 0.
General information about origin, release date can be
supplied by keywords
OCS.CON.ORIGIN and
OCS.CON.RELEASE.
Table 7.2 Configuration of the subsystems
|
Configuration
keyword
|
Short description
|
|
OCS.<CAT>.NUM
|
Number of subsystem
belonging to the given category.
|
|
OCS.<CAT>i.NAME
|
name of the subsystem
|
|
OCS.<CAT>i.ACCESS
|
access mode of the
subsystem: NORMAL, IGNORE,FORBIDDEN
|
|
OCS.<CAT>i.DICTi
|
Dictionary of the subsystem
: ESO-VLT-DIC.XXXX
|
|
OCS.<CAT>i.ENVNAME
|
Environment name where
process of the subsystem is running
|
|
OCS.<CAT>i.PROCNAME
|
name of process of the
subsystem
|
|
OCS.<CAT>i.KEYWFILT
|
Keywords that are forwarded
to the subsystem
|
|
OCS.<CAT>i.TIMEOUT
|
|
|
OCS.<CAT>i.DBROOT
|
The database address of the subsystem (optional).
|
|
OCS.<CAT>i.DBSTATE
|
db address of ‘state’ (optional)
|
|
OCS.<CAT>i.DBIFROOT
|
The database address of the subsystem interface
(optional).
|
Number of
subsystems - OCS.<CAT>i.NUM
The number of the subsystems of
the given category is a required information for the startup tool [RD-11] therefore should be placed in the configuration file.
Note that this keyword is not
available for TCS subsystem, as there can be only one TCS.
E.g.: OCS.DET.NUM
2
denotes that there are two DCS
subsystems , e.g. one FIERA and one TCCD.
Name of subsystem -
OCS.<CAT>i.NAME
The individual subsystems can be
referred to by their NAME-s. The names can be up to 32 character long,
nevertheless it is recommended to use short names.
Note that in case of Unit telescope (TEL) the name is
restricted to have the following values:
“UT1”, “UT2”, “UT3”, “UT4”. (UT0 can be used when TCS is in
simulation)
Access mode of
subsystem- OCS.<CAT>i.ACCESS
As the examples below show, the
ACCESS of a subsystem can have three values:
OCS.DET1.ACCESS "NORMAL"
OCS.DET2.ACCESS "FORBIDDEN"
OCS.TEL.ACCESS "IGNORE"
In normal operation mode the
subsystem process must be properly installed and ready to be started up. In
this case the ACCESS modes must be set to NORMAL.
When the subsystem is IGNORED all
request (i.e. messages) to the subsystem will be ignored, i.e. considered as
successfully finished. This option can be used during development when the
process for the subsystem is not yet available, or just simply make the tests
quicker. When a subsystem is ignored its state has no impact on the global
state of the instrument.
When during operation one of the
subsystem goes out of order its access mode should be switched to FORBIDDEN.
This forbids the usage of this subsystem. In this case all request to the
subsystem are rejected (error message is sent).
Dictionary of
subsystem - OCS.<CAT>i.DICTi
Only the ‘tail’ of the dictionary
of the subsystem must be given, i.e: XXXX for a dictionary ESO-VLT-DIC.XXXX.
More then one dictionary can be
supplied using indexes.
E.g.: OCS.INS.DICT1 "ICS_AA"
OCS.INS.DICT2 "ICS_BB"
Please note that
the maximum number of dictionaries per subsystem is 20.
Dictionary for
additional configuration keywords should be specified differently please see
also section 6.6 and for an example section 10.2.
Environment name - OCS.<CAT>i.ENVNAME
e.g.:
OCS.INS.ENVNAME "wxxxx"
Note
that the environment where the process is running, should not be given
by environment variable, eg,.: $RTAPENV.
On
the contrary, the environment variables are set according to the configuration
file.
Keyword filter- OCS.<CAT>i.KEYWFILT
The keywords in the setup that
match the pattern will be forwarded to the subsystem.
When more the one filter id
given, they must be separated by a comma.
E.g.: OCS.DET2.KEYWFILT
"DET2.*.*.*.*.*.*,DET.*.*.*.*.*.*"
Timeout - OCS.<CAT>i.TIMEOUT
Must be given in seconds.
Database address of
subsystem - OCS.<CAT>i.DBROOT
Must be supplied when other then
default, e.g.:
OCS.DET3.DBROOT "<alias>fiera";
Default values:
DCS: "<alias><INS.CON.ID>:DCS:<OCS.DETi.NAME>"
ICS: "<alias><INS.CON.ID>:<OCS.INSi.NAME>"
TCS: "<alias>TCS"
OS: "<alias><INS.CON.ID>:DCS:<OCS.OSi.NAME>"
Based on the value of DBROOT
other default database addresses -of state, newdata(DCS) and status (DCS)- are
specifed.
Database address of
state -
