suggestions for some single dish radio astronomy standards

SUGGESTIONS FOR SOME SINGLE DISH RADIO ASTRONOMY STANDARDS

ANDERS J.G. EMRICH, NICHOLAS D. WHYBORN Onsala Space Observatory, Chalmers University of Technology 439 92 ONSALA, SWEDEN

(Received 15 February 1991; accepted 17 June 1993)

ABSTRACT. In this paper we examine the possibility of adopting standards within the context of radio astronomy and the benefits to be derived thereby. In particular we consider the application of standards within the three areas of the receiver hardware, the control and communication between different parts of the observing system, and the interface with the astronomer. The adoption of such standards will increase flexibility of observing systems, allow the easy interchange of equipment between observatories and greatly simplify guest observing. In this paper we will only consider the application of standards within the field of millimetre-wave and sub-millimetre-wave single dish astronomy. However, the principle can be easily extended to other astronomical wavebands. We describe some current developments at the Onsala Space Observatory which illustrate the proposed philosophy and show how such standards may be implemented. Naturally, the detailed definition of such standards would have to be agreed in conjunction with other interested astronomical institutions.

KEYWORDS Standards, radio telescopes, inslrumentation, control, user interface, data handling.

1. Introduction

The system design of single dish millimetre radio astronomy instruments has now reached a fairly mature phase and the sub-millimetre instrumentation will soon follow. The general architecture of the receiver systems looks very much the same from instrument to instrument but they often differ at the sub-system level. This is unfortunate since if these differences could be removed by the adoption of a standard then it would be easy to install and use equipment from other observatories. This would increase the range of observations possible at any given site and would also mean that different institutions could specialize in particular areas of receiver development while buying other parts of the system.

An immediate need for standards exists already as there are several cases where one antenna is jointly operated and equipped by several universities, even from different countries. The lack of such standards can cause delays in the integration of different components of the observing system. It may unnecessarily restrict the range of observations that are possible because limitations in the interface between sub-systems do not allow their individual capabilities to be exploited to the full.

Experimental Astronomy 4: 41-58, 1993. © 1993 KluwerAcademic Publishers. Printed in the Netherlands.

42 A. J. G. EMRICH AND N. D. WHYBORN

Devices designed today usually incorporate at least one microprocessor thus making it possible to use high level and readable commands to control them. It is then possible to define communication standards and protocols independently of the device. For example, it is possible to have exactly the same communication standard for different spectrometers; an AOS can be made "plug"-compatible with a filterbank or an autocorrelator. Existing devices can be made compatible with a new set of standards by adding intelligence with a PC or standard bus based controllers like VME-bus CPU-boards. The cost is of the order of $2500-$4000, a small fraction of the device cost in most cases, so there is no need to scrap existing equipment. In any case, it is not necessary to convert all the existing equipment to the standard at one time; benefits will still accrue i f the equipment is updated or replaced piece by piece.

As far as the observer is concerned, there is little point in having the best receiver in the World if it can not be easily and effectively used. The adoption of a standard user interface would considerably simplify observations for guest observers; they would not have to re-learn how to make observations at each new telescope they encounter. Furthermore, it would allow the preparation in advance of a control file, perhaps with the aid of a general simulation program, containing a complete description of the planned observations thus saving time at the observing site and reducing the probabili ty of making a mistake. Such a standard would also simplify absentee observing as a user would then be able to construct her observing file and send a copy to the observatory to be run automatically.

Having a standard user interface is also of benefit in the case of remote observing. This mode of operation will almost certainly become more popular in the future as the cost of high-speed data links falls relative to the price of air travel, and considering the amount of time taken to travel to a remote observing site. Remote observing also makes practical flexible or adaptive scheduling where the observing programme is chosen on a day-to-day or even hour-to-hour basis to make best use of the prevailing weather conditions. Having a standard user interface also opens up the intriguing possibility of making simultaneous remote observations at a number of observatories, perhaps operating in different wavebands.

When the observations are finished the astronomer will want to take her data away for processing and here too the adoption of a standard for the transfer of the data helps immensely. Some standardization has already occurred in this area with the definition of the FITS format. However, this is of limited applicability in the modem workstation environment because FITS is based on the use of the almost obsolete 9 track magnetic tape. The adoption of a new standard here, perhaps using MS-DOS formatted media, would allow the transfer of data in a more compact and convenient form.

