The VLT control software development and installation
G. Raffi
European Southern Observatory (ESO),
Karl-Schwarzschild-Str. 2
D-85748 Garching, Germany
E-mail: graffi@eso.org
Abstract
The Very Large Telescope (VLT) control software
installation is on-going at the new Paranal Observatory of
ESO in Chile. The whole process of commissioning willtake up to year 2000, when all the four VLT 8 metertelescopes will be completed.
The VLT control software approach has been to use at
the basis standard commercial and public domain products(Rtap by HP, Tcl/Tk). A very comprehensive software
layer, called VLT common software was added on top,
before any specific control software was written. This has
been an in house development, provided by a team ofabout 20 people.
The VLT control software amounts now to about one
million lines of code. The common part (VLT commonsoftware) is distributed in 2 releases per year toContractors and Consortia of Institutes associated to theVLT project and they are requested to use it in their VLTdevelopments. The advantage of this approach is clear interms of uniformity and maintainability of software. Thishas raised though a number of needs, like backwards
compatibility and automatic regression testing (test scripts
amount to almost another million lines).
A novel approach of the VLT software in general, is that
the VLT control software is well integrated into an end-toend Data Flow concept. The whole is enabling automatic
execution of observations from proposal preparation toarchiving and is suitable for service observing.
A relevant feature of the VLT software at this stage isthat it has been validated (at about 90%) by re-engineering
the New Technology Telescope (NTT) at the La SillaObservatory in Chile. This was done by an independent
ESO team and the NTT is now back in service operation,
providing at any new release plenty of useful feedback.
This gives us the confidence that, above the obvious
differences of hardware between telescopes, the VLTsoftware will work properly also at the VLT.
1 Introduction
The VLT project consists of four telescopes each with a
primary mirror of 8.2 m diameter, capable of working inparallel, equivalent to a single telescope of 16 m diameter.
It is under installation at ESO's new observatory site atParanal, a 2600 m high mountain top in the Chilean
Atacama desert. At the moment of writing, while the four
domes have already been erected, also the activity ofcommissioning the control software has started.
First light on the first unit telescope is scheduled for mid
1998, but the entire commissioning period for the fourtelescopes and the auxiliary telescopes will extend up toyear 2000. At that moment the VLT will be the largest
optical telescope in the world. The VLT will also work ininterferometric mode, in combination with three movable
1.8 m telescopes. The instrumentation programs, involving
control software based on the same components andstandards, will be developed in parallel and will obviously
continue to require dedicated efforts for a much longertime.
The size of the VLT control software, including
telescope control software, is so far about 1 million lines ofcode (including comments, double so much if test scripts
are added) and might become about 1.5 million lines when
the full instrumentation complement is ready.
2The VLT control system

The VLT control system is based on a distributed layout(about 50 workstations and 160 VME basedmicroprocessors) with computers interconnected byvarious LANs intermixing Ethernet and ATM technologies(Fig.1).
With such a complex layout we found it fundamental not
only to try out interface cards and routers in a stand-alonemode, but to build a mock-up where software can beinstalled and tested in simulation. It is a VLT control
system without the hardware interfaces to the telescope
and we call it VLT control model. It allows to test software
integration and performances in advance. We give quite
some importance to this, having seen that most of theproblems with our previous releases were software
configuration and interface issues, much before any
hardware was concerned. We do this also in an effort to cut
down installation times to hours rather than weeks.
3The VLT common software

The main initial idea of the VLT was to have a welldefined and comprehensive common layer of software forthe whole observatory, main telescopes, interferometry andinstruments. This we implemented and call VLT commonsoftware.
It makes all the VLT control software behave the sameand gives to it a coherent design structure. It allows also to
the different user interfaces to have similar look and feel,as they are all based on a common tool, called Panel editor.
The VLT common software consists of a layer ofsoftware over the Unix operating system, in the case ofworkstations and on top of the VxWorks operating system,
for the Local Control Unit (LCU) microprocessors. It
provides mainly common services, like an architectureindependent message system, a real-time database for all
telescope and instrument parameters, error and logging
systems and a large number of utilities and tools. The innermechanisms of the common software on the workstationside are provided by a commercial software product from
Hewlett-Packard, called RTAP. A more extensive
description of the VLT common software was given at theICALEPCS ‘95 [Ref.1]. The smooth introduction into theproject of an Object oriented design and implementation
after its start-up phase was also presented at that
conference [Ref.2].
The original idea of a thin layer of software common to
all Observatory application software, has evolved in thecourse of time. It moved forward to include more and morehigh level applications, like the entire CCD control
software used both for scientific and technical CCDs (e.g.
guide cameras) and other general purpose software used byinstrumentation (e.g. Real-Time Display software andINS common software).(Fig.2).

The VLT common software is portable on two platforms
and all software has been tested both on SUN and HP Unix(Posix) workstations, while the microprocessors based on
VxWorks do now support also PowerPCs.
4

Software development approach

An important choice in our design was to base it asmuch as possible on existing standards and products(public domain like Tcl/Tk or commercial like HP Rtap).
We found it is important to resist as much as possible to theidea of re-inventing something better and slightly different,to spare expensive developments with a limited life-time.
The VLT common software is distributed in 2 releases
per year to Contractors
andConsortiaofInstitutesassociated to the VLT project and they arerequested to use it in their VLT developments. The
advantage of this approach is clear in terms of uniformity
and maintainability of software. Bi-annual releases

implement in a natural way an incremental development
approach. This allows to concentrate on the main featuresand leave the rest for a future release. It allows also to havefrequent deadlines, on which one has to be strict, but they
provide developers with a good feeling and feedback about
the development process.
The languages used are C (lower layers) and C++ (andObject Oriented concepts) on the workstation side, while
the code running on the microprocessors is written
exclusively in C. The User Interfaces on the workstations
are built using the VLT Panel Editor, which is based on
Tcl/Tk.
5Software test approach

