A&A 395, 727-731 (2002)
DOI: 10.1051/0004-6361:20021318

RTML - a standard for use of remote telescopes

Enabling ubiquitous use of remote telescopes

C. Pennypacker1 - M. Boer2 - R.  Denny3 - F. V. Hessman4 - J. Aymon5 - N. Duric6 - S. Gordon7 - D. Barnaby8 -
G. Spear9 - V. Hoette10


1 - University of California, Lawrence Berkeley Lab, Bld. 50, room 5036, Berkeley, CA 94720, USA
2 - Centre d'Étude Spatiale des Rayonnements (CESR/CNRS), 9 Av. du Colonel Roche, BP 4346, 31028 Toulouse Cedex 4, France
3 - DC-3 Dreams, SP,6665 E. Vanguard St., Mesa, AZ, 85215, USA
4 - Universitats-Sternwarte Gottingen, Geismarlandstrasse 11, Gottingen, Germany
5 - University of California Lawrence Berkeley National Laboratory, Bld. 50, room 5036, Berkeley, CA 94720, USA
6 - University of New Mexico, Department of Physics and Astronomy, 800 Yale N.E. Albuquerque, NM 87131, USA
7 - University of California Lawrence Berkeley Lab, Bld. 50, room 5036, Berkeley, CA 94720, USA
8 - Western Kentucky University, Department of Physics, 1 Big Red Way, Bowling Green Kentucky, 422101, USA
9 - Sonoma State University, 1801 East Cotati Ave., Rohnert Park, CA 94928-3609, USA
10 - Yerkes Observatory, 373 W. Geneva St,Williams Bay, Wisconsin 53191, USA

Received 3 May 2002 / Accepted 9 September 2002

Abstract
The scientific need for a homogenous remote telescope image request system is rapidly escalating as more remote or robotic telescopes are brought to function and scientific programs are created or adapted to use such powerful telescopes. To respond to this need, we have drafted a protocol - "Remote Telescope Markup Language" (Version 2.1) - which has enabled us to implement a non-homogeneous network of imaging telescopes capable of processing requests for the acquisition and retrieval of simple astronomical images. This protocol is designed to be independent of the specific instrumentation and software that control the remote and/or robotic telescopes. It embeds traditional astronomical features such as coordinates and exposure times, and allows for prioritized queue scheduling of telescopes while protecting the telescope operating system. The prioritization supports high-stakes interruption of other observations - "Targets of Opportunity" like optical detection of gamma-ray bursts or other transient events. Some generality in this definition and flexibility is desirable, so that a broad variety of objects and observations can be accommodated within this standard. A number of professional observatories, telescope hardware/software companies, and amateur astronomers are already working with this version of RTML and a large body of additional professional and amateur users willing to share observing time and/or provide observations for scientific or educational use could easily adopt this protocol. The next generation mark-up language (RTML 3) will include elements necessary to schedule more complex observations, enabling its use in practically all ground-based and satellite observatories.

Key words: telescopes


1 Introduction

The last few decades have witnessed a growing shift in the manner in which research telescopes are used. Telescopes of the 4 m-class and smaller were originally conceived and largely continue to be operated in the traditional manner, in which small portions of time are allocated to visiting observers. As the use of space observatories has became more common, many "observers'' have been forced to order their data in service mode: the observations must be proposed and prepared in advance and the telescope's clients often don't know when the observations are made until the data is finally delivered. Given the cost of 8-10 m telescopes, there is tremendous pressure to operate the newest generation of ground-based telescopes also in service mode, e.g. in order to use times of exceptional seeing more efficiently.

Originally, it was thought that the dramatic increase in the number of large telescopes would mean that most small telescopes with apertures less than about 1-2 m would simply have to be shut down. However, two developments have resulted in a renaissance in small-telescope use and science: (1) advances in computer and sensor technology have made it possible to control telescopes over the internet and even to roboticize simple telescope operations using modest means and budgets; and (2) there is a growing awareness that there are many interesting scientific projects which can only be carried out by networking a large number of telescopes. The former effect has resulted in a near explosion in the number of remotely controlled and robotic telescopes[*]. The latter idea has been around for some time, since there are many astrophysical phenomena which cannot be studied on the typical timescales of classical observing runs. Examples range from astroseismology (e.g. the Whole Earth Telescope: Kawaller 2001), large-scale surveys (e.g. COYOTES determination of rotation rates for a large number of young stars: Bouvier et al. 1997), and Target-of-Opportunity (ToO) campaigns for Gamma-Ray Bursts to the long-time monitoring of variable stars and AGN's (e.g. tomography of broad-line regions in Quasars: Peterson et al. ). However, most of the international collaborations which have tried to carry out multi-site/multi-wavelength campaigns have learned how difficult it is to coordinate complex projects using inhomogenous facilities, particularly when they depend upon person-to-person communications.

