5 STANDARD DATABASE STRUCTURE

The standard structure of the IWS on-line database common to all instruments is graphically described below. This should be considered the minimum structure, and each instrument may add its own particular branches.

Appl_data

|

|--TCS (or VLTI for Interferometry instruments)

|

+--UVES (Instrument Id)

|

|--DCS (see details in [23] [24] [25])

| |

| |--ccdsci1

| |--..

| +--ccdtec

|

|--ICS (see details in [21])

| |

| |--DEVICES

| | |--filt

| | | |--MOTOR

| | |--..

| | +--lamp

| |--ASSEMBLIES

| |--PROCESSES

| | |--WS

| | |--LCU1

| | |--...

| | +--LCU3

| |--HISTORIAN

| +--PLOT

|

|--OS (see details in [26])

|

+--newData (see 5.1)

5.1 DATABASE POINTS

The interface between OS Archiver and the VLT on-line archive system is described in detailed in [4] and is based on the newData OLDB point shown above. Every instrument must include such a point in its IWS OLDB and the OS Archive must write into it when new data become available. Such a point must be derived from the dbl class¹ inscNEWDATAINFO.class. Example:

// Branch Configuration File for (part of) OS

.....

// Point to signal existence/readiness of new detector data.

//

// Here we consider the general case of 1 or more detectors using the

// same point to signal the readiness of new data (which for

// simultaneous read-outs will result in a multiplicity of events

// equal to the amount of detectors).

// In case external clients need to be informed about the availability

// of new data of only a particular detector of a multiple-detector

// instrument, this scheme can easily be adapted (using different

// pointnames).

POINT inscNEW_DATA_INFO newData

BEGIN

ALIAS newData

END

....

For the purposes of OS being notified by DCS that the exposure has finished, or that any other event related to an exposure happened, class inscEXPOSURE is defined for the DCS database. The coding of the possible values of the exposure status is described in the file inscEXPOSURE.class. From this base class any specific DCS has to derive a more specific subclass. Example:

#include "inscEXPOSURE.class"

CLASS inscEXPOSURE EXPOSURE

BEGIN

// Add additional attributes here

END

Finally, the class inscEXP_LIFE_CYCLE is used by OS to reflect the different steps in an exposure's lifecycle; contrary to the expStatus attribute described in inscEXPOSURE, these stages are reflected here in separate attributes, so that one can be very selective when attaching processes to an event.

For an instrument which may have several exposures active simultaneously, there may be the need for one instances of these DB classes per active exposure.

The classes described above are part of the insc module distributed with the VLT Common Software release, and are installed under $VLTROOT/dbl during the installation procedure. The parts of the point configuration files for OS and DCS which are described here are also part of the insc module, and end up after installation under $VLTROOT/templates.

In order to determine the global instrument state, OS needs to know the state of all sub-systems it controls. Every sub-system (DCS, ICS, TCS) must therefore provide a database attribute of type INT32 containing the coded value of its state.

¹

For more info about this syntax, see the On-line Database Loader User Manual [11]. The classes and branch configuration files described in this section are distributed together with the periodic VLT Common Software Releases, as part of the insc module.

Quadralay Corporation http://www.webworks.com Voice: (512) 719-3399 Fax: (512) 719-3606 sales@webworks.com