OPERA

The complete collection of software for controlling ALIS is called an OPERations system for ALIS (OPERA). The three main components of OPERA are briefly described below.

User interfaces

The main graphical user interface for ALIS is an X-windows application (parsifal ) that has been supported on various computing platforms (HP-UX, Sun-OS (Solaris), GNU/Linux, Windows-95 and Java). It provides a user-friendly way to configure and run ALIS as well as to display quick-looks and status information. Commands can be sent to the system, either by user-defined menus or directly by typing them on a command line. From parsifal it is possible to monitor and control ALIS in many ways, to receive and view quick-look images, to communicate with other ALIS users, to upload experiment configurations, etc.. A text-only user interface, (tosca ), is available for controlling ALIS over slow communication lines (implemented in Lisp as a major mode for the Emacs editor). From around 1999, as the stations become networked over ppp (Section 2.2.3) it also became possible to configure and control the stations over direct TCP/IP connections (for example by making a direct telnet login to the desired station computer). It is foreseen that the need for a dedicated control centre and special user-interfaces will vanish as it will be possible to control ALIS from an ordinary web-browser in the future.

AIDA

A central set of server processes, Alis Internal Data Administration (AIDA) runs at the control centre, accepting connections from user interfaces and directing user-commands to the desired set of stations. Furthermore, requests from the stations affecting users, or other stations, are routed to their proper destinations. AIDA also handles alarms and other exceptions and activates the paging system if no user-interface is online. The concept of AIDA as a central node (or crossbar-switch) has survived since the first implementation (around 1992), but is subject to change in the future as all stations become networked. When this happens, a central node is no longer required, as this functionality can be undertaken by any station. Therefore the need for a dedicated control centre will also diminish with time. All of the AIDA software was written in a Unix/C environment from the beginning, first under HP-UX and later ported to GNU/Linux. A block-diagram of the AIDA software and user interfaces appears in Figure 5.1.

Figure 5.1: Block diagram of OPERA. Any number of user-interfaces (parsifal , tosca ) can connect to AIDA in order to control ALIS. In AIDA a central supervising process V (verdi ) routes all information between the different user-interfaces and the stations. The stations are connected to verdi via an interface process, R (radames controls a RS-232 serial line and a modem, or rigoletto that provides a TCP/IP connection to a station over an existing network connection). The control centre status display map (Figure 2.7) is connected in the same way as an ALIS station. The user-interfaces labeled ssh and http indicate the possibility to control the stations over a shell-login, or from a standard web-browser. This will eventually make the control centre software superfluous, as the functionality of AIDA will be available at each station.

See [Nilsson, 1994] for a more detailed description of AIDA.

Station software

The present ALIS stations are to a large extent controlled by station-control programs running in the station computer (SC). As long as MS-DOS was used as the operation system for the station computer (Section 2.2.6) a huge application program (HENRIK ) controlled the station. Due to the many and absurd technical limitations of MS-DOS, this program had problems meeting the required specifications, especially with respect to speed, reliability and the data-handling capacity. As GNU/Linux emerged as a reliable and free multi-tasking operating system, it was quickly realised that a change of operating-system at the stations was top priority. Around 1997, HENRIK was quickly ported to GNU/Linux; the resulting program was called arnljot . Although this was a major improvement, it was still a ported huge MS-DOS program including large amounts of code written exclusively to bypass MS-DOS limitations. To remedy this, a major rewrite of the code was initiated, removing all ``MS-DOS-artifacts'', as well as splitting the program in three parts: aniara handling the overall station control and communication with the control centre; mima , controlling the imager; and nipu handling the NIPU, (Section 2.2.2). These programs have been in routine operation since 1999.

aniara

supervises most functions at the station and provides an interface to AIDA. Among many other things, aniara handles alarm conditions, stores configurations, and acknowledges ``sanity-checks'' sent from the Housekeeping Unit (Section A.4) after verifying that the station computer is operating properly. A simple text-oriented user interface to ALIS, mainly intended for system maintenance is also provided by aniara . As AIDA is slowly phased out, aniara will most likely take over some of its functionality.

mima

is the imager control program. It boots up the camera-control unit (Section 3.3.2), configures the imager (Section 3.3.3), retrieves the image-data as well as creates and saves FITS images onto the local disks (Section 2.2.5). This program is thus responsible for putting all the supplementary information into the FITS header (integration-time, filter, UTC, viewing direction, CCD-temperatures, etc.).

nipu

is a program for controlling and booting the NIPU. This program is used to calibrate the FPS and CPS, select filters (Section 3.5) and viewing-directions (Section 3.6).

Apart from the software discussed above, it is also worth mentioning the following software packages at the station:

CCU-software:

Vendor-provided Transputer binaries for the camera-control unit (Section 3.3.2). This code is uploaded by mima during the imager boot-up phase.

HU-firmware:

The Housekeeping Unit (Section A.4) firmware is written in assembler and stored in an Erasable Programmable Read-Only Memory (EPROM). It provides low-level interfaces to various GLIP systems (Appendix A), watchdog functions for the station computer, as well as alarm and error-recovery functions. If the station computer is shut-down or malfunctioning, the housekeeping unit will take over the communication line and alert the control centre about the error condition at the station. It is then possible for the operator at the control centre to communicate directly with the housekeeping unit to diagnose the situation and often resume normal operation in less than ten minutes.

ntpd

This freely-available daemon controls station timing (Section A.5).

NIPU software:

Software for the Transputers in the NIPU are uploaded at NIPU start-up by the nipu program at the station computer. The NIPU software was written in Occam and Transputer-C.

Figure 5.2 presents the interrelationships of the various software at the stations superimposed onto a block-diagram of an ALIS station (Appendix A).

Figure 5.2: ALIS station software superimposed onto the block-diagram of an ALIS station (refer to Figure A.1 in Appendix A); mima uploads the vendor-provided CCU-software and controls the imager; nipu uploads the NIPU software and controls the CPS and FPS; aniara is the main station-control program. The housekeeping unit is controlled by firmware in an EPROM.

Experiences and future plans

ALIS software has now existed for over a decade. During the early years, technical obstacles, and in particular problems related to the many limitations of the operating system at the stations, dominated. Following the major OS upgrade to GNU/Linux, most of these software problems have now been eliminated. The importance of reliable and free operating systems cannot be over-estimated. Many man-years of programming efforts could have been saved if proprietary software could have been avoided in the first place.

Regarding the user-interfaces, it seems inevitable that an effort will be required to create a web-oriented standard user interface for ALIS. AIDA will probably be depreciated in favour of moving this functionality to the stations. This will also increase redundancy of the ALIS control system. At the stations a simple and flexible approach seems to be to let each major functionality to be represented by an application program. An interesting development is the networked ``parameter-server'' that can be used to configure ALIS as well as to retrieve status information in a consistent way over the entire network of stations and user-interfaces.

The lag between the desired and present control system for ALIS is in the order of 1-2 man-years. Finally it should never be forgotten that software development is an evolutionary process that requires continuous upgrades and maintenance.