Next: The Distributed Analysis System Hierarchy (DASH) for the SUBARU Telescope
Up: Dataflow and Scheduling
Previous: System Interfaces to the STIS Calibration Pipeline
Table of Contents -- Index -- PS reprint -- PDF reprint


Astronomical Data Analysis Software and Systems VII
ASP Conference Series, Vol. 145, 1998
Editors: R. Albrecht, R. N. Hook and H. A. Bushouse

REMOT: A Design for Multiple Site Remote Observing

P. Linde
Lund Observatory, Box 43, SE-221 00 Lund, Sweden, Email: peter@astro.lu.se

F. Pasian and M. Pucillo
Osservatorio Astronomico, Via G.B.Tiepolo 11, I 34131 Trieste, Italy , Email: {pasian,pucillo}@ts.astro.it

J. D. Ponz
ESA Villafranca P. O. Box 50727, 28080 Madrid, Spain, Email:jdp@vilspa.esa.es

 

Abstract:

The REMOT project objective is to develop and validate a generic approach to allow remote control of scientific experiments and facilities that require real time operation and multimedia information feedback. The project is funded through the European Union Telematics initiative and is a collaboration, involving representatives from both the astro- and plasma physics communities. Standard communications infrastructure and software solutions will be used wherever possible. In the first step, requirements have been collected and analysed, resulting in a set of service definitions. These have been partly implemented to perform a set of demonstrations, showing the feasibility of the design.

       

1. Introduction

As a response to the increasing need for remote control of large scientific installations, the REMOT (Remote Experiment MOnitoring and conTrol) project was initiated in 1995. The final goal of the project is to develop and validate a generic approach to allow real time operation and multimedia information feedback, using communications infrastructure available to European researchers.

Funded through the European Union Telematics Organisation, the project involves representatives from the astro- and plasma physics communities and from several teleoperation and software design institutes and companies. The partners from the astrophysical community include OAT (Italy), IAC (Spain), LAEFF (Spain), Nordic Optical Telescope and CDS (France).

2. Requirements and Operational Scenario

The design of the generic system and communications architecture started by creating a large database of user requirements, collected from each participating partner. The requirements were derived from the following operational scenario:

3. Services Provided

The services that REMOT will provide can be roughly divided into four categories:

4. Implementation of Services

Analysis of the collected database of requirements resulted in a set of service definitions. These services will be implemented by using two different conceptual planes (see Figure 1). These are (1) the System Plane, supporting Quality of Service (QoS), (2) the Management Plane, supporting reliable communications. Operational services will be performed in the System Plane and managed over the Management Plane, while auxiliary services will be supported over the Management Plane.


 
Figure 1: The architecture of the REMOT system. The observer's application is interfaced to a CORBA client and, through the Object Request Broker (ORB) mechanism, communicates with the Telescope and Instruments application. A Communications Manager arbitrates if the communication is to take place through the standard IP-based channel (IIOP), through a bridge supporting Quality of Service (QoS), or using directly the transport services.
\begin{figure}
\plotone{lindep1.eps}\end{figure}

For the communications architecture we use a CORBA compliant mechanism: the Management Plane is implemented by using CORBA and its IP-based layer (IIOP) directly. When QoS is required (System Plane), a bridging mechanism bypassing IIOP can be used, or alternatively there is the possibility of using the transport services directly. The presence of a Communications Manager to arbitrate communication resources is necessary in both cases.

5. An Example: The Galileo telescope (TNG)

Galileo's high-level control system is based on a distributed computer architecture in which both the code and the data are shared by all the workstations supporting the systems (Pucillo 1994). Remote control is implicitly embedded in the design, since the control workstation can either be located or be connected via a bridge or a router.

REMOT improves this remote access philosophy since, besides using a common user interface for different telescopes, it does not require TNG-specific hardware, but will allow remote observations to be run ``at the astronomer's own desk", on a simple PC.

Integrating the control system of the Galileo telescope in the REMOT project is simple:

The software interface between the control system and REMOT consists of an ancillary process running under the same environment. This process is also responsible for retrieving from the TNG on-line database the updated status of the system, and for downloading observational data in original (FITS) or compressed (quick-look) format to the remote user.

6. Project Status and Future Activities

A prototype of the complete system is under development, including the basic services. Since REMOT is limited in scope, only a subset of the design will be currently implemented. This will, however, allow a practical demonstration to be performed using the new Galileo telescope located at La Palma and the IAC 80 cm telescope located on Tenerife.

REMOT will be extended in a continuation project DYNACORE, where a complete implementation is targeted. The design will then be upgraded to include real time access to data bases, flexible scheduling and dynamic reconfiguration. Additional information on the project can be found at
http://www.laeff.esa.es/~tcpsi/.

References:

Pucillo, M. 1994, Handling and Archiving Data from Ground-Based Telescopes, M.Albrecht & F.Pasian eds., ESO Conferences and Workshop Proceedings, Vol. no. 50, 77


© Copyright 1998 Astronomical Society of the Pacific, 390 Ashton Avenue, San Francisco, California 94112, USA


Next: The Distributed Analysis System Hierarchy (DASH) for the SUBARU Telescope
Up: Dataflow and Scheduling
Previous: System Interfaces to the STIS Calibration Pipeline
Table of Contents -- Index -- PS reprint -- PDF reprint

payne@stsci.edu