Rolando Potts - UGRdtstc.ugr.es/~jedv/descargas/2004_astrorobot-fullscan.pdf · del sistema....

Diseño cubierta y maquetación: L. Rolando Potts

Reservados todos los derechos. No se permite reproducir, almacenar en sistemas de recuperación de la información ni transmitir alguna parte de esta publicación, cualquiera que sea el medio empleado -electrónico, mecánico, fotocopia, grabación, etc.-, sin el permiso previo de los titulares de los derechos de la propiedad intelectual.

© 2005 Alberto J. Castro-Tirado / Benito A. de la Morena Carretero / José Torres Riera

© 2005 EQUIPO SIRIUS

ISBN-lO: 84-95495-64-3

ISBN-13: 978-84-95495-64-8

Depósito legal: M-43259-2005

Imprime: PUBLICEP Libros Digitales

Impreso en España I Printed in Spain

Equipo Sirius. S .:\ .

Avda. RafEel Fina~ 3-!. _ .• ~~2drid

Correo-e: 5L-: ,,'ª _ ;po.-T. ' . om

,,·W\y.eq ":':?Qs..-::.-::..;::o:::;

AS ROe ES

A BENITC

8/ Alberto Javier Castro Tirado / Benito A . de la Morena Carretero / José Torres Riera

CAPÍTULO 3 INSTRUMENTACIÓN Y DESARROLLOS FUTUROS ................... 161

MONITOR DE SEEING AUTOMÁTICO (DlMMA) ........................................... 163

SISTEMA DE CÁMARAS DE GRAN CAMPO PARA LA

DETECCIÓN Y ESTUDIO DE FENÓMENOS ÓPTICOS

TRANSITORIOS DE ORIGEN CÓSMICO, BÓLIDOS Y METEOROS ........... 177

BOOTES-IR: UNA ESTACIÓN ASTRONÓMICA ROBÓTICA

EN EL IR CERCANO PARA EL OBSERVATORIO

DE SIERRA NEVADA ............................................................................................... 189

EL SOFTWARE DE CONTROL DEL TELESCOPIO IR

DE 60 CM DE SIERRA NEVADA ........................................................................... 201

IRAIT, OBSERVATORIO ROBÓTICO EN

LAANTÁRTIDA. ....................................................................................................... 213

APÉNDICE ............................................................................................................ 229

TELESCOPIOS «ROBÓTICOS» DEL OBSERVATORIO

ASTRONÓMICO DE MALLORCA (OAM) .......................................................... 231

TELESCOPIOS ÓPTICOS ROBÓTICOS. SU USO

EN LA DOCENCIA Y LA DIVULGACIÓN ........................................................... 255

ÍNDICE DE MATERIAS .................................................................................. 269

ÍNDICE DE AUTORES .................................................................................... 273

I

I ;

Desde la o ... a finales de la d . La Palma en 199-servatorio robó ' ( Atmosféricos E ) rospacia1) en ~lan a robotizarse en E: años. Una do e~ tres en Canarias. 1

de Madrid, uno e:J

y otro en Balear ' Es por ello 1

de Astrofísica Ro' carácter cientifi () bién a tecnólogos realizados ha diferentes pro~ timicen los re expusieran lo . e Creemos que -:'

La Reunió del Espacio y T ce del Instituto ~ ci Astrofísica de .b (IAA-CSIC) o trónica, Siste a: Queremos a_ l M. Andújar. J Co10mé, J. Díaz

El software de control del telercopio IR de 60 cm de Siena Nevada / 201

EL SOFTWARE DE CONTROL DEL TELESCOPIO IR DE 60 CM DE SIERRA NEVADA

J E. Díaz Verdejo, P. García Teodoro, J M López Soler y J R. Martínez Pérez (Area de Ing. Telemática, Dpto. Electrónica y Tecnología de Computadores, Univ. de Granada)

202/ ASTROFÍSICA ROBÓTICA EN ESPAÑA. Instrumentación y desarrollos futuros

1. E. Díaz Verdejo

Resumen

En e té