While most robotic and/or remotely accessible telescopes have been conceived as single instruments for special scientific projects and have modest apertures, it is clear that they have tremendous potential for filling the niche left empty by the classical or service-mode use of larger telescopes. What they lack in aperture they could more than make up in reliable time-coverage if it were possible to coordinate their use with a minimum of effort. This means having an acknowledged standard for the exchange of scheduling and data information which goes far beyond simply being able to exchange email messages and being able to read each other's FITS files.

The power of simple telescope networking becomes even more obvious when it's use is extended beyond purely research projects to public outreach and education. By tapping the resources of schools and advanced amateurs, such networks can not only make true scientific contributions but can also give schoolchildren and the public an intimate feeling for the scientific process by letting them become an active part of an international collaboration.

The unifying theme for the use of networked telescopes is that there is some person or organization who wants a body of observations to be acquired but is located far away from the actual telescope, often cannot or simply does not want to carry out those observations remotely, who doesn't want to have to deal with the vagaries of different telescope operation systems, and often doesn't even care either when and/or where the observations are made. Conversely, the institutions or persons operating a networked telescope have an obvious interest in protecting their hard- and software from anonymous outside users. This means that the client and the telescope network server need a common network interface, both to send requests and to communicate the results of the requests.

In this paper, we present an example of such an exchange language, called RTML ("Remote Telescope Markup Language''). The goal of RTML is to enable communication between user and remote telescopes using a simple but yet powerful interface, based on a widely accepted language (XML) and software tools available for any computer platform. Already several observatories and telescope hardware/software companies have implemented RTML capabilities (e.g. the "Hands-On Universe'' network[*]), but a large body of users could easily implement and benefit from the adoption of RTML in the near future.

2 RTML syntax

RTML is an implementation of XML ("eXtensible Mark-up Language") designed to describe all the information needed to make a simple astronomical imaging observation. XML documents have many advantages over other formats: it is easily passed as a stream of human-readable strings over the Internet; the syntax is simple and yet rigorously defined; it can be used to describe very complex information; it is a widely accepted standard maintained at an international level; and a large number of software parsing tools exist. In simple terms, XML resembles the HTML used in normal Internet documents (with the mark-up keywords enclosed by <'s and >'s), but valid documents must adhere strictly to the XML syntax. The latter is presently defined by a "Document Type Definition'' (DTD) file - unfortunately not written in XML - or some XML-based syntax "schema'' (e.g. Microsoft's XDR Schema or the W3C Consortium's XML Schema). If the syntax description is available over the internet, the syntax of an XML file can be dynamically validated over the internet. Nowadays, XML is being used to describe everything from spreadsheet contents and public library holdings to spacecraft components.

RTML provides a minimum number of elements which are necessary to describe a set of astronomical imaging observations, including things such as a description of the person/institution requesting the observations (<Contact>), a short description of the purpose of the observations (the <Reason> and<Project> tags), scheduling contraints such as sky brightness (<Moon>) and the times of the observations (<TimeRange>), the information about the astronomical sources (e.g. <RightAscension>,<OrbitalElements>), the choice of filters and exposure times, and even the amount of pre-reduction desired (<Correction>).

Because the XML syntax is so human readable, the best way to intrduce RTML is by providing a few examples. Table 1 shows an example of a minimal RTML request. This specifies a single 180 s exposure of NGC 6705 with no filter and no constraints on the time of observation. It includes a DOCTYPE declaration that references the DTD at the HOU web site (see Table 2), permitting validation against the official syntax. A file or web URL to any copy of the DTD will suffice. While DTD validation can be bypassed by omitting the DOCTYPE declaration, it is not recommended, since this feature makes the exchange of requests so robust. Note that all of the information necessary to define a (simple) observation has been hierarchically organized into pieces labelled and bounded by the XML tags (e.g. <Target> ... </Target> for all the information concerning the object to be observed). The information is contained within the tag names, the (often optional) tag attributes (e.g. the version="2.1" attribute of the <RTML> tag), and the contents between the tag head and tail (e.g. <RTML>).

  
Table 1: A simple example of an RTML 2.1 request.
\begin{table}\par {\footnotesize
\par\begin{tex2html_preform}\begin{verbatim}<...
...
</Target>
</Request>
</RTML>\end{verbatim}\end{tex2html_preform}}
\end{table}

A somewhat more complex RTML request is shown in Table 2. This request contains several targets and an explicit request for reduction (dark-correction and flatfielding). The RTML tag contains a name space declaration that references the XDR schema at the ASCOM web site, permitting validation against the XDR schema. A file or web URL to any copy of the XDR schema will suffice. To bypass validation, omit the xmlns attribute (again, not recommended!). This is nowhere nearly as complex as possible, but it does illustrate usage of the repeating elements and the use of optional tag attributes. The total number of images taken by this RTML document is 5 (the first <Request> has <Target count = "2">).

  
Table 2: A more complicated RTML 2.1 request.
\begin{table}\par {\scriptsize
\begin{tex2html_preform}\begin{verbatim}<?xml v...
...=''true''/>
</Request>
</RTML>\end{verbatim}\end{tex2html_preform}}
\end{table}


  \begin{figure}
