INTERFACES

This chapter gives an overview of all the interfaces of the Auxiliary Telescope Control System, external as well as internal interfaces. Only brief descriptions and general design considerations are presented. More details are available in the ATCS Online Documentation and in particular the UML model provides a lot of interface information. Package Design Description documents will contain also sections describing all interfaces between the package and other packages.

External interfaces

User

A 'direct' ATCS user is interacting via TCS GUI panels or start-up scripts. An 'indirect' ATCS user is one who is interacting with ATCS via some other package, e.g. VLTI Coordination Software. Such a user is not interacting directly with ATCS but via some external software, and is therefore seen by ATCS as `External application software' (see below).

External applications

External software interfaces to ATCS by use of the public interfaces provided by the tif package.

The ATCS public interface must be as much as possible identical to the Unit Telescopes TCS, to make transparent to VLTI Coordination Software the usage of Uts and ATs for interferometric combined operations.

The UT TCS interface is therefore taken now as a reference. See the ICD between ATCS and VLTI Supervisory Software [AD25] for details on the current Telescope Interfaces.

Graphical User Interface

This document presents the general concepts applied to ATCS GUI panels. Detailed presentations and descriptions of panels will be given in a ATCS Operator User Manual, to be developed during commissioning. All ATCS GUI panels are produced according to the Common Conventions for VLT UIF panels [AD08] and developed using the Java programming language or reusing already available user interfaces developed with the VLT Panel Editor.

Additionally, the following rules must be applied in order to allow re-use these panels for all instances of ATCS of the VLT observatory.

• Relative paths are always used when referencing database points.
• Node names, addresses and similar information are not fixed in panel definitions, but are parameters to the panels, given at runtime.

The GUI panels provided by the ATCS package can be divided in the following categories, according to functionality:

• Status panels: They are used to show the status of parts or all of the ATCS system. They are organized in a hierarchical way, with increasing level of detail, to allow for selection of a suitable level of details.
• Control panels: These are panels which the telescope operators can use to override/intervene the automatic control of ATCS. Like the status panels, they are organized hierarchically, but there are also `horizontally organized' panels, i.e. panels with combinations of functionality that reflects frequently used combinations of actions. Control panels also contain some necessary status information.
• Engineering panels: The engineering GUI provided by CCS and LCC will be used for engineering purposes. In addition to this, there will be panels that provide the software and hardware engineer with additional status information and control possibility, on a level which is not used for observational purposes. These panels can access `internals' of ATCS modules and subsystems.
• Error and alarm display: The general GUI facilities provided by the CCS Error and Alarm systems are used.
• Test panels: It is possible that panels will be produced for pure test purposes, that are not part of the Engineering panels, but are special to a given SW or HW unit. Such panels are normally not accessible at all, not even as Engineering panels, because they might be too dangerous to use. They can be accessed only after some (minor) re-configuration action.

Telescope Real-Time Display Utility

For ATCS operations and maintenance, the Telescope Real-Time Display is used for the following purposes:

• field acquisition in general (`looking at the field')
• selection of object or guide star
• manually selected centering of object or guide star
• measuring the relative position of a `pointing measure'

The Telescope Real-Time display is a specialized Real-Time Display able to send preset, offset and guide star acquisition commands to the ATCS based on selections from the attached camera or from any available catalogue.

The real-time display of FSS data will be performed using dedicated display widgets created from panel editor classes provided by the STRAP software. These widgets will be integrated in the FS GUI. This feature is decoupled from the Telescope RTD.

Archive

Each action performed is logged in FITS format using the DICB dictionaries[AD16].
Four categories of logs are produced:

• Action log: record of an action
• Status log: record of action completion, status information
• Unforeseen log: record any unexpected event
• Comment log: any information that may be relevant for a complete description of the system

Interfaces to subsystem hardware

Interfaces to subsystem hardware are described in detail in the ICD between the Electro-Mechanical Hardware and ATCS [AD20].

Internal interfaces

Internal package relations

Package-package interactions can be in the form of :

• Commands
  Every ATCS package is allowed to use any command defined in the CDT of any other ATCS package
• Direct database read
  Every ATCS package is allowed to read directly in the database branch of other ATCS package. This should be limited to the strictly necessary and should whenever possible use either application programming interfaces provided by the package owner of the data to warranty encapsulation or to use indirect addressing.
• Database event triggering and alarms
  Every ATCS package is allowed to attach events and alarms directly to database attributes in the database branch of other ATCS package. This should be limited to the strictly necessary and should whenever possible use either application programming interfaces provided by the package owner of the data to warranty encapsulation or to use indirect addressing.
• Application programming interfaces.
  Packages should provide application programming interfaces, in the form of class libraries, to be used by other classes to request services. In particular this should be done to get access to database attributes, in order to warranty information encapsulation.

Details about which mechanism is used where, can be found in the individual packages design descriptions.

Setup file handling

The Presetting module provides the setup file handling interface to `external' software. All other ATCS modules support an internal setup file handling:

• from the Presetting module they can receive complete setup files, where items that have changed since last time are marked. From the setup file received, the corresponding values are extracted and treated.
• All modules also support the 'check' option.
• With the exception of Presetting, no module supports the 'noMove' flag.