Äîêóìåíò âçÿò èç êýøà ïîèñêîâîé ìàøèíû. Àäðåñ îðèãèíàëüíîãî äîêóìåíòà : http://www.stecf.org/conferences/adass/adassVII/reprints/lindep.ps.gz Äàòà èçìåíåíèÿ: Mon Jun 12 18:51:47 2006 Äàòà èíäåêñèðîâàíèÿ: Tue Oct 2 03:07:46 2012 Êîäèðîâêà: Ïîèñêîâûå ñëîâà: arp 220

Astronomical Data Analysis Software and Systems VII
ASP Conference Series, Vol. 145, 1998
R. Albrecht, R. N. Hook and H. A. Bushouse, e
Ö Copyright 1998 Astronomical Society of the Pacific. All rights reserved.
ds.
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 in­
stallations, 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 feed­
back, 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).
328

REMOT: A Design for Multiple Site Remote Observing 329
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 pro­
posal, a detailed observing plan is prepared, using the instrument simu­
lation facility to allow optimal usage of the instrument. The plan is then
submitted to the scheduling subsystem to prepare the actual time alloca­
tion plan.
. Several time allocation plans are generated using a scheduling subsystem,
defining a primary session and several alternate sessions. The actual op­
erational session is designed in a flexible form, allowing for observing con­
ditions 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 di#erent in­
strument 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 cate­
gories:
. Monitoring activities, to follow basic operations performed at the tele­
scope. 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 instru­
ments, 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 con­
trol activities, such as the setup of basic modes and functions of telescope
and instruments, download of compressed (lossy) data for quick­look pur­
poses, etc. Guaranteed bandwidth for the support of real­time is required
together with intermediate transfer rates.

330 Linde, Pasian, Pucillo and Ponz
Services
Client Server
ORB ORB
BRIDGE
IIOP
Communications
Manager
Application Application
Observer's T & I
Interface Interface
Transport
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.
. Data transfer activities,for the transfer of scientific data files (lossless com­
pressed). 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 di#erent concep­
tual planes (see Figure 1). These are (1) the System Plane, supporting Quality
of Service (QoS), (2) the Management Plane, supporting reliable communica­
tions. 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.
For the communications architecture we use a CORBA compliant mecha­
nism: the Management Plane is implemented by using CORBA and its IP­based
layer (IIOP) directly. When QoS is required (System Plane), a bridging mecha­
nism 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 architec­
ture in which both the code and the data are shared by all the workstations
supporting the systems (Pucillo 1994). Remote control is implicitly embedded

REMOT: A Design for Multiple Site Remote Observing 331
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 com­
mon user interface for di#erent 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 in­
clude real time access to data bases, flexible scheduling and dynamic reconfigura­
tion. 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 Proceed­
ings, Vol. no. 50, 77