The need to test software in its real computer
environment (VLT control model) was already mentioned.
In the context of testing a considerable effort has been
done during the last year in submitting most modules of
the VLT common software to automatic regression tests,
which can get repeated frequently and systematically. This
was a goal and a necessity at the same time, as frequent
releases become otherwise impossible to test (oralternatively would be of poor and non repetitive quality).
Important to note is also that test coverage has also to bemonitored and improved from release to release. Problems
which have been reported and fixed have to be picked up
one by one and reflected in an equivalent test procedure.
So test procedures get also developed incrementally during
development and maintenance.

Additionally code has been exposed to tools like Purify
and Quantify. This has made the base platform of thecommon software stable and reliable, but of course newfeatures and higher level layers have been added as well,so that problems discovered nowadays tend to be more in
the upper layers.
One constraint we have with the VLT is that non all thecontrol software is done by the same team. Software
quality and test coverage to be expected are then different
and obviously worse than if one team only had developed
everything. The final word on this will come only after thefull integration at the observatory, which has still to come.
So far we have noticed that Consortia of Institutes,
developing instruments and software for the VLT, being
typically smaller than ESO, show a lot of interest in
following certain standards, particularly when embedded
into existing software provided by ESO and are flexible inadapting to changes. Otherwise, differently than industrialcontractors, they are less used to work with appropriate
documentation and review levels, as done by the internalteam of ESO.
6Integration with data flow software

A novelty of the VLT software is the high level ofintegration achieved between the VLT control software andthe Data Flow software, providing an end-to-end concept
to the process of observing [Ref.3]. This goes fromproposal preparation via the use of Templates, to computer
optimized scheduling according to observation needs.

Several optional scenarios are then prepared for a givennight and the final choice among them has to do withatmospheric conditions etc. The VLT control software
receives observations sequenced in so-called Observation
Blocks in such a way that they can be executed by a skilled
operator, while the presence of the astronomer whoprepared the programme is not required. The VLT control
software acquires then data in the form of images orspectra, which are stored away immediately and thenarchived. Quality checks are done all along this process
and a pipeline reduction is automatically done to work out
important results. The data are ready then for packaging
and shipment to the requesting astronomer, while otherObservation Blocks are being executed (see again Fig.2).

The past period has not been one of pure developmentonly. It has been fully used by ESO also to try out thewhole VLT control software on the New Technology
Telescope (NTT) at La Silla by re-commissioning theentire control system and software in particular. This work
was the responsibility of a different ESO team who did
work in good collaboration with the VLT developmentgroup, providing a lot of useful feedback [Ref.4]. Not
always such a lucky situation can happen in a big project,but it indicates at least how fundamental early field tests
with hardware are. It shows also that in a complex system,some kind of simulation of the whole computer networkneeds to be part of the software test environment.

reachable and controllable segments, with well defined
deadlines. It is now intended to make releases less frequent
during the integration and commissioning phases atParanal and stabilize them by only fixing problems.
Testing is a strong point of the VLT control software, but
still we are working on it, because it is crucial for the finalresult. Automatic regression tests, with a good level ofcoverage, are in routine use at every release. Still
experience with a real case, like the NTT telescope,
showed that also testing with a simulated environment (theVLT control model) was needed to shorten installation
time. We have learned also that testing costs a lot of effort
and time, even when automated.
Although the system is all based on the same common
software, integration of software produced and not yet
delivered by different teams, is going to happen in the nextmonths. We have put into account some interface problems
here. The system of configuration control and software
problem reporting we have in place since the beginning,should help us in this phase of the project. The experience
gained by the NTT team in "getting things to work" in thefield shall be our background strength.
Next year the first VLT telescope will be operational andits software too.
People who wish to know more about the VLT project
can access the VLT software documentation and generalVLT documentation via a web browser, starting fromESO's home-page (URL: http://www.eso.org). This
includes access to relevant specifications and usermanuals.

8

Acknowledgements

7

Full validation of software

Conclusions

The VLT control software is ready for commissioning atParanal and a number of conclusions and lessons havebeen learned from its development so far.
The VLT control software is based on standards andpublic domain products. It enforces a homogeneous designand outlook across all the project. Looking in retrospective
design could have been more effective if it had been driven
more by scenarios and examples than by conventional
functional specifications. The transition to OO design andcoding happened in a smoother fashion than we hadenvisaged. It created a certain redundancy with existing
software, but with the advantage of allowing a transition
path to a system with an expected longer life-time. The
advantage of reusability has been already shown (e.g. 2
previous telescopes being upgraded with the samescheme).
The VLT control software uses an incremental
development approach based on Releases. This was a very
fortunate choice and allowed to break the project into

The author wishes to thank all colleagues in the VLT
Software Group and NTT team of ESO, who are the realauthors of most of the Control Software mentioned anddescribed here.
References[1] G. Raffi - Status of ESO Very Large Telescope control
software - Proc.ICALEPCS, pp.162-166, Chicago,
1995.
[2] G. Chiozzi - An object-oriented event-driven
architecture for the VLT Telescope control software Proc.ICALEPCS, pp.121-127, Chicago, 1995.
[3] M. Albrecht, M. Peron et al. - VLT Data Flow System:
the NTT prototype experience - Proc.SPIE/TCS, SanDiego ‘97 (not yet available).
[4] A. Wallander and J .Spyromilio - NTT project: a fieldtest of the VLT software and hardware Proc.SPIE/TCS, San Diego ‘97 (not yet available)