This section defines the global architecture of the ATCS system. The architecture is derived from, and is mapping, the functionality described in the Requirements Specification [AD05 ]. The split up in packages and package names assignment are also given. A description of each package is given in the Packages chapter.
The interrelation between the ATCS system and externals is shown in the top-level context diagram in [Figure 3] in the Overall Description and General Requirements chapter.
The ATCS is split into sub-divisions called packages that are designed, developed and tested independently. They are then integrated and the whole system is tested as a single entity. Packages can be in principle recursively containing other packages.
Every package has a name that identifies it uniquely. At implementation level, packages are mapped into VLT software modules, that correspond to components in the UML terminology, kept under configuration control in the VLT software archive and with a standardized structure.
In most cases, one package corresponds to a single module, with the same name. Some complex packages will be split in more modules; in this case the package name is used as a prefix for all the related modules.
There are four categories of packages within the scope of the ATCS system:
These categories are described in the following subsections.
Figure 1 below in this chapter is the class diagram showing all packages with their relations.
Figure 1. Class Diagram for Packages of ATCS software.
The term Subsystem is frequently used in VLT documentation to refer to a more or less well-defined electro-mechanical unit of the total telescope. Subsystems are typically controlled from one LCU, while one LCU can control one or more subsystems. Complex subsystems can include more than one LCU, but they are anyway largely independent of each other from a software point of view. Subsystem software is fully responsible for the control of the subsystem and implements all the interfaces that are necessary to interact with the electro-mechanical units that are part of the subsystem itself.
These packages are identified by the stereotype <<SubSystem>>.
Every subsystem software package provides:
The table below lists the subsystems within the scope of ATCS. More details on the deployment of each subsystem on the LCUs and on the harware configuration of the LCUs themselves can be found in the Hardware environment section.
| Subsystem | Package name | Component name | LCU |
|---|---|---|---|
| Tracking axis | Tracking Axis, Probe | axis, ataltaz, probe, atp, atalt | alt, az, sensor |
| Translation Stage | tsd | atxyt | sensor |
| Field Acquisition System | fas | ccd | sensor |
| Field Stabilization System | fss, ndf, afd | atfss, atndf, strap | sensor |
| M2 | m2 | atm2 | alt |
| M6 | m6 | atm6 | sensor |
| M10 | m10 | atm10 | az |
| Nasmyth Focus Device | nfd | atnfd | alt |
| Coudé Focus Device | cfd | atcfd | az |
| Air Conditioning System | acs | atacs | aux |
| Relay Optics Shutter | ros | atros | aux |
| Transporter | trl | attrl | aux |
| Enclosure | ecs | atecs | aux |
| Services | srv | atsrv, ataltsrv | aux, alt |
| Future Subsystems | Package name | Component name | LCU |
|---|---|---|---|
| M6 Deformable Mirror | m6dm | atm6dm | sensor |
| M10 Dual Feed | m10df | atm10df | az |
| Transversal Atmospheric Dispersion Compensator | tadc | attadc | az |
The `Coordination software' is hierarchically above the subsystem software. It performs actions of a combined, coordinating nature, and it often uses one or more subsystems to execute its actions.
These packages are identified by the stereotype <<Coordination>>.
Most of the coordinating software runs at Workstation level, but there are also parts that run on LCUs, in particular,
The coordination packages make use of other `fellow' packages and of subsystems to do their job.
All inter-process communication, and all communication to LCUs, makes use of the CCS message system. Each package has a command interface, which is the one is normally used for all inter-package communication, and which is also normally used by TCS user interface panels. There are exceptions to this principle in a few cases, for performance reasons, e.g.:
The table below lists the coordination packages within the scope of ATCS.
| Table 2. ATCS coordination packages. | Package name | Component name |
|---|---|---|
| Mode switching | msw | atmsw, atosf |
| Presetting | prs | atprs |
| Pointing modelling | pom | pom |
| Tracking | trk | trk, acm, trkws |
| Optical Adjustments | opt | atosf |
| Chopping | chp | chopws |
| Autoguiding | ag | ag, agws, atagws |
| Field stabilisation | fs | atfs, fsws, atagws |
| Enclosure Control System | ecs | atecsws |
| Active optics | act | atact |
| TCS monitoring | tcsmon | atcsmon |
| Thermal | thermal | thermal |
| Table 2b. Future Coordination packages | Package name |
|---|---|
| Adaptive Optics | ao |
The normal interaction with the user will be achieved within the framework of ISS/User Interface by means of graphical panels. However the ATCS will have a built-in user interface dedicated to software development and maintenance staff, used when testing the operation of a single telescope and its elements, independently from the whole interferometer.
These packages are identified by the stereotype <<Interface>>.
The interface to ATCS can be divided into two types:
The Programmatic Interface, also called just Telescope Interface, is the one used by any other software interacting with the ATCS.
As shown in figure 1 in this chapter, all communication to the ATCS is directed to a single interface process running on the AT Control Workstation. The command interface provided by this process and based on the CCS message system is the only way from external software to control via software the Auxiliary Telescopes. The package provides also a library of functions and a standard database branch that can be used by external applications to query the status of the ATCS.
Commands directed to the Telescope Interface are routed transparently to the appropriate ATCS coordination packages.
The graphical user interface for the ATCS consists of all operator and engineering panels used to control the telescope. Logically all GUI development is independent and separated from the development of the telescope control functionality. No GUI will contain control logic and all inter-process communication between panels and control processes is based on the standard command and database interfaces. The only differences with respect to external applications is that ATCS GUIs are allowed to directly send commands and access the database of all control packages, without asking the services of the Telescope Interface Package and without being limited to the ATCS public interfaces. This allows to develop the GUIs completely independent from the control software and makes easy to redesign and replace them without side effects on the control software.
The operator panels are not strictly part of the ATCS development process, since they are typically developed at Paranal by the team responsible for final integration and commissioning in collaboration with the telescope operators. Some basic panels are anyway provided to allow first operation of the system and will be typically based on the GUIs of the VLT Unit Telescopes.
Engineering panels are typically developed contextually with the corresponding packages to allow modular testing and integration. In this case they will be then physically distributed inside the VLT software modules of that packages.
All ATCS interface software runs at workstation level.
The table below lists the interface packages within the scope of ATCS.
| Table 3. ATCS Interface Packages | Package name |
|---|---|
| Telescope Interface | tif |
| Telescope Graphical User Interfaces | gui |
Packages that cannot be well classified in any of the three previous categories are just simply defined as support packages and are not identified by any specific stereotype.
The table below lists the support packages within the scope of ATCS. It includes general system configuration packages as well as basic packages that implement standard design patterns and functionality defined at higher VLT level, like for example the behavior of standard commands, protocols for error handling and so on.
The classes defined in these packages are used as base classes in the inheritance hierarchy for the classes defined in the other packages presented in this document.
| Table 4. ATCS Support Packages | Package name |
|---|---|
| VLT Software Package | vltsw |
| Standard Package | std |
| Build Package | build |
The following deployment diagram shows the hardware configuration for the Auxiliary Telescopes and the deployment of the packages on the CPUs that are part of the system.
Figure 2. Deployment diagram
The bulk of ATCS software runs on a ATCS workstation, the coordinating workstation, of which there is one per telescope and that is physically located in the VLTI Control Room. This workstation will hold the ATCS on-line database.
The ATCS user interface panels will run, during normal operation, on the VLTI Supervisor Workstation, or anyway on a remote workstation in the VLTI control building.
All subsystem software and the LCU components of the coordination packages runs on one of the 4 LCUs. More details on the exact hardware configuration for the LCUs are in the ATS Hardware Design Description [AD23 ] and in the ICD between the ATCS and electro-mechanical hardware [AD20 ].
For test and maintenance purpose, the LCU boards shall easily be accessed and especially the activation of the Reset buttons shall be granted. A dedicated PCB connected on the Digital I/O board may be designed to force the HW reset of the LCU whenever the associated digital I/O signal has not been accessed for 15s (this trigger is to be coupled to the SW watchdog of the LCU).
The different LANs to which the ATCS workstation(s) and LCUs are connected are described in the ATS Hardware Design Description [AD23 ] and in the ICD between the ATCS and electro-mechanical hardware [AD20 ].
The LAN layout will be finalized at a later stage at VLTI level.
The current LAN implementation reflects the VCM layout. A detailed study of the foreseen traffic will lead to decide of the final layout. It shall aim to avoid any LAN reconfiguration on relocation. Therefore a possible solution might consists in having all AT equipment on one subnet only.
One of the goal of the prototype will be to evaluate the bandwith requirements per ATS where Control and Guide LAN are merged into one LAN only. The 4 LCUs will be connected to an Ethernet Hub, which in turn will be connected to the ATM Switch. The Workstation will as well be connected on the ATM Switch, since it is located in the Computer Room of the VLTI building.
For tests, commissioning and maintenance activities, a switching box shall be placed in an easily accessible place in the Signal Cabinet on the Transporter that shall contain:
This can be used during testing and maintenance to connect a PC or a Linux portable.
Moreover, the network plug of the nearest station can be used to connect a PC or a workstation for longer periods.
During commissioning, the AT shall be placed in the maintenance station. A container might be located on the roof of the VLTI control room that offers good visibility inside the dome, necessary in the preliminary phases.
The Workstation software environment consists of:
The LCU software environment consists of: