Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.adass.org/adass/proceedings/adass97/lindep.html
Дата изменения: Fri May 15 22:17:28 1998
Дата индексирования: Tue Oct 2 01:31:17 2012
Кодировка:
Поисковые слова: р п р п р п р п р п р п р п р п р п р п р п п р п п р п п р п п р п п р п п р п п р п п р п п р п п р п п р п п р п п р п п р п п р п п р п п р п п р п п р п п р п п р п п р п п р п п р п п р п п р п п р п

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:

• The scientist generates the observing proposal. Upon approval of the proposal, a detailed observing plan is prepared, using the instrument simulation facility to allow optimal usage of the instrument. The plan is then submitted to the scheduling subsystem to prepare the actual time allocation plan.
• Several time allocation plans are generated using a scheduling subsystem, defining a primary session and several alternate sessions. The actual operational session is designed in a flexible form, allowing for observing conditions and priority requirements.
• When a session is allocated for operations, the end user node is contacted, and the client capabilities are validated to define the supported services and hand-over takes place.
• After hand-over, the actual operational session takes place, controlled by the instrument server, with minimal input from end user clients.
• During the session, several clients can work with a given instrument server. One of the clients is the primary, operational node, the others acting as passive, mirror nodes. A given client can work with several different instrument servers, allowing simultaneous observations.
• Instrument servers include an on-line archive facility, to keep record of the real-time activity and to store the observed data.
• Observed data and related archive data are transferred from the server to the clients upon request, for quick-look, calibration and analysis.

3. Services Provided

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

• Monitoring activities, to follow basic operations performed at the telescope. No control operation is performed at this level, therefore no real-time activity is really required and no guaranteed bandwidth is required.
• Remote control activities, controlling the activities of telescope and instruments, including performing real-time operations. A minimal guaranteed bandwidth for the support of real-time is an absolute requirement.
• Remote observing activities, including monitoring and some of the control activities, such as the setup of basic modes and functions of telescope and instruments, download of compressed (lossy) data for quick-look purposes, etc. Guaranteed bandwidth for the support of real-time is required together with intermediate transfer rates.
• Data transfer activities,for the transfer of scientific data files (lossless compressed). Guaranteed bandwidth is not a requirement but high transfer rates are desirable.

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.

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 IP protocol will be implemented on top of ISDN, so to allow testing the control system concept on ISDN-based connections.
• An appropriate software interface will be built between the control system and the REMOT-provided communications architecture. Direct use of the communications infrastructure and the bridging mechanism guaranteeing QoS will be provided.
• The use of ATM services may be considered in a possible extension of the project.

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