General Requirements

The AT Control System shall obey to the standards described in [AD04], � 7. This section will point out the main software requirements.

Control Software

The design and development of the software will be on a large extent based on the UT Telescope Control Software that has been designed for reuse on other ESO Telescopes.

The ATCS will be constituted by a set of running programs (processes), distributed on LCUs and WSs. They will cooperate exchanging messages and sharing a common on-line database. The control software of a subsystem (as defined in the Glossary) shall run entirely at LCU level, while software of coordinating nature should be mostly implemented at WS level. The software shall be built in functional layers; each of them will provide all the required services to the next upper layer and will hide the details of the lower layers.

As general constraints, the following issues shall be considered:

ATCS is formally part of the VLTICS but can work also standalone, like TCS does for the UTs, to work independently of the VLTICS. The systems of VLTICS are independent but coordinated by ISS. The individual systems are not accessible from outside, but only through ISS.

VLT UT Telescope Control Software (analysis, design and actual software modules) shall be used whenever possible. This means that a new design of a new implementation will be used only if and where the UT Telescope Control Software does not provide already the required functionality. Also in this case, the software modules of UT Telescope Control Software will be used as a baseline and new specific modules for the ATs will be created to augment or override the basic functionality. It could be necessary to generalize software modules of the UT Telescope Control Software to allow reuse for the Auxiliary Telescope. In this case formal change requests will be submitted to allow the generalization. Finally the functions that do not exist in the UT Telescope Control Software shall be developed as new software modules.

VLT common software (CCS [AD05] / LCC [AD06]) shall be used whenever applicable and for all the basic services.

other existing VLT software packages and/or modules shall be examined to assess any possible reusability or adaptability

commercial packages and standards shall be used whenever VLT common software and standards do not provide the required services.

interfaces to external software shall be provided

Table 3 shows the commercial and the ESO internal software, on top of which the ATCS shall be developed. At the WS level there also are two more layers above CCS: Extended CCS [AD07] (ECCS), the object oriented interface to CCS, and CCS Event Handling [AD09] (EVH), a software toolkit easing the implementation of event driven applications, which shall constitute the standard for high level coordinating software modules.

	LCU	WS
Operating System	VxWorks	UNIX
VLT Common software	LCC	CCD, ECCS, EVH
UT Telescope Control Software	LCU Control SW	WS Coordination SW

Table 3. Software platform for the ATCS.

VLT Software - Guidelines for the Development of VLT Application Software [AD11] gives a set of clear and important guidelines for the development of application software, both on WS than on LCU, explaining in particular how to use CCS.

The standard programming language will be ANSI-C and C++. Coding recommendations concerning program structure and style are given in VLT Software - Programming Standards [AD02].

The graphical user interface will rely on the ESO Graphical UIF Common Conventions [AD08].

Subsystem Functions

There are several functions that are in principle the same in every subsystem. This applies to reading and displaying I/O signals, reading/writing local variables, logging and raising alarms and many others. These common functions are described in [AD06], and they all apply to every subsystem unless explicitly excluded.

The final subsystem sets of functions will partly depend on actual hardware design solutions. General principles to follow when defining functions are:

all relevant signals (voltage levels, currents, switch positions,...) shall be available to the higher level software and easy to access through the user interface
all moving or adjustable devices should be available for individual, independent movement (adjustment) for test and maintenance purposes
for every command at least one reply shall be returned, when the requested action has been completed

A comprehensive list of requirements and guidelines is given in [AD11].

Subsystem States

Each subsystem shall have a set of predefined possible states. The same state definition already established within the LCC (see [AD06] and [AD11] for more details) shall be used, that is (sorted by increasing operational level):

OFF
The subsystem is not operational, that is switched off, or hardware not available, or control software not loaded.

LOADED
The necessary control software is loaded, but some software and/or hardware is in an undetermined status (not initialized). This is the state where normally no activity can take place, except starting the system (making a transition to a higher state).

STAND-BY
Everything needed to use the subsystem for normal operation is in a known and defined status. This is the state normally used during day-time.

ON-LINE
Everything needed to use the subsystem for regular operation (normally for observation) is ready to be used (switched on, initialized, checked). This is the state used for normal night-time operations.

System Performance

The ATCS shall be able to handle at the same time an observation run and those functions of the Maintenance Mode that do not interfere with the current observation run.

A monitoring mode (that is no permission to send commands, but only to get readouts of the AT status) shall be foreseen and implemented in a way that shall not influence at all the system performance. No remote access possibility for the control of the interferometric observation is foreseen, because of the highly experimental environment.

The response times shall be those mentioned in [AD04], � 2.2.3.