A common misconception is that standards will hinder the development of more capable instrumentation or in some way limit its performance. We argue instead that standards are needed for a continuing increase in the performance of modern instruments. Take the computer industry for instance: nobody could claim that standards like Ethemet, TCP/IP etc have hindered computer communication; that MS-DOS has raised the cost of computing; or that Unix (and POSIX) has limited the performance increase of workstations. In fact it could be argued that the introduction of standards stimulates progress by allowing effort to be concentrated in new areas instead of being wasted in areas where adequate solutions already exist.

SUGGESTIONS FOR SOME SINGLE DISH RADIO ASTRONOMY STANDARDS 43

It is easier to set standards in some areas than in others. In this paper we endeavour to point out areas where standards can be set without sacrificing performance or flexibility and where the technology exists to make the implementation simple.

To recapitulate: this paper is intended to initiate a discussion about standards within the radio astronomy community. Mostly we describe possible standards on a very general level, though we also present some examples of actual implementations developed or under development at the Onsala Space Observatory. However, the actual examples we describe are included purely for illustrative purposes. The detailed definition of any standards would, of course, be a matter for agreement between interested groups, perhaps through a joint working group.

In the next Section we give a short description of the components and operation of a typical single dish radio astronomy system and outline how standards may be introduced beneficially. In Section 3 we discus how standards may be applied to the hardware in a typical radio astronomy observatory. In Section 4 we describe ways in which it is possible to standardize communication between the various parts of the observing system. In Section 5 we focus on the interface between the observer and the observing control system including the data handling. Our conclusions are presented in Section 6. Examples of possible implementations are presented in the Appendices A.1 and A.2.

2. A Radio Ast ronomy Observing System

2.1 GENERAL

The functions of the instrumentation and electronics of a radio astronomy telescope can be grouped into four major sub-tasks: the antenna pointing (encoders, clock, tracking computer, motor control), the data acquisit ion (receivers and receiver support), the master control (scheduling, user interface) and the data processing (processing, storage, presentation). These tasks are largely independent of one another and can be accomplished with separate sub-systems each with its own controller as shown in Figure 1. Even if one computer takes care of more than one of these tasks, a clean and well defined interface between the sub-systems makes the support and development easier. As an example, in Appendix 1 we outline the proposed new observing system for the Onsala 20 m antenna.

In general, sub-systems should have well defined and simple control state-diagrams, i.e. as few control states (e.g. ON-LINE, STANDBY, FAULT, etc) as possible. This makes it easier to predict the interaction between sub-systems and reduces the complexity of the overall system control. Thereby enhancing system reliability and simplifying fault finding.


Figure 1. The system architecture: control and data flow

Three sorts of connection are required between these four sub-systems: real-time synchronization, control information transfer, and data transfer. If the real-time synchronization is handled by dedicated hardware then "asynchronous" communication can be used for the other two types ("asynchronous" meaning that the response time is not critical). The only significant difference between the control and data communication being the transfer speed required. It is possible to use industry standard hardware and software for the asynchronous communication: Ethemet, token ring and serial lines can be used and standard high level features like file transfers offered by, for example, TCP/IP can aid in the system development and make the system more reliable and portable.

All communication between the sub-systems are handled with simple high level commands and form an Instrument Control Language (ICL). The commands should be independent of the hardware being controlled. For example, the pointing system, on being ordered to track a source by the control computer, searches for the coordinates in a common source list and tracks that position. The source list is in a standard format, e.g. name, RA & dec(2000), v(lsr), etc. All translations would be handled within each sub-system so the astronomer would still have the option of entering and displaying coordinates in whichever system she preferred. Note that the observer is not required to know anything about the ICL which is only used for inter sub-system communications.

Master control s, stem Antenna poinfin~., rstem

