Ref: z2801162
Background: South Africa has for almost two centuries been a frequently used astronomical viewing site for the southern hemisphere and had telescopes in many different locations. As a result of urban development (lights, dust etc) in the early 1970s most of the larger telescopes were relocated to Sutherland in the Northern Cape, which, due to its height above sea level and its relatively remote location is an ideal site for optical astronomy with excellent 'seeing conditions' throughout the year. The new complex was renamed the South African Astronomical Observatory (SAAO) and it later became a national facility of the National Research Foundation.
As a result of political isolation and government's other agendas, for decades there was no new investment in major telescope infrastructure. After years of lobbying by the late Dr Bob Stobie, the then director of the SAAO, government approval was eventually obtained for the construction of what has become known as SALT (Southern African Large Telescope). The first R50 million ($8 million) required for the construction was committed by government during 1998 with the corollary that additional funding be obtained from overseas observatory partners. The final cost of the SALT project is estimated to be R200 million (~ $30 million), with operation starting during 2005. Many international partners willing to commit financing in return for observing time were found, the largest contributors being the University of Wisconsin, the Astronomical Centre of the Polish Academy of Sciences, Dartmouth College and the Rutgers University of New Jersey. Today the NRF's shareholding in this truly international venture stands at some 34%.
Introduction
Due to the cost benefits, the SALT telescope was based on the Hobby-Eberly telescope which has an Arecibo design whereby the spherical primary is fixed (in the case of SALT at an angle of 37° to the horizontal) and the movement of celestial objects is tracked using the prime focus tracker which has 10 axes of motion and will move the optical payload at up to 10 mm per second with a pointing accuracy of 6 μm (a human hair has a diameter of some 30 μm).
This system requires more complex control systems compared to traditional steerable telescopes. SALT took advantage of technological developments that have occurred since the construction of the Hobby-Eberly. A spherical telescope is less expensive to construct than a paraboloid and the SALT mirror is constructed from 91 hexagonal mirrors, each a metre across and with an integrated surface diameter of 11 m. To allow for changes due to temperature or movement each mirror segment has three computer-controlled actuators responding to feedback from edge sensors, keeping it in position with the others (and maintaining a perfect spherical shape). The initial shape is determined by use of a device mounted on a tower near the dome.
A major difference to the Hobby Eberly was a complete redesign of the spherical corrector which produces an even sharper image (0,25 arc seconds) doubling the diameter of the field of view of SALT, and is able to use the full 11 metre array when the tracker is on axis, making it the largest effective mirror installed in any optical telescope, with a light gathering power exceeding any other telescope in the southern hemisphere. Note that some steerable telescopes in the northern hemisphere are used in tandem providing a light gathering power exceeding that of SALT.
The challenge
To facilitate the development of such a complex system the telescope, including the control software, was divided into several major subsystems, these being developed by SALT, the SAAO and outside consultants. These include:
1. The structure and dome control (SDC) system to control the rotation of the upper mirror (and aperture) by means of which the telescope is pointed at celestial objects. This system also controls rotation of the dome and the opening of the structure.
2. The building management system (BMS) used primarily to control the environment within the dome structure ensuring that the internal temperature is maintained at the external ambient.
3. A tracker control (TC) system which allows the moving tracker to observe the required part of the night sky reflected from the primary mirror and to track stellar objects as they move during the night.
4. A mirror alignment control system (MACS) which is used to align the individual hexagonal segments to maintain a perfect spherical surface.
5. A tracker payload control (TPC) system that allows the tracker payload to image light onto the various instruments housed in the payload. This system operates by inserting or changing mirrors to direct light to the particular instrument.
6. A mirror segment alignment measurement system (SAMS) and a segment positioning system (SPSP).
7. An acquisition computer and a centre of curvature alignment sensor for the primary mirror.
The challenge for the SALT team was to implement a fail-safe central control system that would be able to communicate with all the subsystems and provide realtime status information and visualisation. With a dual man machine interface (MMI) input the system also had to be capable of dealing with divergent commands that could result in damage to the telescope and structure. The need for a dual MMI is that the telescope is manned by an operator and an astronomer, both of which have control inputs. A longer term objective for SALT is to let the astronomers stay in Cape Town (due to the remoteness of the site as well as the fact that in winter Sutherland is the coldest reporting weather site in South Africa) and to allow them to interface with the telescope from there.
The solution and specific novel features
The central control of the telescope is managed by the TCS (telescope control system) server written in LabVIEW, as is the controlling software on each of the telescope subsystems. Here it should be noted that largest telescopes in the world today use UNIX, C or C++ and VME hardware in their TCS. The team at SALT however wanted to perform development at a high level (as opposed to detailed), as the complexity of the control system is far greater than the case of the steerable systems. It was important to apply good software engineering practices and overcome limitations of text-based languages. They also required something that had to be reliable and maintainable over a long period of time and it had to be robust without the need for specialised software experts.
Members of the team also had their own positive experience with the use of LabVIEW and recent additions to the Hobby-Eberly, including the edge sensing system are using LabVIEW. Finally a member of the team also liaised with the developers of the SOAR (Southern Astrophysical Research) telescope in Chile which came on-line earlier this year. SOAR makes extensive use of LabVIEW and its developers provided encouragement and advice to the SALT team. The feedback from the SOAR team made the choice more credible and that together with the experience of members of the SALT team, and the fact that using LabVIEW would enable them to end up with an executable code much earlier and at a lower cost finally convinced the sceptics.
LabVIEW, being graphical and not text-based, is of course fast, scientific and easy to debug. It is also the only true engineering programming language incorporating all the features required in scientific/engineering applications and it boasts outstanding visualisation of data. The TCS communicates with the various subsystems using National Instruments' DataSocket server technology. The TCS publishes control information that is in turn read by the subsystem and the latter publishes status confirmation which is again read by the TCS. The TCS in turn receives commands from the various man machine interfaces (MMIs) and these commands are communicated in a text-based language using TCP/IP. While LabVIEW has been used in conventional steerable telescopes this is its first major application in an Arecibo layout.
Software features
The control and status clusters (clusters are LabVIEW data structures), which are communicated between subsystems and the TCS, are defined by an interface control dossier (ICD) as agreed upon by the subsystem contractors. They are transmitted in a cyclical fashion to keep the TCS and subsystems synchronised. The whole SALT system has been designed as a state-based communications system (as opposed to a command-based system), and this allows the system to recover to a particular state without having to resend commands in the correct sequence. These states are communicated to the various subsystems which in turn respond with status information to be published using LabVIEW on the TCS.
The TCS server consists of two main modules, the TCSS-HI and TCSS-LO. The TCSS-HI is responsible for coordinating the functioning of the overall telescope system via the various high-level modules such as the pointing and error management system. The TCSS-LO consists of a number of subsystem controllers each responsible for a specific function. These controllers receive commands from the command interpreter and act according to the current state of the subsystem. The MMIs, namely SOMMI (the SALT Operator work station) and SAMMI (the SALT Astronomer work station) send commands to the TCS and these text-based instructions are translated into LabVIEW clusters. Errors are reported to the SALT event logger, prompting the user to take appropriate action. Note that in terms of the MMIs, SAMMI is used for scheduling, acquisition, guidance and telescope information while SOMMI is used for telescope control, acquisition, guidance and maintenance.
When the SALT Command Language (SCL) interface receives a text-based list of commands from one of the MMIs, this is interpreted into relevant values within one of the LabVIEW control clusters. At the same time a mask is created which indicates which values in the command cluster are relevant. These command clusters are then passed on to the specific subsystem or TCSS-HI. The SCL syntax is directly derived from the Interface Control Dossier definitions and thus seamlessly adapts to changes in the interface.
The TCS software has been implemented in a highly modular fashion, each module being self-contained, performing its own initialisation and shutdown. This structure allows each module to be tested in isolation by simulating the required inputs. An object oriented approach was taken where each module contains its own data which is only modified by functions within that particular module.
In terms of the implementation of LabVIEW and to provide an object-oriented architecture an object data manager (ODM) was defined. In its simplest form the ODM is similar to a global variable, with a 'get' and 'set' action. The ODM can be easily modified to allow for greater control over data access, such as using a thread-safe ODM which locks access while a pending write is completed.
With LabVIEW one can easily create a program for almost any application and the program's software routines are called virtual instruments (VIs). Each VI can call other VIs and a collection of VIs can be stored in libraries. While VIs are easily created by the user, major built-in libraries are available for TCP/IP communication (creating and closing connections, listeners, read and write functions and IP-string converters, etc) and for synchronisation (creating notifiers, queues, occurrences, etc). The LabVIEW Function Palette has more than 20 sub palettes of built-in nodes and VIs to perform various tasks (control, numeric, reports, drivers, instrument I/O, etc). In the SALT application the VI that is to be spawned is dropped directly onto the diagram display. This allows the VI to be loaded into memory when the application is loaded, making spawning extremely fast. The SALT team created many of its own specific VIs but also made extensive use of the LabVIEW library.
In the case of SALT the subsystem controllers need to monitor and coordinate the commands sent to them but the design has to be general enough to be easily adapted to different subsystems. In this case it was decided to use complex states to track state changes in the controller. The super state is used to keep track of the controller's monitoring state with respect to the subsystem. In operation, during initialisation, the controller clears all the queues and sends a fail-safe cluster to the subsystem to ensure that it is in a safe state. In the ready mode the controller has communication with the subsystem and will listen to its two incoming queues, CI and HI, for the next command to be processed with HI having priority. If the controller loses communication with the subsystem it converts to a Fail-Safe mode and will require communication to be re-established before continuing operation. To take care of communications jitter the controller will wait in the Recovery State until it is sure that full communication is safely re-established, before changing to Ready mode.
The SALT system incorporates an error handler as communication is state-based and there is no way for a subsystem to know how to handle a control failure, or indeed to know whether a command has failed. The function of the error handler is to get the subsystem into a state where it will be able to re-execute the command and this could require a sequence of control clusters to be sent to the subsystem. As an example, suppose that the structure has failed to rotate. In this case the controller needs to stop the structure and lower it onto the pier. In the initial sequence the error handler sends a stop command and waits until the structure reports that it has reached its destination. Once the structure has been lowered it then indicates that the error has been handled and that new control instructions can be sent.
The TCS makes extensive use of inter-process communication, and where two or more concurrent processes share the data, various options are available, including a shared data space, queues and notifiers. The SALT configuration queues the data to avoid the possibility of race conditions in the case of shared data, or lost notifications in the other option. When many modules need to communicate with each other using queues, managing of these queues can be problematic. In the case of SALT a Queue-Switch is used which takes the data and destination module as parameters and simply places the data on the relevant output queue.
The visualisation screens developed by SALT's engineers are impressive, to say the least. For example, the acquisition display shows the acquired image, the mirror assembly status and the tracker display which also shows which of the hexagonal mirror elements are in use. The SOMMI (one of the MMIs) display shows the status bar with all the current subsystem states indicated with LEDs, along with the current telescope system mode. A manual control panel is also displayed which provides low-level controls for the tracker, dome and structure (see images 2 and 3).
Conclusion
Although the SALT telescope is not fully operational, some sky work has been carried out and everything is performing as expected. Of the more than 10 000 VIs used some 80% were developed by SALT and its sub-contractors. A few bugs were experienced but none were critical and the SALT developers are full of praise for the support that they obtained locally from National Instruments South Africa. Part of the success must go to the fact that a software standard was drawn up for the interfacing of the various LabVIEW programs. A lot of effort was spent in terms of the Interface Control Dossier and data types were defined for communications in accordance with the SALT Software Standard. Software developers were also required to demonstrate full compatibility with these interface definitions using simulation, before their software was implemented at the telescope.
The SALT developers are convinced that they made the right choice in selecting LabVIEW and as the telescope is upgraded over the years, and more instrumentation is added, they are confident that National Instruments' developments in terms of software upgrades will be able to keep pace.
About SALT
SALT is a South African company with international shareholding. It has contracted professional individuals who collectively form the 'SALT Team', to construct the telescope, whereafter it is handed over to the SAAO for operation and maintenance. The SALT TEAM are South African (with the exception of the optical engineer, who is from Poland), and they are responsible for the concept design, subcontracting, commissioning and testing of the telescope. Some of the more critical items such as the TCS software and Payload, were developed in-house by the SALT Team.
More information about SALT, its shareholders and the people involved, can be found at http://www.salt.ac.za.
About National Instruments
National Instruments (ni.com/southafrica) is a technology pioneer and leader in virtual instrumentation - a revolutionary concept that has changed the way engineers and scientists approach measurement and automation. Leveraging the PC and its related technologies, virtual instrumentation increases productivity and lowers costs for customers in South Africa and world-wide through easy-to-integrate software, such as the NI LabVIEW graphical development environment, and modular hardware, such as PXI modules for data acquisition, instrument control and machine vision.
For more information about the technologies discussed in this article, or about any other National Instruments offering, contact NI South Africa (toll-free) 0800 203 199, or e-mail [email protected], or visit www.ni.com/southafrica.
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version