FUNCTIONAL SPECIFICATION

Introduction

The functional requirements of the Auxiliary Telescope Control Software are captured in form of Use Cases [RD04].

"A Use Case is a specific way of using the system by performing some part of the functionality. Each Use Case constitutes a complete course of events initiated by an actor, and it specifies the interaction that takes place between an actor and the system.... The collected use cases specify all the existing ways of using the system" [RD04].

Actors are the system itself and any other external entity (people or other systems), that interacts with the system to achieve a desired goal.

At the level of requirement specification, Use Cases see the system as a black box and no indication of the internal architecture is provided.

At analysis and design level, Collaboration Cases are used to "open" the black box and show the interactions between the components internal to the system. In this phase Use and Collaboration Cases are assigned to software packages and extended adding specific design level details. When Use Cases and Collaboration Cases are read from the Requirements point of view, the Design level details are filtered out and removed.

Use Cases can also be directly used to verify compliance of the development system to the requirements. The acceptance test of the system consists in verifying one by one all the use cases specified at requirements level and whenever possible an automatic regression test will be developed for each Use Case.

Use Cases are grouped according to their functionality.

Note: The actual text of the Use Cases IS NOT included in this chapter. To allow an easier navigation between the use cases and to make easier to keep them up to date and always available in the next project phases, Use Cases are written as hypertext html document and kept under configuration control. The complete text of the Use Cases as of the document release date is given in Appendix for reference and archiving purpose, but the reader should always refer to the online version.

AT Control Software

The ATCS shall provide all the functions to perform both low level control (implemented in one or more LCUs) of each of the subsystems listed in section Subsytem Software, and high level tasks, running on the WS platform and coordinating the subsystems operations. It shall also have an interface to the external systems. During the VLTI operation, the ISS shall command the ATCS.

In general, the ATCS includes six categories of software:

The ATCS design and development shall be based on the VLT UT TCS [AD17], according to General Requirements - Control Software.

Coordinating Software

The tasks of the Auxiliary Telescope Coordinating Software are:

The Coordinating Software consists of the following groups of:

 

Note: The VLTI Software Requirements Specification document [AD18] refers in section 3.2 also to Relocation Software, that is not any more controlled by software but by human operators, and to Combined Operations Software, that is not in the scope of the AT Control Software but is at a higher level, common to UT and AT telescopes.

Subsystem Software

The list of the subsystems that are controlled by the ATCS follows here below:

The Subsystem Software shall be developed according to the general guidelines given in [AD11].

Interfaces to external software

The Special Interface Software gathers the two libraries to access the Star Catalog System and the Astronomical Site Monitor (ASM). It does not require any specific development, because these libraries are included in the development of TCS package (ASM) and DFS package (Astronomical Catalog Library [AD15]). The ATCS shall simply use the functions provided by them.

Note: The VLTI Software Requirements Specification document [AD18] refers in section 3.2.3 also to the Building Management System, that is not actually used in the AT Control Software.

Command Interface Software

The ATCS shall provide to the outside world an interface, which includes all the possible commands supported by the ATCS and made publicly available. During normal operation this interface is actually only used by VLTICS-ISS, which will send global commands to the AT, without knowing the details of the internal control of each subsystem, and will receive a general feedback of the telescope status. Such an interface shall constitute the only gateway to the ATCS functions from external software and shall act basically as a command dispatcher towards the internal software modules (of VLTICS).

User Interface Software

The normal interaction with the user will be achieved within the framework of ISS/User Interface by means of graphical panels. However the ATCS shall have a built-in user interface dedicated to the software development and maintenance staff, used when testing the operations of the single telescope and its elements, independently from the whole interferometer.

Engineering and Maintenance

The Engineering and Maintenance software shall allow to access the complete functionality of all LCUs, all subsystems and all high level functions. This means, in particular, that all I/O signals are individually accessible, for reading or writing, and that all moveable and adjustable devices can be individually manipulated. Furthermore most of the LCUs have low level functions that are normally used programmatically by high level functions in a way invisible to an observing user. However these functions can be directly used for Engineering and Maintenance purposes. They shall be made available by means of tailored Engineering and Maintenance graphical panels.

ATCS States

At each instant in time the ATCS can assume one of a predefined set of states:

A separate sub-state is maintained for the tracking sub-system. Three main substates are identified:

State information about other components of the AT Control System is available. In particular, specific state information is maintained for the Chopping software.

Note: The VLTI Software Requirements Specification document [AD18] defined requirements for ATCS states in section 3.2 "ATCS States". This definition has proved not feasible during design and implementation of the UT Control Software and had to be modified.

In particular indication of tracking and auto guiding/field stabilization states had to be separated from the global system substate.

For example, the telescope can be TRACKING but at the same time STANDBY if a non-tracking subsystem (i.e. a subsystem not involved in tracking a target) is for any reason in STANDBY state. Even in this condition it can be possible to continue observation under degraded performances.