I Schedule] [Antenna SOOiCEonono

!. ! Database ~---. , ----~ Translati0n

RA and DEC epoch 2000

Figure 2. Data flow example

The user interface has two defined levels: the interface for engineering staff designing and maintaining the sub-systems including hardware and software design guide-lines, and the interface used by the observer. The latter should be standardised and site- and instrument independent The astronomer interface consists of the Observation Description Language (ODL), the data storage database format and the log file formats.


2.2 SYSTEM CONTROLLER

The system controller acts as a co-ordinator between the different sub-systems and the user. The features required are: a user interface with a means of loading source lists and observing files, and control communication links to the other sub-systems. The system controller should provide different security levels for different types of users such as the astronomer, the chief scientist and the engineer. The astronomer interface should focus on what observations have to be done by the system, not the details of how to do it. Finally, and perhaps most importantly, the system controller should document the progress of the observations by automatically logging operations and system status in a file.

The easiest way to implement a secure and, at the same time, user friendly system is to base 9rocedures, parameters and commands on lists or databases. The system should provide lists of 'font-end frequency set-ups named after molecule transitions, a library of sources, back-end set- ~ps named in a logical manner and so on. All ordinary observations are then done from lists vhere the observer selects the most appropriate configuration for the observations in hand. Both ommon and private user lists would be supported so the user would retain the freedom to define er own sources etc. In order to make the lists more transportable and consistent it should be

based on one format only, e.g. the source coordinates in RA and dec at epoch 2000. This would not limit the user to one coordinate system since conversion between the standard and other popular systems would be handled automatically by the user interface; the observer should never need to look directly at the source-list file.

The system should provide enough intelligence so that fairly advanced operation is possible without human attention. It should be possible to specify a certain noise level to be reached in each pixel in a map, a change in source depending on elevation and so on. The system controller should also generate log files showing the status of the system throughout the observations allowing errors and faults to be traced.

By using a standard ODL, good documentation of observations will be automatically provided and advanced scheduling becomes feasible. As the ODL is purely text based, any modem computer system can interact with the control system, thus facilitating remote observing. Going further, if X-Windows TM, say, were to be adopted as a standard graphical interface, completely interactive graphical remote sessions become possible.

2.3 ANTENNA CONTROL AND POINTING SYSTEM

The antenna control and pointing system should work as a self-contained system accepting commands which are independent of the actual telescope hardware. The system should receive observing commands from the system controller in a device and time independent format and handle all calculations and telescope control based on that information. In return, this system should provide the controller with telescope position and status, weather information and time when requested. The pointing system must also be able to communicate with the data acquisition system via a synchronization bus for time-critical control functions such as are required for position switched observations.

The features needed in the pointing system are a two-way communication interface, a real-time synchronization interface, an accurate clock, input from encoders and other kinds of sensors and


output to the motor control units. The sub-reflector and image de-rotators in imaging systems should also be part of this sub-system. To facilitate synchronization with the receivers and other sub-systems, the pointing system should be able to work at least as a master on all the lines described in the synchronization specification of Section 3. The control language is outlined in Section 4.

2.4 DATA ACQUISITION SYSTEM

The data acquisi t ion system is defined as including all units involved in receiving the astronomical signal from the sky, excIuding the antenna. It should be independent of the host antenna, that is it should be at least theoretically possible to transfer one data acquisition system, or parts of it, from one antenna to another. We return to the hardware interface definition in Section 3.

The data acquisition system should deliver calibrated data together with all possible on-line information used such as zenith opacity, weather parameters and known system errors. It should also be able to take simple decisions regarding time intervals between calibrations and when to start the next integration based on the observed system noise level. All system noise specifications should be referenced above the atmosphere.

At power up all receiver hardware should configure itself to a well defined default configuration, if possible preceded with a self-test. The hardware should also incorporate some means of self- calibration as a check on performance, to facilitate easy system integration and for fault finding.

2.5 DATA PROCESSING SYSTEM

The data processing system should provide automatic data reduction as well as interactive features, tt should also automatically generate a log of the processing that has been applied. The system should work with high level database facilities, indexing data in a logical manner, i.e. by source, time, frequency and position, and not by an irrelevant scan number. This is no luxury; the new imaging systems under development promise to produce one to two orders of magnitude more data than current systems and current data handling methods used at most observatories will not be able to cope with the flood of data.

The standard should define formats and protocols to be used for data transfer between the sub- systems. A convenient solution is that the data acquisition system and the master control system send the data files to a specified sub-directory on the data processing computer using a standard file transfer method supported by the systems involved, e.g. FTP in the case o f UNIX systems. The data handling and file formats are discussed under Section 5.

.


Data Acquisition System

47

3.1 GENERAL

This is the most complex and rapidly evolving system and, therefore, both the hardest to standardize and the system most in need of standards. A big advantage can be gained if receivers are built to be as self-contained as possible, e.g. a heterodyne "front-end" should include the complete local oscillator system and not rely on external shared components. Each sub-system should include its own tables of tuning and calibration information so that control commands can retain a very general nature.

The quasi-optical coupling of the receiver system to the antenna is unfortunately very hard to standardize as antennas vary in their design. The receiver system can be of two kinds: a direct detection system or a heterodyne system. The direct detection device is often a complete receiver while the heterodyne system is often divided up into a "front-end" and a "back-end". The reasons for this are economy and flexibility; several "front-ends" can share the same "back-end" and vice versa. In the case of mm-wave and sub-mm receivers this connection is usually made at an intermediate frequency (IF) of a few GHz.

All receivers need a control and data read-out communication interface and a real-t ime synchronization facility. In addition, the heterodyne "front-ends" and "back-ends" need an intermediate and reference frequency interface. A big advantage can be gained by wherever possible making use of standard commercial hardware, such as VME, for the control electronics and i/o.

32 W INTERFACE

In order to standardize the IF interface it is necessary to specify the centre frequency, power levels, matching requirements and spurious signal levels. Traditionally, two IF-frequencies have been used almost exclusively, one centred at about 1.5 GHz and one near 4 GHz. Therefore, it is not very controversial to base standards on these two frequencies. When front-ends and back-ends are separated by more than a few metres, near baseband frequencies are sometimes used. In this case the region from 0 to 200 MHz should be avoided as this range is prone to noise from digital signals in the system.

As the receiver systems are reaching the sub-millimetre range the bandwidths should be made as wide as possible, 1 GHz is reasonable as the maximum allowable bandwidth for the lower frequency and 2 GHz for the higher. Devices not using the full IF bandwidth should, nevertheless, have a standard centre frequency, so a 500 MHz bandwidth spectrometer at the lower IF-band should cover 1.25-1.75 GHz. Equipment should avoid generating strong signals in the IF-bands to avoid possible interference problems. Even if the spectrometers in use only cover parts of the IF-bands it is a good idea to reserve the whole of those bands for future expansion.

The power level from a front-end should be high enough to reduce sensitivity to interference and low enough to avoid saturation in amplifiers, a spectral density of -25 dBm/GHz seems a


reasonable compromise. The output level from a front-end can vary by up to 5 dB depending on frequency, calibration levels, atmospheric opacity, etc. Therefore, back-ends should be able accommodate this variation with room to spare. The allowable pass-band ripple depends on the type of spectrometer but a specification of t dB seems desirable. Other in-band variations, such as a gain slope, are probably not so important. The spurious signal outputs and responses should low enough to avoid interference problems; a combined spurious signal suppression of ---50 dB should be adequate. The IF's are then specified to be:

Specification IF I Centre frequency 1.5 GHz Frequency band 1-2 GHz Power level -25 :t:5 dBm/GHz Impedance 50 f~ Return loss > -20 dB Total in-band variation < 3 dB Ripple (over <100 MHz) < 1 dB Spurious outputs (front-end) < -50 dBm Spurious responses (back-end) <-30 dB

I F I I 4 GHz

3-5 GHz

This frequency plan makes the bands 2.5-3 GHz and 5 GHz and above available for local oscillator and other signals, and the band 0-200 MHz available for data communication and reference frequency distribution. A 100 MHz sine wave reference signal at 0 dBm could be used for all sub-systems.

Front-end receivers should have at least two parallel IF outputs thus allowing simultaneous operation with more than one back-end, while a minimum of two switched inputs should be provided in back-ends. At telescopes where a limited number of cables are available for signal distribution between the front-ends and back-ends then an IF multiplexer would be needed to select the receiver combination. In cases where the front-end and back-end do not use the same IF then a frequency converter would be required.

3.3 SYNCHRONIZATION

Single-dish observations are usually made in some kind of differential mode, switching between the "signal" and a "reference". During the transition between these two states the data-stream may be corrupted and some blanking feature inhibiting integration must be used. Since other faults can also corrupt the data, e.g. bad pointing or phase-lock problems, a multi-master capability for data blanking is almost essential. When a set of "signal" and "reference" spectra have been taken, some signal to start a new set is needed. Although this transition usually occurs on time-scales of the order of seconds to minutes and can be handled by computers, a hardwired signaling capability renders the real-time performance of the computer system completely irrelevant.

The synchronization between different sub-systems in existing instruments has been solved with either a central high-performance real-time computer or simple hardwired schemes. The first approach is fairly general but requires special real-time facilities of the operating systems making the software non-portable; it also constrains the system into a centralized architecture. The second


solution usually requires a redesign to incorporate new sub-systems and advanced features are very complicated to implement.

Here we propose a new approach based on a general synchronization bus. This bus can be used for synchronization on time-scales of from a few microseconds to minutes or more. The bus consists of the definition of the scheme and a description of a hardware solution. The definition has two levels: one basic configuration for synchronization consisting of four lines, and an outlined extension with communication facilities. It is possible to implement this scheme with several different kinds of hardware. In Appendix A2 we discus the system being built at the Onsala Space Observatory [2].

4. Sub-system Communicat ion

4.1 INTRODUCTION

The communication hardware and software between different sub-systems should be as simple as possible, yet provide high transfer speeds if needed. It should be easy to debug and be based on industry standards. The simplest interface is the serial terminal interface, TTY or VT100, which is supported on most hardware platforms. This can be used to send commands between different sub-systems. Several hardware solutions can be used as most network protocols provide a virtual terminal facility, i.e. TELNET in the case of TCPflP. IEEE-488 can also be accommodated using virtual serial drivers. The reason for allowing different hardware is that although an advanced sub-system like a spectrometer may use Ethemet to allow high transfer rates this would be overkill for simple systems like a weather information unit or a sub-reflector controller.

More complex set-up information for advanced devices can be formed by a set of simple commands collected together in a text file. The same interpreter can then be used but with a file I/O stream substituting the terminal I /0 stream. The files should be made available to the sub- system in some way; on a RAM disk, on a local floppy or hard-disk or a remotely mounted disk over a network. The transfer can be made by KERMIT in the case of a serial interface or by FTP on Ethemet. The data can be delivered in the same way in a standard format by switching the communication direction.

In general, we propose that sub-system controllers should have two tables of parameters available for controlling their operation, one for the current setting and one for the next setting. Thus the settings for the next operating mode, frequency, source etc., could be loaded while observations continue uninterrupted. After the "next settings" table had been entered, and upon receiving a signal or command, the sub-system would change to the new setting.

4.2 THE INSTRUMENT CONTROL LANGUAGE

This language is used for communication between the component units of the observing system and as such would not normally be visible for the observer. We envisage that the ICL would consist of two distinct types of commands: High-level commands of a universal nature would be used for the normal control and operation of sub-systems. Low-level , device dependent commands would be used for engineering and test purposes and may also be required to control


unintelligent units. The commands should be readable by humans, they could be separated with semi-colons and executed with return or enter. In operation a dialogue should occur between the controller and the sub-system as commands would be acknowledged by the receiving sub-system.

The ICL could be based on SCPI [1] (Standard Commands for Programmable Instruments), which is an extension of IEEE-488.2 and backed by an industrial consortium. SCPI is based on an hierarchical structure of commands, a tree structure. On the highest level is the root command or simply the root. Moving down in the command tree is done by separating commands with colons while using a semi-colon separates commands without changing the level or path. In addition, there are common commands like *RST (RESET), which all start with *. These can be used in any instrument state or anywhere in the command tree. See SCPI documentation for more details.

4.3 SYNCHRONIZATION COMMAND STRUCTURE

Three logical signals are needed for synchronization and each device must be programmed to control or respond to these l ines to execute the desired sequence of observations. The configuration of a device connected to the synchronization bus can be for either master (M), slave (S), or don't care (X) operation. The switch-period and integration time must be specified in the devices which are masters on the lines SR or NX. Integration time may be specified either as absolute (A), or effective (E) to take into account any lost integration time due to data b l a ~ i n g - absolute and effective integration times may differ substantially.

4A COMMANDS FOR THE ANTENNA POINTING SYSTEM

Following the general principles outlined above, the antenna pointing system would have two source descriptions at any given time, the current and next source. The source description would include not only the source centre position but also other source related parameters such as proper motion, redshift, and the definition of any possible local coordinate system used for mapping it. Three pointing modes are required: tracking a "fixed" position defined by reference to RA-Dec(2000) coordinates at specified times, tracking planetary objects with positions derived from an internal ephemeris, and tracking to a fixed position in telescope coordinates.

4.5 COMMANDS FOR FRONT-ENDS

The fundamental command for controlling a heterodyne receiver is to set the observing frequency. For uniformity, the frequency specified should be the sky frequency that corresponds to the standard IF band centre. This together with Doppler information from the antenna pointing system should allow all receiver parameters to be determined by reference to look-up tables contained in the receiver controller. A few other commands will be required during normal operation for initiating calibration, enquiring after system performance and selected sideband, etc. As before, there should be two receiver settings stored in the controller, a current setting and a next setting. Receiver retuning would be initiated by the command ~OTONEXTSETTING. The same principles could apply to continuum front-ends and beamswitch systems. Low-level commands of a device-dependent nature would only be used by the engineering staff for the maintenance and testing of the systems.


4.6 COMMAND SYNTAX AND DATA FORMATS FOR SPECTROMETERS

The control of a back-end should follow the same rules as for a front-end with current and next set-ups defined. Here the major parameters to be specified are the resolution and number of channels.

The back-end should deliver data in a standard format to the data acquisition system. The format would be the same as the general file format used in the data handling system, but with spectrometer- instead of sky-frequencies and leaving empty spaces for the source position parameters. The frequency parameters should be given relative to the centre of the IF-band. The filename of the spectrum could be used to identify the type of spectrum, the spectrometer input port, a sub-band specification and a time stamp.

5 Observer Interface

5.1 OBSERVATION DESCRIPTION LANGUAGE

The observation description language should be easy to read and write for an astronomer as well as easy to implement on the on-line system. It should, furthermore, allow flexibility for the various types of instruments used at different observatories. The example below shows a possible style that fulfils at least partly the specification above.

USE SOURCELIST "userkSockerConny\sources"

USE MAPLIST "user\SockerConny\maps"

USE FRONTEND sis3mm WITH ml3COl0

USE BACKEND hybridspec WITH hspSOOMHz

LOG weather EVERY i0 min

LOG azel EVERY sourcechange

LOG systemtemp EVERY calibration

DATADUMPTIME=30 S

SAVE final, calibration AT

"SUNSPARCII\user\SockerConny\data"

USE SOURCE irasl0216 ~

USE MAP iras2025CO

OBSERVE PATCH theleftpart UNTILRMS<0.01 K

OR INTT~ME>500 S

tells the computer to use the source list in sub-directory SockerConny in main directory user

sends the f i le m13C010 to the device with the name sis3mm sends the f i le HSP5OOMHz to the device with the name hybridspec

dump time save f inal and calibration spectra at computer and directory ... source defn. in RADEC2000 map tilt, grid and patches "theleftpart" being defined in the map list


5.2 LOG FILES

The log files should be produced automatically by both the system controller and data processor and should list commands issued, actions taken, and system messages. The format of observation log files should be based on a time stamp, indicated with the keyword T ZME, with a list of events and status at this time. Separate files could be kept for each observer, with a new file started every day.

The data processing log file could have the same general format as the observation log file but recording the commands executed by the data processing software instead.

5.3 REMOTE OBSERVING AND TIME-SLICED OBSERVATION SCHEDULING

It is rather surprising, considering the time and cost involved in travelling, that observing systems are seldom planned to cater for remote operation. Often the observer flies halfway around the earth only to sit in front of one or several computer terminals. With well thought out standards, both control information and data can flow transparently and effortlessly back and forth over the globe much more easily than the observer! This then opens up the possibility that one observer could control several instruments in parallel, even synchronously, allowing multi-spectral, simultaneous observations of the same object.

Many observations in the sub-mill imetre band are heavi ly dependant on the weather and instrument performance - good and reliable data can only be obtained at certain unpredictable moments. Observatory scheduling is usually fixed many months in advance making it difficult or impossible to make full use of any chance good weather. Thus it often happens that non-critical observations are performed when the weather is perfect, while critical sub-mm observations may never be performed because the weather was bad at the allocated time. Another problem is that a system failure can disrupt a complete observing session for one astronomer.

These problems can be solved by adopting a new automatic time-slice observing mode or flexible scheduling. This mode works in the following way: Several ( t0-50) observation jobs are submitted in the ODL format to the instrument control system every observation period (say 1-4 weeks). Every 1-2 hours, say, the system considers all relevant parameters, such as weather, system noise, etc., in relation to the observation job list and runs that job which is most suited to the prevailing conditions. This can be seen as a "Weiner Filter" approach to scheduling: matching observations to the system performance.

In certain cases extra conditions could be specified, that certain jobs must be completed uninterrupted for instance, without sacrificing the main idea. A system breakdown would then only cause a delay of a couple days for a number of observers, and if only one instrument goes down, other jobs not requiring that instrument could be scheduled and no observing time is lost.

Interactive observations could still be supported to some extent. Most astronomers would receive data (and log files) back every day using standard WAN file transfer facilities. This data can then be analysed and modifications to the job description could be made before the next time-slice is allocated.


5A DATA HANDLING PHILOSOPHY

Data transfer is perhaps the one area within radio astronomy where a standard exists, namely the FITS format. However, at present FITS has several shortcomings: it does not support hierarchical data structures (directories, sub-directories, etc), does not follow relational database theory in that it often contains redundant information, and has many site-dependant, non-universal keywords. Developments of FITS now in progress may well remove these limitations but we will nevertheless set down here some suggestions for a modem standard in this area.

Data storage and processing is a direct extension of the sequence: observation planning, actual measurements, and on-line data reduction. Therefore, it is reasonable to keep this thread as intact as possible and generate a database directly from the observation schedule. The database could be loosely based on relational database theory, keeping as little redundant information as possible and at the same time providing advanced search and select tools. The database should fulfil three functions in addit ion to data storage: keeping a record of the observations, supporting observatory archiving of data, and providing a base for data reduction.

The data storage structure should use the native file system so that ordinary operating system tools can be used to organise the data. All major operating systems now support hierarchical file systems which can then be used to divide the data into manageable blocks. All information to do with one project or sub-project could then reside in one directory named after the project. The directory would contain one database file, an observation log file, a data reduction log file and a number of data files. A data file should have a minimal header and contain only one set of data, i.e. one spectrum per file in spectroscopy. The database file can be used both as the selection and sorting index for the spectra as well as a place for storing and processing data derived from the spectra, like mean velocity or total integrated power.

5.5 DATA STRUCTURES

The database file consist of a general information header, a spectrum type list, a source Iist and a spectrum list. There could also be a list defining detector specific items for imaging receivers etc. The database files could be expanded with more items during processing, like total power or mean velocities, and this information could then be used both for sorting and searching as well as for plots and analyses.

5.6 LOW LEVEL FORMATS

The main specification is that the native file system should be used on the machine. With some effort, this will make it possible to operate the system on a number of different computers connected with local area networks. Data can then also easily be transferred with tools like FTP under TCPBP between different machines, even over continents.

For data transportation between machines not connected to a network or for larger amounts of data there are several possibilities. Right now, the least common denominator between modem computers is the 3.5" floppy. It is supported on DOS-machines, 386 and 486 UNIX machines, Macintosh, Amiga, Atari, OS/9 and workstations from DEC, HP, SUN and even NEXT. Most, if not all, of those machines can read and write in MS-DOS format, making it possible to keep the complete hierarchical directory structure when transferring data between different machines.

54 A.J.G. EMRICH AND N. D. WHYBORN

When standards are created for read/write optical disks and DAT-tape drives, the format can be used directly and no new translator needs to be written.

6 Conclusions

We have attempted to show that there are large benefits to be had by the implementation of standards at radio astronomical observatories and have suggested ways in which such standards may be formulated. Standards defining the interconnection, communication and control of the various parts of a radio astronomy observing system will increase the flexibility of the instrumentation and simplify system integration. A standard observation description language would be of great benefit to astronomers and especially guest observers while a standard format for transferring sorted data between observatories would simplify the use of database soRware required to handle the large amounts of data expected from the new generation of imaging radio telescopes.

Acknowledgements

We gratefully acknowledge Stefan Andersson for many helpful discussions and suggestions regarding the synchronization hardware.

References

[ 1 ] "Beginners guide to SCPI", Hewlett-Packard, 1990

[2] Andersson, S. & Emrich, A.: 1991, "A System Management Bus", Onsala Technical Memo.

[3] Emrich, A.: 1990, "A Flexible Hybrid Spectrometer for Balloon Bome and Ground Based (Sub)Millimetre Wavelength Astronomy", Experimental Astronomy, 1, pp 227-235.


Appendices

55

A.1 Examples of Implementations

The Onsala 20 metre antenna is currently undergoing a major renovation with the control system being replaced and the antenna surface being upgraded. The new control system has been designed according to the ideas outlined in this paper and this has simplified the development considerably. An overview of the system is shown in Figure A. 1.

The System Controller and the Data Processing System will be Unix workstations in the 40+ MIPS range from HP. These will communicate with the other sub-systems using TCP/IP via an Ethemet link.

°

:ASS ~ASS A B

VME CME

Control System [ii] Data Processing [i!~ Master fill System

lIP720 Crate

management bus

Ethemet control bus ~ ~ ~ ~ ~ ~

Figure A.1. The proposed control system for the Onsala 20 meter telescope upgrade. FASS A&B are two spectrometer crates and SISYFOS is a 100 GHz imaging receiver presently under development. The System Resource Crate incorporates, frequency & time standards, alarm functions, System Management Bus monitoring etc.

The Antenna Control And Pointing System (ACAPS) is a dual processor system with software running under the OS/9 operating system in a single VME-crate. The host is a FORCE M68040 board with Ethernet and SCSI interfaces while a MEN M68332 board is used to implement a software based numerical control loop for the antenna slewing and tracking servo. Ten VME

56 A. J. G. EMPdCH AND N. D. WHYBORN

boards in total are used to implement all the sub-system tasks: antenna position measurement, slewing and tracking servo loop, sub-reflector control, coordinate transformation, TCP/IP communication, motor amplifier control, monitoring antenna safety, synchronization interface, absolute time tracking and many more. The VME-board functions are outlined in Figure A.2.

Figure A.2. ACAPS: a block diagram showing the control crate boards, interconnections, and I/0 connections. The six boxes on top indicate boards which use the fuU VME interface, while the lower five only use the VME backplane for power and ground connections. As the backplane can accept 20 boards, there is plenty of room for expansion.

A flexible hybrid spectrometer (FASS) with up to 16 W-channels is also being built according to the philosophy presented here. The spectrometer has a maximum total bandwidth of 5120 MHz with -- 6800 effective spectral channels [3]. The system uses two FORCE M68040 boards, four MEN M68332 boards and is divided into 6 VME crates. Communication is provided over Ethemet via TCP/IP in the same way as for the Antenna Control System.

Awaiting a new generation of millimetre receivers for the telescope, an intelligent controller is being added to the current 3 mm system. A MEN M68332 board with an Ethemet module will be added to the existing control electronics and the IF interface will be modified to follow our proposed standard. Planned new receivers and associated controllers will be built according to the guide-lines outlined in this paper.

A standard synchronization bus interface board developed for use in the antenna control system, front- and back-ends is described in more detail in the next Appendix.

Wherever possible, we have made extensive use of standard, commercial products in designing the systems discussed above. Also, much of the electronics and software in each of the sub-systems outlined above is identical, thus reducing development times.


A.2 Synchronization Bus Implementation

57

A.2.1 SYNCHRONIZATION PROTOCOL

The suggested bus standard consists of four defined lines. The three synchronization lines are called DATA VALID (DV), SIGNAL/REFERENCE (SR) and NEXT (NX). In addition, a FREQUENCY/TIME (FT) line complements the asynchronous ones to make synchronous services available.

DV: DATA VALID is capable of multi-master operation; any connected device can pull it low. At the same time it functions as the enable signal for the other lines, i.e. the other lines are only defined when DV is low. The meaning is obvious: when data valid is true, the signal is reliable. Data acquisition can then be paused by any connected unit pulling this line low, on release the integration can continue.

SR: SIGNAL/REFERENCE describes the state of the switching arrangement. This line can only have one master at a time but can be used by any device that acts as a switching master, i.e. a beamswitch, the local oscillator for frequency switching and even by back-ends with limited asynchronous switching capabilities such as AOS's. In the suggested implementation this signal must be defined 100 its before DV goes from low to high and must be held for at least 100 its after to ensure error free latching, i.e. the SR-master must pull down DV before changing the state, Usually this means that the line must be defined at all times except when the SR-master pulls DV low to be able to change state.

NX: NEXT is used to start a new spectrum or set of "signal" and "reference" spectra and,possibly, move on to the next source position. If it is high when DV goes from low to high it means that the data should be stored in a new accumulator for the next integration period. The state of the signal must be defined 100 Izs before DV goes from low to high and must be held for at least I00 /zs after. It must also have a minimum pulse width of 100/.ts. Both the receivers and the antenna control can be used as masters.

FT.- FREQUENCY/TIME is a frequency reference with a superimposed one-second tick. We suggest using a 250 kHz signal which can also be used for implementing the carriers on the three synchronization lines if a carrier on/off type of logic is used.

D V I l l I I . . . . . . . . . . . i,,,,,I I

SR [1 I I NX jJ !1

new signal data signal signal new spectrum reference blanking reference reference spectram antenna change phase- change change antenna pointing beam lock beam beam pointing system switch switch switch system

Figure A.3. An example timing diagram.


A.2.2 A SYSTEM MANAGEMENT BUS

If complemented with a few additional wires, the synchronization bus could be expanded into a system management bus. Suggested services would be two network lines and two auxiliary lines to be defined by each observatory. The network lines can be used to send simple commands, status information and alarm signals between connected units. The network standards should be based on existing ones, AppleTalk TM or PROFIBUS are promising alternatives for the low level protocols, or OS/9 NET could be used for both low level and high level protocol implementation.

A.2.3 THE HARDWARE

Our SMB hardware has the following characteristics: • All 8 lines have the same implementation (FSK, transformers and twisted-pair

hardware). • Multi-master operation on the DV-line using frequency detect. • Bus operation uninterrupted by power down of any connected unit. • Bus can be extended by a fibre-optic link • Operation reliable up to 300 m total bus length. • TTL and CMOS compatible user inputs and outputs of the bus drivers/receivers. • Single 5 Volt power supply for the bus drivers/receivers. • Sufficient drive in the bus drivers to fan out up to 32 bus users.

/ - [

:~:.:i!i!!!?::~:~5:!:~

':~:;ii!!~ii!i',~N i

SYSTEM MANAGEMENT BUS: TERMINATI'N ~ ' 8 RS-485 twisted wire pairs ,, ~ OMN~D C u ~ T ~ ~

USER ~

SMB USERS (1-32)

Figure A.4. A diagram showing a simple system management bus configuration.

suggestions for some single dish radio astronomy standards

Documents