\par\includegraphics[width=18cm,clip]{RTML-2.1-diagram.ps} \end{figure} Figure 1: Schematic diagram showing the syntax of RTML 2.1. Optional tags have dashed frames. Tags which can occurs multiple times have a "+" label and those which are the heads of a hierarchy are labelled with a "-". The icons containing the labels "- $\cdot \cdot \cdot $-'' indicate that the subhierarchy can occur in any order whereas the "electrical switch'' icon indicates that only one of the daughter tags can be used.
Open with DEXTER

The best sources for information concerning the syntax of RTML are the internet addresses indicated in Tables 1 and 2 since they formally define RTML, but we provide a more visual syntax in the form of an iconic representations in Fig. 1.

3 Relation to other systems and limitations

RTML is not the only or even first astronomical use of XML: NASA's GSFC is using Astronomical Instrument Markup Language (AIML[*]) to document the instrument interfaces in order to provide a common platform for commanding and controlling NASA instruments. XML is being used to describe and exchange astronomical metadata like tables, catalogues, and images (e.g. Ochsenbein 2000) as well as a storage format for things like the GEMINI Phase I proposal software PIT[*]. Each of these examples contains only a subset of the tools necessary to exchange observing requests: AIML could be used to describe a generic camera+filter, the XML constructs used in databases like SIMBAD could describe the targets, and the XML used in PIT could describe the project-aspects but none of them are able to describe all the details of the observations. Unfortunately, a simple union of all these dialects would be a fairly cumbersome means of exchanging information. In addition, the power of AIML is its specificity for explicit and detailed instrument control. The goal of RTML is to isolate the requestor from the instrumentation details. Even though such control as allowed by AIML may be desired by more expert users, RTML elects to leave this explicit control to AIML. RTML intends to be based more on the image throughput, as compared to the explicit control mechanisms that may exist at each observatory. For example, AIML users on the HAWC instrument on the SOFIA airborne infrared observatory use powerful commands like "Nod," or "chop," which far supersedes the amount of control that RTML endeavors to give to the remote observer. One would expect a parser and subsequent scripts written by HAWC team members to take an RTML-based request for a HAWC observation and convert it into the appropriate AIML. Thus, we require an XML dialect tailored to the purpose at hand. By mapping the tags onto the projected users needs in correspondence with the capabilities of the expected hardware, one increases the chances of being sufficiently compatible with other dialects that translations between dialects can be performed.

Many of the limitation of RTML were mentioned in the previous section and are mainly due to the potential complexity of inhomogenous networks. The trade-offs obvious when designing a new syntax are many: do we need a dialect which is so general that all potential observatory facilities can be used/described or should the syntax be kept very simple so that observatories are more likely to want and to be able to implement it locally; should the syntax remain static and hence well-defined or should it contain dynamic elements (the present syntax is mainly intended to communicate the client's wishes to the server - should the server be able to respond and query the client)? In the 2.1 syntax, the structures were consciously kept as static and simple as possible. As more experience is gained in the use of RTML 2.1, we will be able to guide RTML towards an even more robust and useful universal standard.

  
Table 3: This is an excerpt from the full schema of RTML. The full schema is on-line at: http://hou.lbl.gov/RTML2.1.
\begin{table}\par\scriptsize
\begin{tex2html_preform}\begin{verbatim}<xs:eleme...
...
</xs:cmoplexType>
</xs:element>\end{verbatim}\end{tex2html_preform}\end{table}

4 RTML 3.0

While the syntax of RTML 2.1 is fully adequate to connect telescopes to clients requesting simple images, it is clear that we will soon need a more complex description of observation requests. For example:

As the networks become more powerful (e.g. networks of networks) and are used by a wider "customer base", the networks and the users will need a means of "charging" or at least keeping track of the observing time used by various individual users and community of users. Many of these ideas will soon be implemented in RTML 3.0 as soon as enough experience has been gained in the use of RTML 2.1 and the syntax necessary for more complicated requests has been defined. Several very different projects in development are planning on basing their whole operations on RTML 3+ (e.g. the telescope network MONET[*] and perharps the 11 m Southern African Large Astronomical Telescope (SALT[*]).

5 Conclusions

In this paper we have described the first steps towards a universal protocol for sending astronomical requests of many types to any participating telescope. Thanks to the use of XML, RTML has the flexibility to evolve to a communication language with both autonomous and manual observatories, and to encompass all kind of observations. RTML is already being used to request observations from automated instruments, as well as to get images from database systems. The writing of interfaces is simple enough, so they can be embedded in many kind of user interfaces (GUI) for any platform. An RTML request can also be written directly by a program, e.g. an alert system like the GRB Coordinate Network (Barthelmy et al. 1997). We are now aggressively testing the actual use of RTML 2.1, experience which will promote the development of the next-generation RTML 3.0 with even more potential for use in a wide range of projects.

Acknowledgements
Part of Pennypacker's work was supported by the United States National Science Foundation, under Grant ESIE9554161. In addition, Dr. Nicolas Regnault made significant contributions at various phases of this project.

References

 
Copyright ESO 2002