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:
- Coordinating Software
- Subsystem Software
- Special Interface Software
- Command Interface Software
- User Interface Software
- Engineering and Maintenance
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:
- to manage high level tasks of combined, coordinating nature,
which involve often simultaneous actions executed on several
subsystems
- to send the low level commands to the subsystems in the proper
sequence
The Coordinating Software consists of the following groups of:
- Mode Switching
The Mode Switching functions are used to command the AT Control
System as a whole and to provide information regarding its
global operational state.
- Presetting
The Presetting functions shall take care of requests to move the
telescope to a new target position.
- Pointing Modelling
The Pointing Modelling software creates and updates, automatically or
interactively, pointing models used to improve the telescope
pointing accuracy, by compensating geometrical misalignments and
structural flexures.
- Optical Adjustments
Comprises all activities related to adjustments of optical devices
(Mirrors, Wheels, Filters, ...)
- Tracking
The Tracking software shall implement the function that drives the telescope to follow the apparent motion of an astronomical object.
- Field Acquisition
The Field Acquisition functions provide a high level control of the Field Acquisition Sensor, which supplies an image of the stellar field from the Coudé Focus.
- Autoguiding
The Autoguiding software shall intervene to correct telescope position errors of low frequency
- Field Stabilization
The purpose of the Field Stabilization is to make position corrections faster than those achievable by Autoguiding. Modifying the tip/tilt angle of M6 performs such corrections.
- Chopping
Describes the functions needed for tip-tilt of the M6 to achieve
chopping.
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.
The list of the subsystems that are controlled by the
ATCS follows here below:
- Altitude drive
Position control of the telescope altitude axis, including
motor, amplifier, tachometer, encoder, brakes and limit
switches.
- Azimuth drive
Position control of the telescope azimuth axis, including motor,
amplifier, tachometer, encoder, brakes and limit switches.
- M2
Control of the focusing, centering and tilt mechanism,
switching of the pupil beacon light source.
- M6 (to be replaced by Deformable Mirror)
Control of the High Frequency M6 tilt motions, required for
field stabilization and chopping. For Adaptive Optics, the M6
will be replaced by a deformable mirror controlled by
appropriate electronics.
- M10 (to be replaced by Dual Feed Mirror)
Control of the Dual Feed mirrors (when implemented) for
output pupil position adjustment as well as reference object
selection and tracking. Control of the two low frequency M10
tilt motions, required for output pupil position
adjustment.
- Coudé Beam Switching Device
Control of the selection of the different elements that can
be inserted in the beam before the Coudé sensor. It
consists of 5 elements, namely a Mirror reflecting the beam to
FAS only, a Beam Splitter sending the beam to both FAS and FSS,
a Free Hole to FSS only, the FSS pupil viwer and a Light Stop
that prevents the beam to reach neither FAS nor FSS.
- Nasmyth wheel
Control of the position of the wheel, including motor,
tachometer, encoder and limit switches. Switching on/off the
image beacon light source. This 4-element device consists of
Flat Retro-Reflecting mirror, a Free Hole and 2 positions for
dedicated Alignment Tools (light beacons).
- Field Acquisition Sensor (FAS)
Control of the Field Acquisition Sensor components (CCD
head, pre-amplifier, temperature sensor, liquid cooling) The
Field Acquisition Sensor is used also as the detector for Auto
Guiding.
- Field Stabilization Sensor (FSS)
Control of the Field Stabilization Sensor components (detector,
real time electronics, communication link to M6).
- FSS Filter Wheel
Control of the position of the filter wheel that allows the
insertions of 6 neutral density filters before the FSS.
- FSS Translation Stage
Control of the XY translation stage used as support for the
FSS, including motor, tachometer, encoder and reference
switches.
- Air Conditioning
- Thermal Control inside the telescope dome
- Telescope Temperature Sensors
Monitor and record the values provided by the temperature
sensors installed on the telescope structure.
- Relay Optics Structure (ROS) Shutter
Open/Close control.
- Enclosure
- Anemometer
Monitor the wind speed measured by the anemometer placed
at the AT enclosure.
- Open/close control,
- Emergency and redundant closing
- Transporter
Monitor the status of the transporter and in particular of the
anchoring system.
- Service modules
Monitor the status of:
- Auxiliary power
- Hydraulic and pneumatic systems incl. On/Off control
- Liquid Cooling Module incl. Flow meter monitoring
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:
- OFF
The system is not operational. The control system is entirely or
partly switched off, or the control software is not loaded or not
initialized, or the control hardware is not configured, or some
controlled devices are in unknown state. To go to the STAND-BY
state, a cold-start procedure is required (power-on, loading,
initialization).
- STAND-BY
The system is not operating, but nevertheless the control software is
loaded, initialized and running. All equipment are switched off,
except those functional units which are required for thermal
stability. Required mechanical safety systems are activated to
prevent any degradation. This state is used when the AT is not
performing an observation, a relocation, or a maintenance
procedure, and provides a safe configuration against environmental
aggression. This is the typical state during day-time.
- ONLINE
The system is completely ready and available for the observation run
or already observing. Two main substates are identified:
- Idle
The system is ready to operate or is operating and is
waiting for a command.
- Presetting
The telescope is performing a "Preset Sequence" moving to
point a selected object in the sky or to a selected
absolute position. Part of the "Preset Sequence" is the
setup of all the sub-systems selected for observation in
the given setup.
A separate sub-state is maintained for the tracking
sub-system. Three main substates are identified:
- Idle
The system is ready to operate and is waiting for a command.
- Presetting
The telescope is moving to point a selected object in the sky
or to a selected absolute position, or the telescope position
is being corrected by a user offset command.
- Tracking
The telescope is following the apparent motion of the pointed
object in the sky. A further level of specification, kept in a
separate sub-state, identifies the type of tracking based on
the guiding mode:
- none (blind tracking) The telescope is
continuously pointing the object under observation using
its theoretical trajectory, taking into account the
sidereal motion, the complete standard coordinate
conversion, atmospheric refraction as well as
telescope-dependent errors included in the pointing
model. It involves the motion of the telescope's axes
only.
- autoguiding It is similar to blind tracking,
except that a low frequency error signal is provided by
the Field Acquisition Sensor from the measurement of the
actual object image. The error signal is used to correct
the position of the telescope's axes.
- field stabilization It is similar to autoguiding,
but in this case a high frequency error signal is
provided by the Field Stabilization Sensor from the
actual star position, to correct atmospheric turbulence
effects and remaining telescope tracking errors. The
error signal drives the tip/tilt control of the fast
steering mirror M6 for compensation. The telescope's
axes follow a control law that performs the offload the
M6 tip/tilt position.
- RELOCATION
The system is performing all the necessary steps to move the AT from
one observing station to another. An operator performs the
relocation under "manual" control using control panels. The AT
Control Software plays no role in this operation, if not
monitoring passively the status of sub-systems. For example an
accelerometer could be added to monitor the acceleration of the
transporter during relocation.
- MAINTENANCE
The system is under maintenance procedures, such as tuning,
calibration and performance monitoring.
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.