telescope-net.com

The SAROS system


	The SAROS system incorporates not only the functionality of the website itself, but also the "behind the scenes" functionality involving telescopes, observations and requests.

	SAROS is the "Scheduled, Autonomous, Remote Observation System." The current production version is 2.1. The system encompasses components to accept and inject observation requests, to rapidly lookup coordinates of astronomical objects, including planets, comets and asteroids, to aquire and dispatch image data in an appropriate and timely manner, and to store and manage observation requests through their lifecycle. Requests can be accepted and data returned via a number or routes, including the website itself, email, and web services.

	The system incorporates a sophisticated scheduling engine, which can schedule requests promptly, reallocate requests from one telescope to another, reschedule failed requests, and can maintain relationships between an arbitrary number of requests.

	The SAROS system understands "virtual telescope networks". In this model, the full network of telescopes is divided in to a number of logically separate networks. For example, networks can be created for instruments with wide-angle or narrow-angle fields of view, or for instruments with high-end equipment or large apertures, or for use by particular schools or universities or the general public. Access to these logical networks can be restricted based upon, for example, the characteristics of the user. In this way, an individual, a small astronomy club, a school or a university can each choose to make their telescopes available to their friends, members or students alone, or they could choose to make these instruments available to potentially service requests from anyone.

	Observation requests are typically submitted to a particular network, and may be serviced by any telescope within that network. This is is some ways an astronomical analogue of the "cloud computing" idea, in that the astronomical imaging may be provided as a service by any telescope appropriately configured over the internet ("in the cloud"), without the requestor requiring any specific control over, or knowledge of, the telescopes or associated infrastructure. Perhaps this should then be called "cloud astronomy" or "cloud observing".

	The system incorporates extensive monitoring and logging of hardware, software and network performance metrics, along with detailed information on weather and the states of systems at the remote sites. SAROS also allows for the scheduled switching and control of remote hardware, as is done for the O'Mara telescope which is a completely robotic installation.

	Because observations can be requested by a variety of users, with varying requirements and levels of knowledge and skill, a flexible request submission system has been implemented. Requests can be created by a number of mechanisms, including web-based forms of varying complexity, RTML, or according to an automated regimen. Currently, only RTML version 2.1 is supported, although it is intended that RTML 3 will be supported as this matures. Requests can also be injected directly from external systems, via web services. This latter path may prove useful in integrating with external RTML servers or with other software systems. The request injection methodology is extensible, such that it is straightforward to create new methods by which imaging requests can be injected in to the system (e.g., email, SMS).

	Requests may specify the coordinates of an astronomical object, or may simply specify a catalogue or common name. In the latter cases, the target's coordinates are looked up in a "directory" of astronomical objects. The orbital elements of solar system objects (e.g., comets, asteroids and planets) are automatically updated on a regular basis.

	Requests also contain information on their priority. The validity period for a request is typically of the order of a week. The priority of a request, as supplied to the scheduler at any given time, will often increase monotonically over this period. This time-dependence of priority is typically used to ensure that requests with less "time to live" are treated by the scheduler as higher priority. The absolute priority of a request (i.e., how "important" this request is, relative to other requests, independent of time), is determined by a number of factors. It can be influenced by request preferences, by by the (logical) telescope network to which the requst is submitted, by who submitted the request, and by the method by which the request was submitted.

	Once injected, imaging requests and all associated data reside in a central store, where they are made available to the scheduling engine. The schedules subsequently constructed for each telescope by this engine are prosecuted by UNIX-style daemons which assume the role of the observer. The observed images are subsequently retrieved and pass through an analysis pipeline. If the imaging attempt was unsuccessful, the request will be flagged and rescheduled for a subsequent observation attempt. If the request was successful, the image and associated information are appropriately stored and dispatched to the request owner.

	The SAROS system contains support for "request sharing", which can be of significant benefit in a system of this type. This model breaks the one-to-one and onto relationship which typically exists between an image request and the actual telescope observation. For example, a newly-arriving request which is identical to one already in a telescope's queue need not require a separate observation to fulfil. Instead, if appropriate, this new request may be associated with the already-queued observation request. In such a case, a successful observation would then satisfy two, independent requests. In this way, increased numbers of individual requests may be handled by a relatively modest number of telescopes.

	The system will soon be made available for the general public, such that they can add their telescopes to the network and submit requests.