Reliability and Availability
The VLTI is a highly experimental environment. The first phase of its operation foresees considerable time reserved for system optimization and upgrade. However, the ATCS shall have a high reliability level, that can guarantee since the beginning the basic control on all the functionality of the system in order to run interferometric observations and concentrate the software upgrade effort on the above-mentioned optimization at VLTI system level. The basic requirement for the AT is to have a reliability level comparable to that of the UT. One should aim at characterizing more precisely the maximum fault rates and system down time during the ATS commissioning period at Paranal.
The ATCS software is designed such, that the number of components that cause a complete loss of operation when they fail, is minimized. Logging, error and alarm reporting are factors of major importance for recovery from error conditions and are therefore carefully considered and implemented.
Due to the large number of controlled components, the ATCS will have an efficient procedure to recover in a reasonable time from a troublesome condition and/or to reboot the whole system and put it in a "ready to use" state. There will also be the possibility to save on request or automatically (for instance, when a general system failure occurs) the most important parameters representing the AT status into a database. The reloading procedure should cause the system to perform all the necessary actions to bring the whole system back in one of the stored configurations (the last one by default).
Maintainability
The concept for maintainability is based on the following points:
- Modular structure to be flexible enough to accommodate new functions. The praxis of assigning a small and precise task to each entity of the package (an entity can be, for instance, a process, an object, a data structure or a function) and then aggregating them into more complex ones, smooths the impact of the upgrading procedure. The skeleton of each package shall comprise all the "hooks" (represented in the code by empty entities) for any planned function or interface, even though the actual implementation is foreseen to come later.
|
|
The interfaces between packages are reduced to messages and database areas and are clearly defined, so that changes can be restricted to the affected packages only, without side-effects to all other packages (see next section). |
![[Design Description Entry]](../../Images/arrow.gif){kind=icon}
|
|
All configuration parameters are stored in the WS on-line database. |
- The ATCS SW will be used by higher level software and the ATCS database definition is very likely to change several times (adding new features almost always requires to add new attributes in the database).
|
|
The Telescope Interface package provides therefore routines to allow transparent access to information contained in the ATCS database. |
- An installation procedure will be made available to allow installation of new releases on already working systems, taking automatically into account possible changes in the database structure (e.g. attributes added).
|
|
The Build package provides this facility |
- The maintenance engineer is supported by the ATCS online documentation, that will be kept up to date during the whole development process and that will provide at the all the necessary architectural, design and implementation information needed for maintenance purposes.
- The software design takes into account as a factor of quality the possibility to fix bugs and correct misbehaviors in a short time using simple procedures. There shall be a facility in the system to label a software module as "not operational" in order to ignore it and restrict as much as possible the influence of the correction procedure on the rest of the control software, when the ATs are operating. This means that the ATCS shall still run, providing to the user all the other functions not depending on the faulty module.
|
|
The Mode Switching package provides this facility |
- Keeping memory in a database of the logs (or a selection of them) produced automatically by the system, helps in figuring out the actions that provoked the failure under investigation.
|
|
This is a basic service provided by CCS. |
Adaptability and Enhancement Potential
The ATCS shall be designed in such a way that it will allow easy integration of the control software with the other VLTI components, which might be not foreseen for the first phase of the implementation. Furthermore it shall not be dependent on the actual number of identical elements to be controlled, but it shall be designed to support since the beginning the maximum planned quantity.
|
|
The design concept for adaptability and extensibility is based on the following points:
|
Modularity
Many software processes will cooperate to control and monitor the Auxiliary Telescopes.
- A hierarchical structure of the software packages together with a careful design of the functionality of each package will help in easing the integration of new functionality and in figuring out failures.
- The packages shall be independent as much as possible from each other in the execution of their tasks.
- Any necessary interface shall be kept as small as possible in the sense of the data to be exchanged. Each package shall appear to the outside world as the set of public commands that it will accept and the set of database attributes related to itself.
- The modularity of the whole system is improved by the mechanism of a "unique access point" to the functions of a set of cooperating modules. This means that sending commands from outside directly to a specific package shall be evoided.
|
|
This concepts is implemented by the Telescope Interface package and external applications are not aware of the internal structure of the ATCS. |
Security and safety
No special security requirements are applicable to the ATCS in addition to those stated for the whole VLT software, like the protection against possible conflicts in controlling the same element by two users (obtained by means of the ACC) and against external intrusions through the network.
The software constitutes the first filter to prevent from the misusage of the system. It shall provide safety mechanisms that shall operate in advance with respect to any hardware interlock. The command parameters shall be checked against their range limits. Every motion of components shall be supported by a software alarm, which will also take the proper corrective action before reaching hazardous situation. Similar solutions shall be implemented for any other physical parameter (like current, voltage, time, force), which can jeopardize devices or people if not kept in its proper working range.
Critical and immediate actions to react to an emergency situation shall be initiated at the hardware level. The software shall be informed by an alarm signal and shall save a comprehensive set of status data to support later analysis. Then the software shall command the whole controlled system to go into the STAND-BY state. A possibility to run automatically a predefined sequence of procedures, customized for a general emergency situation, to configure quickly the system in a safe and controlled state, shall be also considered at the level of the user workstation.
Training
TBD.
Documentation
The most up to date documentation for the ATCS project is available in hypertext format and can be accessed through any World Wide Web browser. The hypertext documentation is kept under configuration control in the VLT module named atcsdoc.
This hypertext documentation is evolving throughout the various project phases (Requirements, Design, Implementation, Testing, etc.), so that it contains at any time all documentation for the project, kept up to date and with no redundancy.
The document is expanded by the artifacts that are produced according to the Unified Software Development Process [RD06] and the Unfied Modeling Language (UML) [RD04]
A tool that supports UML, namely Rational Rose, is used to document formally the process.
Printable documents are released for review and archiving purposes at specified project milestones. They are composed extracting all information from the hypertext documentation. Whenever possible, they are just build linking hypertext sections to make easy and automatic the release of updated versions.
Last modified: Mon Aug 16 14:20:11 METDST 1999