para su adop del sistema ( de módulos. forma autónl Los diferent mediante un la ventaja de interacción e interfaz corn

1. Introduce

El pro: Exploring ~ primera fa e (GRB) en el bótico, a imI extensión na desde 199 .

En el 1 sistema que [ asociadas al telescopio, c. del carácter

El di ( servatorio. a de informac

El software de control del telercopio IR de 60 cm de Sierra Nevada / 203

Resumen

En esta contribución se describe la arquitectura modular diseñada para su adopción en el observatorio automatizado BOOTES-IR. El diseño del sistema se ha realizado considerando un conjunto heterogéneo y diverso de módulos, cada uno de los cuales desempeña una serie de funciones de forma autónoma, aunque coordinadas por el módulo de control central. Los diferentes módulos intercambian mensajes con el módulo de control mediante un protocolo diseñado al efecto. El sistema resultante presenta la ventaja de ser fácilmente escalable y de permitir varios mecanismos de interacción con los investigadores sin más que disponer de los módulos de interfaz correspondientes.

1. Introducción

El proyecto BOOTES-IR (Burst Observer and Optical Transient Exploring System-InfraRed) [1] tiene como objetivo científico seguir la primera fase de emisión pos luminiscente de los brotes de rayos gamma (GRB) en el IR cercano. A este fin, se propone construir un telescopio robótico, a implantar próximamente en Sierra Nevada, y que constituye una extensión natural del proyecto BOOTES [2], que opera en el sur de España desde 1998.

En el presente artículo se describe el diseño e implementación de un sistema que permita controlar y monitorizar la instrumentación e información asociadas al observatorio BOOTES-IR, tanto desde la propia ubicación del telescopio, como desde otras ubicaciones remotas, dotándolo adicionalmente del carácter robótico previamente mencionado.

El diseño del sistema de control requiere un análisis previo del observatorio, a fm de identificar los elementos que lo componen y los flujos de información entre ellos. En primera aproximación, podemos identificar


6 elementos o bloques diferenciados: el telescopio, la cámara, la cúpula, la «sala de control», el sistema de análisis de imágenes y un módulo encargado de gestionar las alertas GRB recibidas. Cada uno de estos módulos presentará una funcionalidad y software propios. Por otra parte, dado que BOOTES-IR es una continuación de proyectos previos, existen componentes que se encuentran ya implementados y en funcionamiento, por lo que sería aconsejable reutilizar los elementos disponibles sin más que realizar las adaptaciones mínimas imprescindibles. Ambos factores aconsejan abordar un diseño modular del sistema.

-.YV~h SMS . . ~ ~EB¡e%

Interfaces de usuario

-- Interacción mediante BTP (BOOTES Transport Protocol)

Figura 1: Arquitectura del sistema y ubicación de los agentes BTP.

Por otra parte, la capacidad de control desde la propia ubicación del telescopio o desde ubicaciones remotas aconseja la utilización de una red de comunicaciones. En concreto, sería conveniente disponer de una infraestructura de red, con los servidores necesarios y de acuerdo a los requisitos de seguridad y fiabilidad adecuados, que permita la interconexión entre los diferentes módulos del sistema y su accesibilidad desde Internet.

Consecuentemente, será necesario implementar un módulo controlador de emisión/recepción de información/órdenes que interaccione con los diferentes instrumentos automatizados existentes.

Finalmente, el control del observatorio debe poder realizarse tanto de forma automática, a partir de unos conjuntos de instrucciones/observaciones programadas, como de forma manual, mediante las interfaces desarrolladas al efecto, desde cualquier ubicación remota con acceso a la red (Internet).

El pre describirá la las especifici en la gestión módulos que la operación mediante el del sistema. tinado a po de la que se observatorio

2. Arquitecn

La arql se muestra er mentados de . diferentes, e

• BS~1 de co todas módu por le Con 1

del 01 ·MC~'

ción ( una u

SMS. entre módl proce

·DCM de ap tema (ilum cualq

El software de control deltelercopio IR de 60 cm de Sierra Nevada / 205

El presente artículo se estructura como sigue. En el apartado 2 se describirá la arquitectura del sistema de control propuesta para cumplir las especificaciones previamente mencionadas. El apartado 3 se centra en la gestión de las comunicaciones a través de la red entre los diferentes módulos que componen el sistema, mientras que el apartado 4 describe la operación del módulo encargado de ejecutar las tareas de observación mediante el envío de las órdenes oportunas a los diferentes módulos del sistema. Finalmente, en el apartado 5 se describirá el módulo destinado a posibilitar las diferentes interfaces con los usuarios, a través de la que se podrán controlar y monitorizar las tareas y elementos del observatorio.

2. Arquitectura del sistema

La arquitectura propuesta para el sistema de control del observatorio se muestra en la Fig. 1. Los elementos que la constituyen, que serán implementados de forma independiente y que pueden estar ubicados en máquinas diferentes, son:

• BSM (BGGTES-IR Server Monitor). Servidor central y monitor de comunicaciones. Tiene como misión servir de intermediario en todas las comunicaciones, vía red de área local, entre los diferentes módulos, interpretar las órdenes y respuestas generadas o emitidas por los diferentes módulos y coordinar la actuación de todos ellos. Constituye el núcleo del sistema, por ser el que centraliza la gestión del observatorio.

• MCM (Modules Control Monitor). Módulo que posibilita la interacción del usuario con el módulo BSM, permitiendo de forma flexible una interacción variable por parte de los usuarios: GPRS, WEB, SMS, etc. El módulo MCM actuará, en consecuencia, como pasarela entre las diferentes interfaces de usuario que se implementen y el módulo BSM, a través del que se tendrá acceso a todos los datos y procedimientos disponibles en el observatorio.

• DCM (Dome Control Monitor). Es el módulo que controla el sistema de apertura automatizada del observatorio. Estará dotado de un sistema de gestión que supervise las diversas variables meteorológicas (iluminación, lluvia, nieve, temperatura, humedad, viento ... ) o de cualquier otro tipo relacionadas con la apertura de la cúpula.


• TCM (Telescope Control Monitor). Módulo que controla los movimientos en ascensión recta (A.R.) y declinación (DEC) del telescopio.

• IRTM (IR Transient Monitor). Módulo destinado a la adquisición de imágenes, debiendo gestionar, obviamente, la cámara existente en el telescopio.

• IAM (Image Analisys Monitor). Módulo destinado al análisis en tiempo real de las imágenes enviadas por el módulo IRTM.

• TSM (TeleSurveillance Monitor). Módulo de televigilancia que controla una o más cámaras de vídeo (webcams) a través de las que se realiza un seguimiento visual remoto del observatorio.

• TPM (Task Planner Monitor). Módulo encargado de gestionar, priorizar y notificar los datos relativos a las observaciones astronómicas a realizar.

• GAM (GRB Alert Monitor). Módulo dedicado a la recepción y notificación de alertas GRB desde fuentes externas l •

• BD Tareas. Base de datos que contiene la relación de observaciones planificadas por el módulo TPM.

• BD Imágenes. Base de datos que contiene, debidamente organizadas, las imágenes adquiridas por el módulo IRTM.

Los módulos intercambian información con el módulo BSM utilizando como medio de transporte un protocolo específico diseñado al efecto, que será descrito en el apartado siguiente. Obviamente, para la correcta operación del sistema será necesario que el acceso a las funcionalidades de cada módulo se realice a través de una interfaz claramente definida.

La elección de esta arquitectura se basa en las especificaciones indicadas en la introducción, a la vez que en la consecución de un conjunto de importantes ventajas:

• Modularidad: La disposición del sistema en módulos independientes introduce importantes ventajas respecto de la reutilización de componentes y facilidad de implementación de las funcionalidades propias de cada módulo.

• Escalabilidad: La adición / supresión de nuevos módulos o elementos resulta sencilla, ya que únicamente es necesario implementar el módulo y especificar su interfaz correspondiente, sin que ello afecte a las funcionalidades de los restantes módulos.

l. En una modificación posterior de la arquitectura, este módulo ha sido integrado dentro del módulo TSM.

Figm

· Múl · MC~

estab BS:'1

• Cono y, pOI

usanc acclO

• Fácil bilita Slll m

3. Comuruc:

En la, módulos coh local median master/slave como servid, o ser destina comUnICaCIO los conocidc tervengan en la Fig. 1).

El inte preestablecic bras, se ha e Transport P¡

agentes de CI


Figura 2: Intercambio de información entre los diferentes elementos.

• Múltiples métodos de control manual. La funcionalidad del módulo MCM permite la utilización de diversas interfaces de usuario, al establecer un mecanismo común de comunicación con el módulo BSM.

• Control global centralizado. La operación de los diversos módulos y, por ende, del observatorio, se realiza desde el módulo BSM que, usando la información disponible, coordina, ordena y secuencia las acciones a realizar por los diferentes módulos.

• Fácil modificación de la operativa. El diseño del módulo BSM posibilita la fácil modificación de secuencias de operaciones o acciones sin más que modificar un archivo de configuración.

3. Comunicaciones

En la arquitectura anterior, las comunicaciones entre los diferentes módulos cobran una especial relevancia. Éstas se realizan a través de una red local mediante la aplicación del paradigma cliente-servidor en su variante mas ter/s lave [3], ya que cualquier módulo puede actuar como cliente o como servidor, es decir, cualquier módulo puede iniciar una comunicación o ser destinatario de la misma. De esta forma, se ha diseñado un agente de comunicaciones, capaz de actuar como cliente y como servidor, basado en los conocidos sockets [4]. Obviamente, cada uno de los módulos que intervengan en el sistema debe integrar un agente de comunicaciones (véase la Fig. 1).

El intercambio de mensajes se realiza mediante un formato común preestablecido, de acuerdo a una secuencia predeterminada. En otras palabras, se ha establecido un protocolo específico, denominado BTP (BOGTES Transport Protocol), que permite la transferencia de información entre los agentes de comunicaciones que, consecuentemente, serán agentes BTP.


El sistema ha sido concebido para que todas las comunicaciones tengan como origen o destino el módulo BSM, es decir, cualquier intercambio de información entre dos módulos requiere de la mediación e intervención del módulo BSM. Se ha adoptado este criterio para permitir centralizar la gestión del observatorio (en el módulo BSM) y para que se pueda realizar una monitorización efectiva, ya que el módulo BSM dispondrá de información relativa a todos los eventos que estén teniendo lugar en el observatorio.

(órdenes)

Alertas GRB t -TPM

Figura 3: Interacción entre TP M, GAM Y BSM para la ejecución de tareas de

observación.

Otro aspecto relevante de las comunicaciones está asociado al intercambio de datos interno a los módulos. Como se ha mencionado previamente, cada módulo debe integrar un agente BTP, que es el que se encarga de las comunicaciones. Obviamente, este agente debe intercambiar información con el programa o programas encargado/s de implementar las funcionalidades propias del módulo. Para ello se ha establecido una arquitectura interna para los módulos (véase la Fig. 2), en la que se establece y normaliza el intercambio de datos entre el agente BTP y el denominado programa principal del módulo a través de una zona de memoria compartida o "pizarra".

La arquitectura adoptada para las comunicaciones presenta la importante ventaja de separar los aspectos relativos a la gestión de la comunicación de los propios del módulo, simplificando el desarrollo del software necesario. Por otra parte, esta comunicación será independiente de los sistemas operativos sobre los que operen los diferentes módulos, ya que la comunicación está estandarizada a través del protocolo BTP y del uso de los agentes.

Para posibilit necesario di . diferentes se

4. Ejecución

El func concepto de cualquier con Por ejemplo. de operacion\ servación. C< tareas de me< obtención de pueden enc01 secuencia de

In

Apertura lo ,

~ 51

Posícionam

/~ ~, 51

Grabació n

51

Análisi s I

s:

El software de control del telercopio IR de 60 cm de Sie"a Nevada / 209

Para posibilitar su uso en diferentes platafonnas software únicamente es necesario disponer de tantas versiones del agente BTP como platafonnas diferentes se vayan a utilizar.

4. Ejecución de tareas

El funcionamiento coordinado del observatorio se fundamenta en el concepto de ejecución de tareas. Una tarea corresponderá, en general, a cualquier conjunto completo de operaciones encaminadas a un fin concreto. Por ejemplo, una tarea de observación estará compuesta por el conjunto de operaciones que es necesario completar para conseguir realizar una observación. Con esta misma aproximación, se pueden definir, por ejemplo, tareas de medición de temperatura, de posicionamiento del telescopio, de obtención del estado global del observatorio, etc. Obviamente, las tareas pueden encontrarse anidadas, es decir, una tarea puede componerse de una secuencia de tareas.

Ape¡rt \.!r!'/cierre cúpula

/t~ <OK?/ >-_N_O _----,

SI 17

Posicionamiento telescopio %e

¡ <"ó~ NO

s;y Grabación imágenes

f ~' NO ~K?~>------I SI Y

Análisis imágenes ¡

~'?, NO

SI

Admill

Investigador

Colaborador

Visitante

Figura 4: Ejemplo simplifi

cado de autómata de control del observatorio.

Figura 5: Jerarquía de seguridad del sistema:

tipos de usuarios.


El módulo BSM es el responsable de la ejecución de las tareas. Para ello dispone de una serie de elementos (Fig. 3) que le proporcionan información relativa al estado del observatorio, los procedimientos disponibles en cada módulo y, fundamentalmente, un conjunto de autómatas de estados finitos (FSA, Finite StateAutomaton) [5]. Cada FSApermite especificar un conjunto de instrucciones que debe emitir el módulo BSM y la actuación del mismo frente a todas las posibles respuestas recibidas de los restantes módulos. Con fines ilustrativos, en la Fig. 4 se muestra un ejemplo reducido de autómata correspondiente a la tarea de observación. Evidentemente, existirá un FSA para cada una de las posibles tareas, que serán iniciadas a petición de cualquiera de los módulos autorizados (p. ej., la ejecución de una observación se iniciará a petición del módulo TPM, la medición de la temperatura se podría iniciar a petición de MCM, es decir, a petición de un usuario, etc.) .

La utilización de FSA para especificar el comportamiento del observatorio proporciona una gran versatilidad, tanto en lo que respecta a cualquier modificación de la operativa del mismo, como a la incorporación de nuevos módulos o elementos. Para ello únicamente será necesario modificar o añadir el archivo donde se especifique el FSA correspondiente.

5. Módulo MCM

El módulo MCM constituye una interfaz común para todos los servicios de acceso, facilitando el desarrollo de diferentes interfaces de usuario para el controlo monitorización del observatorio. Su funcionalidad básica es:

• Realizar el control de acceso, es decir, verificar si el usuario que está accediendo al sistema está autorizado o no así como su nivel de acceso.

Figura 6: Estructura general de la interfaz mediante WWW

• Comr de la i ma. J

• Reem corre~

El con ridad del si información de interfacese hace neces terminar de ", al sistema. pr 5) en los qm corresponde través del m niveles (cola de usuario «

rango en el ~

su correspon privilegios el

A CCe5(l

Inte--n

Router I cortaft. e de acceso

Figura : J


• Comprobar las órdenes o consultas emitidas por el usuario a través de la interfaz, realizando la conversión al formato interno del sistema, si fuese preciso.

• Reenviar las órdenes recibidas hacia BSM, obteniendo las respuestas correspondientes, que son presentadas al usuario.

El control de acceso es necesario ya que debe garantizarse la seguridad del sistema, tanto desde el punto de vista de la operativa como de la información almacenada. Dado que el acceso al mismo se realiza a través de interfaces accesibles públicamente desde el exterior (p. ej. páginas web), se hace necesario establecer mecanismos de autenticación que permitan determinar de forma fehaciente la identidad del usuario que pretende acceder al sistema. Para ello se han establecido 4 niveles de seguridad (véase la Fig. 5) en los que se clasifica a cualquier usuario. El nivel inferior, visitante, corresponde a un usuario genérico no autenticado, pudiendo accederse a través del mismo a información general del laboratorio. Los siguientes niveles (colaborador, investigador y administrador) corresponden a tipos de usuarios que pueden realizar, progresivamente, actividades de mayor rango en el sistema. Cada usuario dispone de una cuenta individual, con su correspondiente pareja nombre-contraseña, clasificada de acuerdo a sus privilegios en una de las tres categorías indicadas.

Router I cortafuegos de acceso

Zona pública (DMZ)

Otros

Módulos

~ Zona privada (mediante filtrado)

!

)

Figura 7: Arquitectura de la red de ordenadores a implantar para la gestión del observatorio.


Como se ha comentado previamente, la utilización del módulo MCM permite el establecimiento de diversas interfaces de usuario. La de propósito más general contemplada es la que se basa en el uso de un sitio web para suministrar la información que se desee, así como realizar el control y monitorización del observatorio. A este fin, se establecerá un servidor web, accesible desde Internet, en el observatorio, con la información estructurada en bloques como se muestra en la Fig. 6. El acceso a los diferentes bloques es función del nivel de seguridad del usuario.

Finalmente, la implantación del sistema requerirá de una infraestructura de red que permita interconectar los diferentes módulos/ordenadores que lo componen. A este fin se establece una estructura de la red en dos zonas (véase la Fig. 7): una zona pública, accesible desde Internet, y una zona privada, a la que no se puede acceder desde el exterior. La separación entre ambas se realiza a través de un cortafuegos que, a la vez, es la pasarela de acceso desde el exterior.

Bibliografía

[1 ] Castro-Tirado, A. J. et al 1998. The Burst Observer and Optical Transient Exploring System (BOOTES) A&AS 138,583. [2] Castro-Tirado, A. J. et al. 2005 BOOTES-IR: el ojo IR del telescopio robótico de 60 cm de Sierra Nevada, Actas I Reunión Nacional de Astrofisica Robótica. Mazagón (Huelva), este volumen. [3] Stallings, W. 2000, Comunicaciones y redes de computadores (6a ed.), Prentice-Hall. [4] Comer, D.E. 1996, TCP/IP: Principios Básicos, Protocolos y Arquitectura, vol. I, (3a Ed.), Prentice-Hall. [5] Hopcroft, J., Motwani, R. y Ullman, J. 2000, Introduction to Automata Theory, Languages and Computation (2a

. Ed.) Pearson Addison Wesley.

IR

JColomé (lE

Univ. de Gra Univ. de Gra

Rolando Potts - UGRdtstc.ugr.es/~jedv/descargas/2004_astrorobot-fullscan.pdf · del sistema....

Documents

Transcript of Rolando Potts - UGRdtstc.ugr.es/~jedv/descargas/2004_astrorobot-fullscan.pdf · del sistema....