DATA DESCRIPTION

Database design.

The LCU databases for ATCS subsystems, as well as the global ATCS database, shall be designed according to the principles defined in the Guidelines for the development of VLT Application Software [AD11].

Each ATCS package will make a design of the corresponding LCU database branch. Though the various packages are in principle independent of each other, an effort shall be made to coordinate the design as far as possible.

There will be one ATCS database environment on the AT Control Workstation.

The database is designed according to Object Oriented principles. In particular every class is fully responsible for its own data and it encapsulate data access as much as possible. The system has a hierarchical structure: the system is on top, divided in packages. Each package is constituted by objects running in different processes and so on. This hierarchy is mapped in the structure of the database and every software component is responsible for the corresponding database branch.

As shown in the following database architecture diagram:

• The AT control Software WS database expands under the TCS root point.
• Every WS package provides a sub-branch of the TCS point in the WS database.
• The Telescope Interface package provides the only public database branch, i.e. the only branch that can be accessed in read mode and using the provided access libraries, by external applications.
• Every package (except for the Mode Switching) is a subclass of the Standard Package and it must then provide the corresponding standard database attributes.
• Every LCU package provides a database branch in the LCU database.
A database architecture diagram is provided as UML diagram with every package

Database use.

ATCS applications rely heavily on the database, not only for storage of data, but for implementations using features related to the database, like event notification, alarming, User Interface etc. For this to be useful, the database has to be used wherever possible for storage of quasi-static data as well as dynamic, temporary data.

As a general design concept, all data related to TCS subsystems or modules are defined in the database. This is the case for configuration parameters, reference values, actual values, status information etc., and also for intermediate results and values. Of course, application objects, programs and functions have their own private data, kept internally, but anything which is shared, or could be shared, between software units should be in the database, and not in any other kind of shared data structure. This rule applies to LCU and to WS software. Any exception must be discussed and accepted individually.

The following database access rules apply:

• Every ATCS object is fully responsible for the data in its own database branch. No other ATCS object is allowed to modify data in the branch of another object. In this context, an object is any instance of an ATCS class, at any logical level: from package to actual code level class. This applies in particular to packages, that are logically represented by a conceptual high level class providing the whole functionality foreseen for the package itself.
• ATCS objects are allowed to read data on the branches of any other object deployed on the same Workstation or LCU, but in order to make the system resilient to changes it must:
• use access functions provided by the class that owns the required database attribute, or
• use indirect addressing, i.e. putting the path of the database area to be read in a database attribute of its own branch, to allow easy reconfiguration without recompiling the SW in case of changes.
• Non-ATCS applications are allowed to access only the public database provided by the Telescope Interface package.
• ATCS Graphical User Interfaces are allowed to access any database attribute on the ATCS Control Workstation
• ATCS Engineering User Interfaces are also allowed to access LCU database attributes

WS-LCU databases.

The subsystem packages mirror on the ATCS WS database all the attributes that can be of interest for coordination packages running on the workstation or for user interface panels, i.e. for each LCU database there is a partial copy on the ATCS WS. The CCS Scan system is used to copy data from LCUs to the WS database. Data are not copied the other way, from the WS database to an LCU database, by use of database facilities. When the LCU database needs to be updated, this is done by an explicit, special command, to an LCU function that updates the local database.