Ciclope Weather, monitorización de datos meteorológicos y gestión

Transcripción

FACULTAD DE INFORMÁTICA
ÉCOLE SUPÉRIEURE D’ÉLECTRICITÉ
UNIVERSIDAD POLITÉCNICA DE MADRID
FACULTAD DE INFORMÁTICA
TRABAJO FIN DE CARRERA
CICLOPE WEATHER
Monitorización de datos meteorológicos y gestión de alertas para un
observatorio astronómico
AUTOR: Bruno PIQUERAS
TUTOR: Francisco Manuel SÁNCHEZ MORENO
Madrid, 7 de julio de 2009
À ma famille,
Copyright ©2009 Bruno Piqueras1
Permission is granted to copy, distribute and/or modify this document under the terms
of the GNU Free Documentation License, Version 1.3[26] or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts,
and no Back-Cover Texts. Full content of the license is available at http://www.gnu.org/
copyleft/fdl.html
Se concede permiso para copiar, distribuir y/o modificar este documento bajo los
términos de la Licencia de Documentación Libre de GNU, Versión 1.3[27] o cualquier
otra versión posterior publicada por la Free Software Foundation; sin Secciones Invariantes ni Textos de Cubierta Delantera ni Textos de Cubierta Trasera. Se puede encontrar una
traducción al castellano de dicha licencia en la URL: http://stuff.danexnow.org/gfdl es.
html”. Sólo la versión original de la licencia, en inglés, tiene valor legal.
Linux es propiedad de Linus TORVALDS. El resto de marcas comerciales nombradas
en este documento son propiedad de sus respectivos propietarios. El escudo de la Facultad
de Informática de la portada es propiedad de la UPM. El logotipo de Supélec de la portada
es propiedad de Supélec.
1
Excepto las imágenes y textos gentileza de terceras partes. Sus autores se citarán expresamente en este
texto.
V
Agradecimientos
À ma famille
Aux amis / A los amigos
A todo el equipo de Ciclope Astro, por su ayuda y soporte constantes, en particular
a Raquel, Diego, Paco, Alex y Alex
A todos los compañeros de Accenture y Coritel del proyecto BTGS y en particular:
• Rocı́o Cantero Sánchez, por el testing del módem GSM
• Ernesto Paternina Moya, por el alpha testing de Ciclope Alarms
A Enrique de Guindos, del Centro Astronómico Hispano-Alemán, en Calar Alto (Almerı́a) por sus explicaciones sobre los sistemas informáticos de control del
CAHA.
A Pablo de Vicente, del Observatorio Astronómico Nacional para sus explicaciones
sobre el funcionamiento del Centro Astronómico de Yebes.
A David Cook, del Subaru Telescope [49], por sus explicaciones acerca del Subaru
Telemetry Server.
Al Dr. Thomas Granzer, del Astrophysikalisches Institut Potsdam por su tiempo y
explicaciones sobre el Observatorio robótico STELLA [5].
A William Cruise, del Canada France Hawaii Telescope [10], por su tiempo y explicaciones acerca de los sistemas informáticos de control del CFHT.
Al Dr. Jorge Nuñez de Murga, del Departament d’Astronomia i Meteorologia de
la Universitat de Barcelona por sus explicaciones sobre el proyecto Fabra-ROA
telescope at Montesec.
En fin, a todos los que me hayan ayudado y soportado durante la realización del
presente Proyecto Fin de Carrera, gracias. . .
VII
Índice general
1. Introducción
1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1. Publicar datos meteorológicos en redes de información
rológica . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.2. Gestor de alarmas Ciclope Alarms . . . . . . . . . . . .
1.2. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . .
1.3. Ciclope Astro y el Observatorio Astronómico Montegancedo . .
1.4. Trabajo del autor . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . .
meteo. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
2. Estado del Arte
2.1. Ciclo de vida de datos meteorológicos . . . . . . . . . . . . . . . . . . .
2.1.1. Producción . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2. De los datos a la información: el papel de las redes de información
meteorológica . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.3. Consumo de información meteorológica . . . . . . . . . . . . . .
2.2. Gestores de alarma . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1. Observatorios astronómicos . . . . . . . . . . . . . . . . . . . .
2.2.1.1. Centro Astronómico Hispano-Alemán A.I.E. - Calar Alto (Almerı́a) . . . . . . . . . . . . . . . . . . . . . . .
2.2.1.2. Centro Astronómico de Yebes . . . . . . . . . . . . . .
2.2.1.3. Fabra-ROA telescope at Montsec . . . . . . . . . . . .
2.2.1.4. Canada-France-Hawaii Telescope (CFHT) . . . . . . .
2.2.1.5. Subaru Telescope . . . . . . . . . . . . . . . . . . . .
2.2.1.6. Observatorio robótico STELLA . . . . . . . . . . . . .
2.2.2. Soluciones software disponibles . . . . . . . . . . . . . . . . . .
2.2.2.1. wview . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2.2. ACS . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2.3. Motores de inferencia . . . . . . . . . . . . . . . . . .
2.2.2.3.1. Motores de inferencia/reglas (Rule Engines) .
2.2.2.3.2. Drools . . . . . . . . . . . . . . . . . . . . .
2.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3. Publicar datos meteorológicos en Internet
3.1. Localización de la estación . . . . . . . . . . . . . . . . . . . . . . . . .
IX
1
2
2
2
3
4
5
7
7
8
9
10
12
13
13
13
14
14
14
15
16
17
17
18
19
20
23
25
26
3.2.
3.3.
3.4.
3.5.
3.1.1. Latitud . . . . . . . . . . . . . . . . . . . . . . .
3.1.2. Longitud . . . . . . . . . . . . . . . . . . . . . .
3.1.3. Altitud . . . . . . . . . . . . . . . . . . . . . . .
3.1.4. Tipos de unidades para coordenadas y conversiones
3.1.5. Técnicas para obtener coordenadas geográficas . .
Awekas . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1. Darse de alta . . . . . . . . . . . . . . . . . . . .
3.2.2. Configurar wview . . . . . . . . . . . . . . . . . .
3.2.3. Comprobar el buen funcionamiento . . . . . . . .
3.2.4. Cambiar la configuración a posteriori . . . . . . .
CWOP . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1. Darse de alta . . . . . . . . . . . . . . . . . . . .
Weather Underground . . . . . . . . . . . . . . . . . . . .
3.4.1. Darse de alta . . . . . . . . . . . . . . . . . . . .
3.4.4. Modificar la configuración a posteriori . . . . . . .
Red Personal Weather Stations . . . . . . . . . . . . . . .
3.5.1. Darse de alta . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4. Ciclope Alarms
4.1. Toma de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1. Propósito general . . . . . . . . . . . . . . . . . . . . . . .
4.1.2. Edición de Alarmas . . . . . . . . . . . . . . . . . . . . . .
4.1.3. Administración . . . . . . . . . . . . . . . . . . . . . . . .
4.1.4. Requisitos no funcionales . . . . . . . . . . . . . . . . . .
4.2. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1. Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1.1. Descripción de los actores . . . . . . . . . . . . .
4.2.1.2. Descripción de los casos de uso en formato breve
4.2.2. Modelo conceptual . . . . . . . . . . . . . . . . . . . . . .
4.3. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.2. Esquema de la base de datos . . . . . . . . . . . . . . . . .
4.3.2.1. Submodelo: Alarmas . . . . . . . . . . . . . . .
4.3.2.2. Submodelo: Suscripciones . . . . . . . . . . . . .
4.3.2.3. Submodelo: Permisos . . . . . . . . . . . . . . .
4.3.2.4. Submodelo: Configuración . . . . . . . . . . . .
X
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
26
26
27
28
28
29
30
31
31
32
34
34
35
36
37
37
37
37
38
39
39
40
41
41
41
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
43
43
43
44
44
45
45
45
45
47
49
51
51
53
53
56
56
57
4.3.3. Diagrama de Clases . . . . . . . . . . . . . . . . .
4.3.4. Integración de la GUI con Ciclope Astro . . . . . .
4.3.5. Motor de Alarmas . . . . . . . . . . . . . . . . .
4.4. Notas para futuras extensiones . . . . . . . . . . . . . . .
4.4.1. Inclusión de una nueva variable de monitorización
4.4.2. Inclusión de un nuevo tipo de acción . . . . . . . .
4.4.3. Inclusión de un nuevo observatorio . . . . . . . .
.
.
.
.
.
.
.
60
62
64
65
65
67
67
5. Manual de Usuario
5.1. Manual de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1. Definir una nueva alarma . . . . . . . . . . . . . . . . . . . . . .
5.1.1.1. Configuración global . . . . . . . . . . . . . . . . . .
5.1.1.2. Condiciones de activación . . . . . . . . . . . . . . . .
5.1.1.3. Acciones . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1.4. Confirmación . . . . . . . . . . . . . . . . . . . . . .
5.1.2. Editar una alarma . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.3. Suscribirse a una alarma . . . . . . . . . . . . . . . . . . . . . .
5.1.3.1. Buscar una alarma . . . . . . . . . . . . . . . . . . . .
5.1.3.2. Configurar las acciones . . . . . . . . . . . . . . . . .
5.1.4. Editar una suscripción . . . . . . . . . . . . . . . . . . . . . . .
5.2. Manual de Administrador . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1. Extensiones de las funcionalidades de usuario . . . . . . . . . . .
5.2.2. Administrar las alarmas de otros usuarios . . . . . . . . . . . . .
5.2.3. Administrar las suscripciones de otros usuarios . . . . . . . . . .
5.2.4. Gestionar los permisos de los usuarios . . . . . . . . . . . . . . .
5.2.5. Administrar el sistema . . . . . . . . . . . . . . . . . . . . . . .
5.2.5.1. Monitorización del sistema . . . . . . . . . . . . . . .
5.2.5.2. Configuración de horarios de funcionamiento del motor
de alarmas . . . . . . . . . . . . . . . . . . . . . . . .
69
69
69
69
70
70
71
71
74
75
75
75
78
78
78
80
81
83
83
6. Manual de Instalación de Ciclope Alarms
6.1. Instalación del módem GSM . . . . . . . . .
6.1.1. Cableado y puesta en funcionamiento
6.1.2. Primeras Pruebas . . . . . . . . . . .
6.1.3. Instalación de las librerı́as java . . . .
6.2. Instalación de la base de datos . . . . . . . .
6.2.1. Modo standalone . . . . . . . . . . .
6.2.2. Modo integrado con Ciclope Astro . .
6.3. Instalación del Motor de alarmas . . . . . . .
6.3.1. Prerequisitos y librerı́as . . . . . . . .
6.3.2. Instalación . . . . . . . . . . . . . .
6.3.3. Configuración . . . . . . . . . . . . .
6.4. Instalación de la GUI . . . . . . . . . . . . .
6.4.1. Prerequisitos y librerı́as . . . . . . . .
6.4.2. Instalación . . . . . . . . . . . . . .
87
87
88
88
89
89
90
90
91
91
92
93
95
95
96
XI
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
84
7. Conclusión
7.1. Conclusiones generales . . . . . . . . . . . . . .
7.2. Futuras Mejoras . . . . . . . . . . . . . . . . . .
7.2.1. Soporte de lógica borrosa . . . . . . . . .
7.2.2. Añadir de nuevos observatorios, tipos de
variables de monitorización . . . . . . .
7.2.3. Mejoras a la parte de edición de alarmas .
7.2.4. Mejoras a la parte de administración . . .
. . . . .
. . . . .
. . . . .
acciones
. . . . .
. . . . .
. . . . .
99
. . . . . . . . 99
. . . . . . . . 100
. . . . . . . . 100
y fuentes de
. . . . . . . . 100
. . . . . . . . 101
. . . . . . . . 101
A. Enabling Wunderground/WeatherForYou frequency configuration in wview 103
A.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
A.2. Short description of desired behaviour . . . . . . . . . . . . . . . . . . . 103
A.3. Details of implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 104
A.3.1. http/http.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
A.3.2. http/http.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
A.3.3. common/sysdefs.h . . . . . . . . . . . . . . . . . . . . . . . . . 105
A.3.4. wviewconfig/wviewconfig.sh . . . . . . . . . . . . . . . . . . . . 105
A.4. Diff report from wview version 4.01 . . . . . . . . . . . . . . . . . . . . 105
B. Informe: Soluciones para mandar SMS automáticamente
B.1. Módems GSM . . . . . . . . . . . . . . . . . . . . . .
B.1.1. Compatibilidad con GNU/Linux . . . . . . . .
B.1.2. Precios . . . . . . . . . . . . . . . . . . . . .
B.2. Móvil convencional . . . . . . . . . . . . . . . . . . .
B.3. Tarifas GSM Operadoras clásicas . . . . . . . . . . . .
B.3.1. Movistar . . . . . . . . . . . . . . . . . . . .
B.3.2. Vodafone . . . . . . . . . . . . . . . . . . . .
B.3.3. Orange . . . . . . . . . . . . . . . . . . . . .
B.3.4. Yoigo . . . . . . . . . . . . . . . . . . . . . .
B.3.5. Operadores virtuales . . . . . . . . . . . . . .
B.4. Servicios on-line . . . . . . . . . . . . . . . . . . . .
B.5. Conclusión . . . . . . . . . . . . . . . . . . . . . . .
C. ERS Ciclope Alarms
C.1. Introducción . . . . . . . . . . . . . . . . . . .
C.1.1. Propósito . . . . . . . . . . . . . . . .
C.1.2. Ámbito del Sistema . . . . . . . . . . .
C.1.3. Definiciones, Acrónimos y Abreviaturas
C.1.3.1. Definiciones . . . . . . . . .
C.1.3.2. Acrónimos . . . . . . . . . .
C.1.3.3. Abreviaturas . . . . . . . . .
C.1.4. Referencias . . . . . . . . . . . . . . .
C.1.5. Visión general del Documento . . . . .
C.2. Descripción General . . . . . . . . . . . . . .
C.2.1. Perspectiva del producto . . . . . . . .
XII
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
113
113
114
115
116
119
119
119
119
119
120
120
121
.
.
.
.
.
.
.
.
.
.
.
123
123
123
123
123
123
124
124
124
124
125
125
C.2.2. Funciones del sistema . . . . . . . . . . . . . . . . . . . . . . . 125
C.2.2.1. Edición de alarmas . . . . . . . . . . . . . . . . . . . 125
C.2.2.2. Administración de Ciclope Alarms . . . . . . . . . . . 125
C.2.3. Caracterı́sticas de los Usuarios . . . . . . . . . . . . . . . . . . . 126
C.2.4. Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
C.2.5. Suposiciones y Dependencias . . . . . . . . . . . . . . . . . . . 126
C.2.5.1. Suposiciones . . . . . . . . . . . . . . . . . . . . . . . 126
C.2.5.2. Dependencias . . . . . . . . . . . . . . . . . . . . . . 126
C.3. Requisitos Especı́ficos . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
C.3.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . 126
C.3.1.1. Edición de alarmas . . . . . . . . . . . . . . . . . . . 126
C.3.1.1.1. Definición de alarmas . . . . . . . . . . . . . 126
C.3.1.1.2. Suscripciones . . . . . . . . . . . . . . . . . 129
C.3.1.1.3. Otras tareas de gestión . . . . . . . . . . . . 130
C.3.1.2. Administración de Ciclope Alarmas . . . . . . . . . . 131
C.3.1.2.1. Configuración global del sistema . . . . . . . 131
C.3.1.2.2. Control de las alarmas definidas por los usuarios131
C.3.1.2.3. Gestión de permisos de los usuarios . . . . . 131
C.3.2. Requisitos de reusabilidad . . . . . . . . . . . . . . . . . . . . . 132
C.3.2.1. Requisito(46) . . . . . . . . . . . . . . . . . . . . . . 132
C.3.2.2. Requisito(47) . . . . . . . . . . . . . . . . . . . . . . 132
C.3.2.3. Requisito(48) . . . . . . . . . . . . . . . . . . . . . . 133
C.3.3. Requisitos de interfaces externas . . . . . . . . . . . . . . . . . . 133
C.3.3.1. Requisito(49) . . . . . . . . . . . . . . . . . . . . . . 133
C.3.4. Requisitos tecnológicos . . . . . . . . . . . . . . . . . . . . . . 133
C.3.4.1. Requisito(50) . . . . . . . . . . . . . . . . . . . . . . 133
C.3.4.2. Requisito(51) . . . . . . . . . . . . . . . . . . . . . . 133
Bibliografı́a
135
XIII
Índice de figuras
2.1. Ciclo de vida de la información meteorológica . . . . . . . . . . . . . . .
2.2. Meteohub: configuración de publicación de datos hacia redes de información meteorológica (fuente: página oficial de Meteohub [43]) . . . . . . .
2.3. Gnome Weather Applet . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4. WeatherBug Widget for Windows (fuente: página web oficial de WeatherBug [71]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5. Configuración de una alarma en STS (autor: David Cook) . . . . . . . . .
2.6. Estructura de ACS (fuente: documentación de ACS [11]) . . . . . . . . .
2.7. Logotipo de Drools (fuente: documentación de Drools [39]) . . . . . . .
2.8. Esquema de un motor de reglas (fuente: documentación de Drools [37]) .
2.9. Red de reglas sintetizada por el plugin Drools para Eclipse . . . . . . . .
12
16
18
20
20
22
3.1. Latitud y longitud (autor: José Alberto Bermúdez y el Instituto Superior
de Formación y Recursos en Red para el Profesorado [8]) . . . . . . . . .
3.2. Dar de alta una estación en Awekas . . . . . . . . . . . . . . . . . . . . .
3.3. Mapa de España en Awekas . . . . . . . . . . . . . . . . . . . . . . . . .
3.4. Red Awekas en Google Earth . . . . . . . . . . . . . . . . . . . . . . . .
3.5. Petición de un Call Sign id para CWOP . . . . . . . . . . . . . . . . . .
3.6. Datos de una estación meteorológica en CWOP . . . . . . . . . . . . . .
3.7. Formulario de Weather Underground . . . . . . . . . . . . . . . . . . . .
3.8. Datos de una estación meteorológica en Weather Underground . . . . . .
3.9. Formulario de PWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.10. Datos de una estación meteorológica en PWS . . . . . . . . . . . . . . .
27
30
32
33
34
36
38
39
40
42
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
4.7.
4.8.
4.9.
4.10.
4.11.
4.12.
44
46
47
48
48
50
52
55
57
58
59
61
Ciclo de vida Iterativo - Unified Process (autor: Westerhoff [72])
Modelo de Casos de Uso - Nivel 0 . . . . . . . . . . . . . . . .
Caso de Uso Gestionar Alarmas - Nivel 1 . . . . . . . . . . . .
Caso de Uso Gestionar Suscripciones - Nivel 1 . . . . . . . . .
Caso de Uso Administrar Alarmas - Nivel 1 . . . . . . . . . . .
Modelo conceptual . . . . . . . . . . . . . . . . . . . . . . . .
Arquitectura general . . . . . . . . . . . . . . . . . . . . . . .
Esquema de la base de datos - Alarmas . . . . . . . . . . . . . .
Esquema de la base de datos - Suscripciones . . . . . . . . . . .
Esquema de la base de datos - Permisos . . . . . . . . . . . . .
Esquema de la base de datos . . . . . . . . . . . . . . . . . . .
Diagrama de Clases - Alarmas . . . . . . . . . . . . . . . . . .
XV
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
11
12
4.13.
4.14.
4.15.
4.16.
Estados de una alarma . . . . . . . . . . . .
Interfaz gráfica - modo standalone . . . . . .
Interfaz gráfica - integrado con Ciclope Astro
Diagrama de Clases - Motor de Alarmas . . .
5.1. Crear una nueva alarma . . . . . . . . . .
5.2. Gestionar sus alarmas . . . . . . . . . . .
5.3. Editar una alarma . . . . . . . . . . . . .
5.4. Crear una nueva suscripción . . . . . . .
5.5. Gestionar sus suscripciones . . . . . . . .
5.6. Editar una suscripción . . . . . . . . . . .
5.7. Edición de una alarma - administrador . .
5.8. Administrar las alarmas de otros usuarios
5.9. Gestionar los permisos . . . . . . . . . .
5.10. Administrar el sistema . . . . . . . . . .
XVI
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
62
63
64
66
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
72
73
74
76
77
77
79
80
82
85
Índice de tablas
2.1. Soluciones software para operar una estación meteorológica . . . . . . .
9
6.1. Librerı́as necesarias para el motor de alarmas . . . . . . . . . . . . . . .
6.2. Librerı́as necesarias para la interfaz gráfica . . . . . . . . . . . . . . . . .
91
95
B.1.
B.2.
B.3.
B.4.
B.5.
Compatibilidad GNU/Linux de los modelos de módems .
Precios de distintos modelos de módems . . . . . . . . .
Modelos de móviles recomendados por Ozenkisms . . .
Móviles compatibles con GNU/Linux . . . . . . . . . .
Ventajas e inconvenientes de cada tipo de solución SMS .
XVII
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
114
115
116
118
121
Resumen
El Proyecto Fin de Carrera expuesto en este documento se inscribe en el marco del proyecto Ciclope [13]. Tiene como objetivos mejorar el funcionamiento de la estación meteorológica Ciclope Weather [14] ası́ como el gestor de alarmas de la misma para permitir
la monitorización del Observatorio Astronómico de Montegancedo a partir del portal web
Ciclope Astro [12].
El trabajo realizado por el autor se organiza según dos grandes objetivos:
Publicar los datos de la estación meteorológica en redes de información meteorológica para hacerlos accesibles a un mayor número de usuarios finales.
Diseñar e implementar un gestor de alarmas flexible, genérico y fácilmente ampliable: Ciclope Alarms.
Résumé
Le Projet de Fin d’Études exposé dans ce document s’inscrit dans la continuité du projet
Ciclope [13]. Ses objectifs sont d’améliorer le fonctionnement de la station météorologique Ciclope Weather [14] et en particulier de son système d’alarmes afin de permettre le
contrôle de l’Observatoire Astronomique de Montegancedo à partir du portail web Ciclope Astro [12].
Le travail réalisé par l’auteur s’organise selon deux grands objectifs:
Publier les données de la station météorologique auprès des réseaux d’information
météorologique afin de les rendre accessibles au plus grand nombre d’utilisateurs
possible.
Concevoir et réaliser un système d’alarmes flexible, générique et facilement extensible: Ciclope Alarms.
Capı́tulo 1
Introducción
El clima y las condiciones meteorológicas en general siempre han tenido una importancia crucial para las actividades humanas. En la antigüedad, se observaban rituales para
apaciguar a los dioses y que éstos proporcionaran condiciones meteorológicas propicias
a buenos cultivos. Los griegos solı́an sacrificar animales a Poseidón antes de los viajes
marı́timos para evitar posibles naufragios.
Hoy en dı́a, siguen siendo de una importancia vital para muchas actividades y no
estamos siempre a salvo de catástrofes naturales, como lo demuestra regularmente la actualidad. La monitorización de las condiciones meteorológicas ası́ como la predicción de
las mismas se han convertido en disciplinas imprescindibles en determinados campos.
Por ejemplo, los aeropuertos tienen estaciones meteorológicas dedicadas a esta tarea para asegurar la seguridad de los vuelos. Ası́ pueden suspender la realización de los
despegues y aterrizajes si las condiciones meteorológicas no son adecuadas.
Los observatorios astronómicos suelen también contar con la presencia de una estación meteorológica esta vez para poder proteger equipos costosos de las intemperies. En
efecto, las observaciones astronómicas sólo se pueden realizar si las condiciones meteorológicas lo permiten. En caso contrario, la cúpula o el techo deslizante del observatorio
se tiene que cerrar para proteger el telescopio ası́ como otros tipos de instrumentos astronómicos. Tradicionalmente, esta decisión está tomada por operadores presentes en el
sitio. Pero, es cada vez más común delegar esta tarea a sistemas informáticos, especialmente en observatorios muy automatizados, o ubicados en sitios poco accesibles.
El Observatorio Astronómico Montegancedo, inaugurado el 23 de enero del 2009 y
ubicado en el campus de la Facultad de Informática de la Universidad Politécnica de Madrid tiene la vocación de tener un funcionamiento totalmente autónomo. Este observatorio
tiene la particularidad de ser de acceso libre y gratuito. En efecto, cualquier persona puede
mediante un sistema de reservas accesible en el portal web Ciclope Astro [12] realizar observaciones astronómicas utilizando los recursos del observatorio. Por eso, debe permitir,
a medio plazo, observaciones astronómicas en cualquier hora del dı́a.
Estas reflexiones y exigencias constituyen el punto de partida de la realización de este
Proyecto Fin de Carrera, titulado Ciclope Weather - Monitorización de datos meteorológicos y gestión de alertas para un observatorio astronómico.
1
1.1.
Objetivos
La situación inicial, i.e. antes de la realización de este Proyecto Fin de Carrera era
la siguiente: el Observatorio Astronómico Montegancedo estaba a punto de estar inaugurado y su estación meteorológica, anterior al Observatorio, llevaba dos años funcionando, capturando y almacenando datos en base de datos. Gracias al software de control de la estación, wview [66], se publicaban los datos en la página web siguiente:
http://www.ciclope.info/weather y con el fin de monitorizar las condiciones meteorológicas, se utilizaba el gestor de alarmas integrado en wview. Este gestor de alarmas, como se
verá en la sección 2.2.2.1 , no cumple con todas las expectativas de los usuarios.
La realización del presente Proyecto Fin de Carrera pretende aportar mejoras a esta
situación inicial, realizando principalmente dos objetivos:
Publicar los datos de la estación meteorológica en redes de información meteorológica para que sean accesibles a un mayor número de usuarios finales.
Mejorar la gestión de alarmas en el Observatorio, concibiendo e implementando
un gestor de alarmas flexible, configurable y que se pueda fácilmente ampliar en el
futuro.
1.1.1.
Publicar datos meteorológicos en redes de información meteorológica
El objetivo principal perseguido en esta parte es hacer un estudio sobre los métodos
para publicar datos meteorológicos en redes de información meteorológica, documentando los pasos a seguir para cada uno y aplicarlos al caso de la estación meteorológica
Ciclope Weather.
1.1.2.
Gestor de alarmas Ciclope Alarms
El objetivo de mejorar la gestión de alarmas en el Observatorio es sin duda el objetivo
cuya realización habrá necesitado más tiempo y esfuerzo, convirtiéndolo de facto en el
objetivo principal del presente Proyecto Fin de Carrera. A lo largo del diseño y de la
realización del mencionado gestor de Alarmas, bautizado Ciclope Alarms, se tuvieron en
cuenta los objetivos secundarios siguientes:
Configuración dinámica de alarmas vı́a el portal web Ciclope Astro.
Carácter genérico de la solución: Ciclope Alarms tiene que permitir la monitorización simultánea de varios observatorios.
Carácter extensible de la solución: el sistema se podrá ampliar fácilmente para incluir otras variables de monitorización (e.g. sensores) ası́ como otros tipos de acciones a realizar.
2
La solución debe utilizar exclusivamente software libre, compatible con la licencia
GNU GPL [25]. Se publicará, bajo los términos de la licencia GNU GPL, en el
repositorio de fuentes del proyecto Ciclope Astro, alojado en sourceforge.net [15].
1.2.
Estructura de la memoria
El presente documento consta de varios capı́tulos constituyendo la parte principal de
la memoria ası́ como una serie de anexos complementando el contenido principal.
Capı́tulo 1: Introducción (el presente capı́tulo). Proporciona una visión general del
trabajo realizado y de los objetivos seguidos.
Capı́tulo 2: Estado del Arte. Presenta el estudio del arte necesario a la realización
de los objetivos. Se presentan en una primera parte los sistemas existentes que intervienen en las distintas etapas del ciclo de vida de los datos meteorológicas. En una
segunda parte del capı́tulo, se presentan sistemas con finalidades de uso similares a
Ciclope Alarms, incluyendo al gestor de alarmas utilizado previamente (wview).
Capı́tulo 3: Publicar Datos meteorológicos en Internet. En este capı́tulo, se detallan los pasos seguidos para publicar los datos meteorológicos recolectados por una
estación meteorológica en varias redes de información meteorológica.
Capı́tulo 4: Ciclope Alarms. En esta sección, se detallan el diseño y la implementación del gestor de alarmas Ciclope Alarms.
Capı́tulo 5: Manual de Usuario. En este capı́tulo, se exponen las instrucciones de
utilización del sistema Ciclope Alarms.
Capı́tulo 6: Manual de instalación. Este anexo incluye las instrucciones de instalación del sistema Ciclope Alarms.
Capı́tulo 7: Conclusión. En este último capı́tulo, se presentan las conclusiones obtenidas de la realización del Proyecto Fin de Carrera y se indican lı́neas de futuras
mejoras al mismo.
Anexo A: Enabling Wunderground/WeatherForYou frequency configuration
in wview. En este anexo, se describen los cambios realizados por el autor a la aplicación wview para mejorar la flexibilidad de la misma a la hora de publicar datos
meteorológicos en las redes Wunderground y WeatherForYou. Este anexo está enteramente redactado en inglés dado que se trata de una contribución al proyecto de
software libre wview, de ámbito internacional.
Anexo B: Informe: Soluciones para mandar SMS automaticamente. En este
anexo, se presentan las distintas soluciones existentes para ser capaces de mandar
SMS automáticamente (una de las funciones de Ciclope Alarms), ası́ como recomendaciones acerca de la solución más adaptada a nuestras necesidades.
3
Anexo C: ERS Ciclope Alarms. Este anexo recopila de manera formal y pormenorizada los requisitos del sistema Ciclope Alarms. Se basa en el estándar IEEE 830
Recommended Practice for Software Requirements Specifications[35].
1.3.
Ciclope Astro y el Observatorio Astronómico Montegancedo
El Observatorio Astronómico Montegancedo, situado en la Facultad de Informática de
la Universidad Politécnica de Madrid e integrado en la red ASTROCAM de la Comunidad
de Madrid, fue oficialmente inaugurado el 23 de enero del 2009, coincidiendo con el inicio
del Año Internacional de la Astronomı́a 2009.
Se trata del primer observatorio astronómico del mundo de acceso libre y gratuito. Se
controla remotamente mediante el portal web 2.0 Ciclope Astro [12], desarrollado por los
miembros del proyecto Ciclope [13].
Ciclope Astro proporciona una serie de herramientas para experimentos astronómicos,
creación de escenarios y control de telescopios, cámaras y cúpulas de forma remota, y
permite a cualquier internauta acceder desde su casa al observatorio para vivir diferentes
experiencias astronómicas. A finales de 2008, Ciclope Astro obtuvo el segundo premio
de la octava edición de Nuevas Aplicaciones para Internet, organizado por la Cátedra de
Internet de Nueva Generación.
Desde finales de 2008, se ha puesto en marcha en el observatorio un experimento
para observar el Sol en la banda H-alfa y distinguir las manchas y protuberancias solares, además de aprender a cambiar los diferentes parámetros de las cámaras para obtener
buenas imágenes astronómicas. Aunque para acceder al control del observatorio hay que
realizar previamente una reserva, en cualquier momento se puede ver desde casa lo que
está ocurriendo a través de cuatro webcams que actualizan sus imágenes cada 20 segundos
si no se está registrado y cada segundo si el usuario está registrado.
El observatorio está ubicado en el Edificio 6 de la FIUPM, en el Campus de Montegancedo, Boadilla del Monte. Dentro de la cúpula está instalado un telescopio de 10”,
robotizado y automatizado mediante ordenador, y diversos equipos que sirven tanto como
servidor de las aplicaciones web, como de conexión y difusión de las imágenes y vı́deos
que captan las webcams dispuestas por la cúpula. Todos corren con sistemas GNU/Linux.
El principal objetivo del observatorio robotizado es controlar hasta el más mı́nimo detalle de un proyecto astronómico, automatizando todas las tareas y haciéndolas accesibles
y controlables a través de Internet.
Antes de su inauguración el observatorio astronómico de Montegancedo ya habı́a tenido varias experiencias participativas de éxito. Una de ellas tuvo lugar en julio del 2008,
cuando colaboró en una observación divulgativa de los cráteres de la luna. La actividad se
realizó en pantalla gigante en el museo Cosmo Caixa de Madrid y su retransmisión pudo
seguirse en directo a través de Internet.
4
1.4.
Trabajo del autor
Este proyecto se inscribe en el marco del proyecto Ciclope[13]. Su realización se basa
y complementa los siguientes sistemas existentes:
Ciclope Weather[14]: estación meteorológica de la Facultad de Informática.
Ciclope Astro[12]: Portal Web 2.0 permitiendo, entre otras funcionalidades, el control remoto del Observatorio Astronómico de Montegancedo.
Para alcanzar los objetivos expuestos en este capı́tulo, el autor ha realizado los trabajos
siguientes:
Estudio teórico del estado del arte, tanto para la publicación de datos meteorológicos en Internet, como para la gestión de alarmas, aplicada al ámbito de un observatorio astronómico. Se encuentra en el capı́tulo 2.
Registro de la estación meteorológica Ciclope Weather en las redes meteorológicas
Awekas, CWOP, PWS, Wunderground y configuración de wview para subir los
datos hacia ellas. Los pasos están documentados en el capı́tulo 3.
Ligera modificación del software wview para adecuarse mejor a las exigencias de
PWS. Dichos cambios están documentados en el anexo A.
Elaboración de un informe sobre soluciones existentes para mandar SMS. Este informe se puede encontrar en el anexo B.
Diseño e implementación del sistema Ciclope Alarms.
Integración del mismo en el portal Ciclope Astro.
Elaboración de un manual de usuario y un manual de instalación para el sistema
Ciclope Alarms.
5
6
Capı́tulo 2
Estado del Arte
Este capı́tulo tiene como objetivo describir el estado del arte en las áreas tecnológicas
que tienen un papel central en la realización de los objetivos planteados, que son: la publicación de datos meteorológicos y la concepción de un sistema gestor de alarmas para
un observatorio astronómico.
En la sección 2.1, se presenta el panorama general que constituye el flujo de datos
meteorológicos, de la producción a la consumición de los mismos, detallando el papel de
las redes y organizaciones involucradas en el proceso.
En la sección 2.2, se describen varias formas de enfocarse a la problemática general
de gestión de alarmas, en particular aplicada al ámbito de un observatorio astronómico.
Se exponen brevemente las soluciones adoptadas por varios observatorios astronómicos,
ası́ como soluciones software que pueden ser pertinentes para la implementación de un
gestor de alarmas.
Por fin, en la sección 2.3, se exponen las conclusiones del presente estudio del estado
del arte.
2.1.
Ciclo de vida de datos meteorológicos
En esta sección se pretende detallar el ciclo de vida tı́pico que pueden conocer los datos meteorológicos, desde su producción hasta su consumo. En efecto, este ciclo de vida
sigue un paradigma productor/consumidor, un productor es cualquier persona u organización disponiendo del material necesario a la colección de datos meteorológicos, y un
consumidor es cualquier persona u organización interesada en información meteorológica.
Este ciclo de vida está ilustrado sintéticamente en la figura 2.1.
En el apartado 2.1.1, se hace un breve repaso de las soluciones que existen para producir datos meteorológicos. En el apartado 2.1.2, se detallan las redes existentes que permiten el almacenamiento de los datos meteorológicos ası́ como la transformación y la
transmisión de los mismos hasta los usuarios finales. Por fin, el apartado 2.1.3 se dedica
a los distintos modos de consumo de información meteorológica.
7
Figura 2.1: Ciclo de vida de la información meteorológica
2.1.1.
Producción
La primera etapa, en el ciclo de vida de datos meteorológicos, es sin duda la producción de los mismos. Para generar datos meteorológicos, dispositivos hardware especı́ficos, o sensores son necesarios. Un sensor suele ser dedicado a la medición de una variable
meteorológica en concreto, por ejemplo la temperatura, o la presión atmosférica. Por esta
razón, se suelen agrupar en un mismo dispositivo, que constituye entonces una estación
meteorológica, distintos sensores para medir un rango más o menos amplio de variables
meteorológicas. El mercado ofrece una variedad de soluciones posibles en este campo, en
el cual destacan los constructores siguientes: Davis Instrument, La Crosse Technology, y
Oregon Scientific.
Aunque el hardware de las estaciones meteorológicas modernas ofrece mucha funcionalidad, el software es necesario para llevar a cabo ciertas tareas como almacenar de
manera permanente los datos, publicar los mismos, como se detalla en el apartado 2.1.2,
o de manera más general utilizarlos.
Una lista de soluciones software que permiten operar una estación meteorológica se
encuentra en la tabla 2.1. Cada solución software permite operar un rango más o menos
amplio de estaciones meteorológicas.
8
Tabla 2.1: Soluciones software para operar una estación meteorológica
Software
wview[66]
MeteoHub1
Weather Display 2
Open2300 3
PC-Weatherstation 4
Virtual Weather Station5
Weather Link 6
FreeWX 7
Tipo
Open Source
Modelos de estación
Davis Vantage Pro/Pro2, La Crosse WS2300/2305/2310/2315,
Oregon
Scientific
WMR918/968
Comercial
Casi todos
Comercial
Casi todos
Opens Source Lacrosse WS2300/WS2305/WS2310/WS2315
Comercial
La Crosse WS2000/WS2500, Oregon Scientific
WMR-918/928/968, WM-918, Davis VantagePro
Comercial
Casi todos
Comercial
Todos los modelos de Davis
Freeware
Todos los modelos de Oregon Scientific
Mediante el uso de una de las soluciones software mencionadas previamente, se puede
operar una estación meteorológica, almacenar los datos medidos y utilizarlos de manera
local.
2.1.2.
De los datos a la información: el papel de las redes de información meteorológica
Si bien utilizar datos meteorológicos de una forma exclusivamente local puede tener
un interés, en particular en la monitorización de una actividad local (aeropuerto, observatorio astronómico, planta. . . ), muchas aplicaciones, como la predicción meteorológica,
requieren la recolección de datos de varios sitios, para posterior procesado en vista de
convertir lo que son datos brutos en información valiosa.
Las redes de información meteorológica cumplen esta doble función de intermediarios
y transformadores entre los productores de datos (brutos) y los consumidores de información meteorológica.
Se puede distinguir dos tipos de redes de información meteorológica, las redes oficiales, que operan con un paradigma jerárquico, recolectando datos meteorológicos de
estaciones meteorológicas de confianza y varias redes privadas, que admiten además de
los datos de las redes oficiales, datos procedentes de estaciones meteorológicas de particulares.
1
http://www.meteohub.de/
http://www.weather-display.com/index.php
3
http://www.lavrsen.dk/twiki/bin/view/Open2300/WebHome
4
http://www.pc-wetterstation.de/en1index.html
5
http://www.ambientweather.com/virtualstation.html
6
http://www.weatherlink.com/start.php
7
http://www.freewx.net
2
9
Las redes oficiales están coordenadas a nivel internacional por la Organización Mundial de Meteorologı́a o World Meteorological Organization[74], que es un programa financiado por la ONU. Éste cuenta con la cooperación de 188 paı́ses y territorios miembros.
Las redes de información meteorológica gestionadas por la OMM tienen una estructura
jerárquica, con divisiones regionales, los Regional Telecommunication Hubs. Éstos están
compuestos por redes nacionales, operadas por los organismos nacionales competentes.
Por ejemplo, en España, este papel está desempeñado por la AEMet, o Agencia Estatal
de Meteorologı́a [1]. Su Regional Telecommunication Hub es el RTH de Toulouse, Francia. En EEUU, se trata de la National Oceanographic and Atmospheric Administration o
NOAA [53].
En paralelo, o a veces en complemento de estas redes oficiales, existen varias redes,
privadas, abiertas a la participación de particulares. Destacan los siguientes programas:
Awekas [7].
Hamweather [34].
Weather Underground [70].
Weather For You [69].
Weatherbug [71].
CWOP (programa civil de la NOAA) [52].
Las soluciones software que existen para operar estaciones meteorológicas, descritas
en el apartado 2.1.1, suelen incluir la funcionalidad necesaria para publicar datos meteorológicos a una o varias de estas redes. Por ejemplo, wview permite subir datos a las
redes Awekas, Hamweather, WeatherUnderground, Weather For You y CWOP. De manera general, para publicar datos en estas redes, la persona u organización responsable de la
estación meteorológica debe completar un proceso de alta antes de activar, en el software
utilizado, la publicación de datos hacia las redes deseadas. Más detalles acerca de este
tema se pueden encontrar en el capı́tulo 3.
La figura 2.2 ilustra un ejemplo de configuración del software Meteohub, para publicar
datos hacia distintas redes de información meteorológica.
2.1.3.
Consumo de información meteorológica
Existen varios canales de consumo de la información meteorológica. Tradicionalmente, dicha información meteorológica se consumı́a exclusivamente a través de los canales
de comunicación que son la prensa, la radio y la televisión, en forma de informes meteorológicos, elaborados por los organismos oficiales de meteorologı́a.
La revolución informática y el auge de Internet ha contribuido a la emergencia de
nuevos canales de consumo. Hoy en dı́a, además de los medios tradicionales mencionados
previamente, uno puede acceder a información meteorológica de manera informatizada,
bien consultando páginas web dedicadas, bien instalando aplicaciones (paradigma cliente
pesado) a este efecto.
10
Figura 2.2: Meteohub: configuración de publicación de datos hacia redes de información
meteorológica (fuente: página oficial de Meteohub [43])
Elaborar una lista completa de las páginas web proporcionando información meteorológica es prácticamente imposible. Aún ası́, se pueden mencionar las siguientes:
Páginas web de las agencias nacionales de meteorologı́a e.g. AEMet, o NOAA.
Páginas web de las redes privadas mencionadas en el apartado 2.1.2.
http://www.weather.com (número 1 en Alexa).
http://www.accuweather.com/ (número 4 en Alexa).
http://www.intellicast.com (número 7 en Alexa).
Más páginas se pueden encontrar en la URL:http://www.alexa.com/topsites/category/Top/
News/Weather
De la misma manera, catalogar de manera exhaustiva aplicaciones de escritorio que
permiten visualizar información meteorológica es imposible, dada la cuantı́a. Se puede
mencionar las siguientes, por su relevancia:
En entornos KDE, kweather.
En entornos Gnome, Weather report applet (figura 2.3).
En entornos Windows, Vista side bar.
11
Figura 2.3: Gnome Weather Applet
Figura 2.4: WeatherBug Widget for Windows (fuente: página web oficial de WeatherBug
[71])
En Mac OS, Meteorologist.
La mayorı́a de las páginas web mencionadas en este apartado, ası́ como las redes de
información meteorológica presentadas en el apartado 2.1.2, proveen algún widget, para
instalar en entornos Windows o Mac OS. Por ejemplo, la red Weatherbug [71] publica en
su página web, un widget para Windows, como se puede apreciar en la figura 2.4.
Tanto las páginas web como las aplicaciones de escritorio utilizan datos disponibles
en una o varias de las redes descritas en el apartado 2.1.2.
2.2.
Gestores de alarma
El objetivo de esta sección es estudiar el estado del arte de la gestión de alarmas en el
ámbito astronómico, con el fin de ayudar a la concepción e implementación de un gestor
12
de alarmas adecuado para el Observatorio Astronómico Montegancedo. En el apartado
2.2.1, se exponen las soluciones adoptadas por varios observatorios astronómicos en el
mundo. En el apartado 2.2.2, se repasan las soluciones software disponibles que permiten
responder a la problemática planteada.
2.2.1.
Observatorios astronómicos
2.2.1.1.
Centro Astronómico Hispano-Alemán A.I.E. - Calar Alto (Almerı́a)
El Observatorio Astronómico Hispano-Alemán de Calar Alto está situado en la Sierra
de Los Filabres, norte de Almerı́a (Andalucı́a, España). Es operado conjuntamente por el
Instituto Max-Planck de Astronomı́a en Heidelberg, Alemania, y el Instituto de Astrofı́sica de Andalucı́a (CSIC) en Granada, España. Calar Alto proporciona tres telescopios con
aperturas de 1.23m, 2.2m y 3.5m. Un telescopio de 1.5m, también localizado en la montaña, es operado bajo el control del Observatorio de Madrid.
Este observatorio dispone de un sistema de monitorización de las condiciones meteorológicas, de desarrollo propio y propiedad del observatorio. Consta de una estación
meteorológica, del constructor noruego Aanderaa, de un módulo principal que interroga
cada treinta segundos el hardware de la estación y propaga los datos hasta todos los módulos que los necesitan, cierre de los telescopios, advertencias, aplicaciones de visualización
de los datos . . . .
Cada telescopio tiene un grado de automatismo distinto. El más pequeño es totalmente
robotizado y sirve de telescopio auxiliar, i.e. aporta información a los demás telescopios
que son los que sirven para las observaciones astronómicas. Por otro lado, los más grandes
siempre están controlados por astrónomos.
El sistema de monitorización permite tomar decisiones automáticas como cerrar una
cúpula. Las condiciones de apertura o cierre de una cúpula son fijas, preestablecidas y
dependen del telescopio. En caso de producirse una alarma meteorológica que provoca el
cierre de una cúpula, debido al fenómeno de histéresis8 , el sistema impide la reapertura
de la cúpula durante un intervalo de tiempo determinado a partir del momento en el cual
las condiciones meteorológicas vuelvan a permitir las operaciones. Por ejemplo, para uno
de los telescopios, si la velocidad del viento supera los 14 metros por segundo, se cierra
automáticamente la cúpula. Para poder volverse a abrir, tienen que transcurrir 15 minutos
por debajo de 12 metros por segundo.
Se pueden encontrar más detalles sobre las condiciones de apertura de las cúpulas
en la página web del observatorio [9]. Adicionalmente, se puede encontrar más información acerca de la estructura del sistema informático de control del observatorio en una
publicación de la revista Novática [32].
2.2.1.2.
Centro Astronómico de Yebes
El Centro Astronómico de Yebes está situado a unos 70 km de Madrid, en el término
municipal de Yebes, en la provincia de Guadalajara. Consta de dos radiotelescopios (uno
8
Fenómeno por el que el estado de un material depende de su historia previa. Se manifiesta por el retraso
del efecto sobre la causa que lo produce.
13
de 14 metros de diámetro y otro muy reciente de 40 metros de diámetro) ası́ como dos
telescopios ópticos.
El sistema informático de control del centro incluye una estación meteorológica, ubicada a 1,5 km de los radiotelescopios para evitar las interferencias. Está conectada al resto
del centro a través de fibra óptica. El software utilizado para el control del centro está basado en ACS, o ALMA Common Software [20], desarrollado conjuntamente por ESO
(European Southern Observatory) y el CERN. El centro siempre cuenta con la presencia
fı́sica de operadores durante las observaciones, que pueden monitorizar las condiciones
meteorológicas gracias a los clientes CORBA proporcionados por la infraestructura ACS,
por lo cual no tiene la necesidad de implementar un sistema de alarmas.
2.2.1.3.
Fabra-ROA telescope at Montsec
El telescopio Fabra-ROA [21], ubicado en Montsec, es un proyecto en curso, que involucra distintas organizaciones como el Observatorio Fabra (Barcelona), el Real Instituto
y Observatorio de la Armada (ROA) y el Departament d’Astronomia i Meteorologia de
la Universitat de Barcelona. Todavı́a no está operativo sino que se encuentra en fase de
implementación.
El objetivo es una automatización completa del sitio. El sistema de control involucra
una estación meteorológica Vaisala ası́ como un detector de nubes y un detector de tormentas. El software de control, de desarrollo propio, está basado en INDI [47]. Los lı́mites
de funcionamiento están fijados en ficheros de configuración. Por ejemplo, cuando la velocidad del viento supera los 15m/s, se cierra el techo deslizante. Lo mismo pasa cuando
la humedad supera el 90 %. Otras propiedades se pueden configurar como la velocidad
máxima de desplazamiento del telescopio.
2.2.1.4.
Canada-France-Hawaii Telescope (CFHT)
El telescopio Canada-France-Hawaii Telescope [10] es un telescopio de 3.6 metros de
diámetro ubicado en la cima del Mauna Kea, un volcán durmiente de Hawaii, que alcanza
los 4200 metros de altura. Está en funcionamiento desde 1977.
El observatorio está ahora mismo en proceso de renovación y uno de los objetivos es
permitir el control remoto del mismo. De momento, cuenta con la presencia fı́sica de dos
personas, que toman las decisiones de cerrar la cúpula.
Dispone de un sistema de alarmas, de desarrollo interno, configurable mediante ficheros de script escritos en Tcl-Tk o Java. Tiene capacidad de mandar SMS o llamar por
teléfono a los responsables técnicos, en caso de problema.
2.2.1.5.
Subaru Telescope
El Telescopio Subaru, operado por el Observatorio Astronómico Nacional de Japón,
está ubicado en la cima del Mauna Kea, en Hawaii, no muy lejos del Canada-FranceHawaii Telescope. Es uno de los telescopios más grandes del mundo.
El sistema de control del Telescopio Subaru llamado STS, o Subaru Telemetry Server
system, tiene como objetivo monitorizar los sensores y sistemas crı́ticos del observatorio.
14
Es de desarrollo interno.
Sus principales funcionalidades son las siguientes:
Monitorizar más de 700 sensores con una frecuencia que varı́a entre 1 y 5 minutos
(dependiendo del sensor).
Guardar todos los valores en bases de datos históricas.
Proveer gráficos para cualquier sensor.
Dar soporte a alarmas por correo electrónico, SMS y voz (sintetizada) por teléfono.
Aún ası́, el sistema STS no toma decisiones como cerrar la cúpula de manera automática. Siempre hay operadores para llevar a cabo este tipo de tareas.
Las alarmas se pueden definir de manera dinámica a través de un portal web, desarrollado en un lenguaje similar a PHP. Cada alarma está asociada a un sensor en concreto. Se
puede definir el valor umbral que dispara la alarma, ası́ como el número de veces que se
tiene que dar la condición antes de disparar la alarma. Esta última funcionalidad tiene un
interés doble: descartar falsas alarmas disparadas por sensores muy sensibles y prevenir
algún problema antes de que suceda (por ejemplo, configurando una primera alarma con
un umbral inferior al que corresponde a una situación problemática y utilizar el parámetro
de ocurrencias consecutivas).
No se puede combinar varios sensores para definir una única alarma.
Las acciones que se pueden llevar a cabo cuando se dispara una alarma son las siguientes: correo electrónico, SMS y llamada telefónica. Además se pueden consultar en
el portal web. Sólo el correo electrónico y las llamadas por teléfono se consideran como
un método fiable al 100 % para transmitir alarmas. Por ejemplo, la persona llamada puede
teclear un código en su teléfono para confirmar al sistema la recepción de la alarma (y
que va a actuar en consecuencia). El mayor problema con los mensajes SMS es que su
entrega no está garantizada en un intervalo de tiempo concreto (en casos extremos se han
visto retrasos de 48 horas en la recepción de un SMS).
La figura 2.5 es una captura de pantalla del sistema STS, cortesı́a de David Cook,
responsable del sistema STS. Ilustra la configuración de una alarma asociada a un sensor
en concreto.
2.2.1.6.
Observatorio robótico STELLA
El observatorio robótico STELLA [5] está compuesto por dos telescopios robóticos
(STELLA-I y STELLA-II), operando sin necesidad de intervención humana ninguna. El
observatorio es un proyecto del Astrophysikalisches Institut Potsdam (AIP)9 y cuenta con
la colaboración del Instituto de Astrofı́sica de Canarias (IAC). Está ubicado en el Teide,
en Tenerife (Canarias).
El funcionamiento del observatorio es enteramente automatizado. Los dos techos deslizantes se abren a las horas previstas de observación, si las condiciones meteorológicas
lo permiten y se cierran al final de la observación o si las condiciones meteorológicas
9
Instituto de Astrofı́sica de Potsdam.
15
Figura 2.5: Configuración de una alarma en STS (autor: David Cook)
empeoran. La estación meteorológica tiene la particularidad de tener dos ejemplares de
cada tipo de sensor, en caso de que falle uno. Los datos se leen cada segundo, y se almacenan en base de datos cada cinco minutos. El software de control, desarrollado por
el AIP, está programado en Java. Los lı́mites definiendo las alarmas se pueden configurar
mediante ficheros de configuración. Además de cerrar los techos, el sistema puede mandar
correos electrónicos cuando se dispara una alarma.
Más documentación acerca del observatorio robótico STELLA se puede encontrar en
la página del observatorio [4].
2.2.2.
Soluciones software disponibles
En esta sección, se estudian las soluciones software disponibles que permiten responder al menos en parte a la problemática de la gestión de alarmas para un observatorio
astronómico. En el apartado 2.2.2.1, se presenta la solución actualmente utilizada en el
Observatorio Astronómico de Montegancedo, ası́ como sus limitaciones. En el apartado
2.2.2.2, se presenta brevemente el framework Alma Common Software utilizado en el
ámbito astronómico. Por fin, en el apartado 2.2.2.3 se presentan las soluciones disponibles parar solucionar un subproblema de la gestión de alarmas, el encadenamiento hacia
adelante de reglas lógicas.
16
2.2.2.1.
wview
wview[66] es el software que gestiona actualmente la estación meteorológica de la
facultad [14]. A parte de las funciones de recolectar, almacenar y publicar los datos meteorológicos de la estación, incluye un gestor de alarmas (wvalarmd). Su funcionamiento
es sencillo por no decir rudimentario: se especifica en un fichero de configuración de texto
plano cada variable que se quiere monitorizar, un valor de umbral, y la ruta hacia un script
que se ejecutará cuando el valor de la variable monitorizada supere (o pase por debajo de
según el caso) el valor umbral. Un ejemplo de dicho fichero de configuración se incluye
en el listado 1.
wview tiene, en cuanto a los objetivos fijados, las siguientes limitaciones:
No es nada flexible, dado que cada cambio de configuración implica cambiar el
fichero de configuración y reiniciar el software.
No se pueden combinar variables distintas (cada una tiene un umbral y un script
asociado).
No permite la integración de otras fuentes de variables.
Las acciones a realizar se tienen que programar mediante scripts.
# Alarm Definitions
# ----------------#
#
Column Format
#
#
1) Alarm Type - see the README file for valid types
#
2) Is a Maximum - 0 => lower bound alarm, 1 => an upper bound alarm
#
3) Bound Value - upper/lower bound value (threshold) (float or integer)
#
4) Abatement - number of seconds to suppress alarms after an alarm triggers
#
5) Alarm Script - full path to the shell script or binary to execute when
#
the alarm triggers
#
## ALARM TYPE
## -----------------#OutsideTemp
#OutsideTemp
MAX?
---0
1
THRESHOLD
ABATEMENT
SCRIPT
--------------------------------------32
900
/usr/local/etc/wview/alarms/outtempMin.sh
5
10
/usr/local/etc/wview/alarms/outtempMax.sh
Listado 1: Ejemplo de fichero de configuración de wview alarms
Sin embargo, cabe destacar que el análisis del funcionamiento del gestor de alarmas de
wview, ayudó en la fase de toma de requisitos del sistema Ciclope Alarms. Por ejemplo,
se reutilizó la posibilidad de definir periodos de inhibición (factor abatement en wview)
entre dos activaciones sucesivas de alarma.
2.2.2.2.
ACS
Alma Common Software [20] es un proyecto de software libre, publicado bajo licencia
GNU LGPL cuyos miembros más activos son el ESO (European Southern Observatory)
17
Figura 2.6: Estructura de ACS (fuente: documentación de ACS [11])
y el CERN. Vio la luz a raı́z del proyecto ALMA, Atacama Large Millimeter Array, proyecto astronómico de cooperación internacional (Europa, EEUU, Canada, Japón, . . . ): un
interferómetro compuesto por unas 64 antenas, ubicadas en el desierto chileno de Atacama.
ACS proporciona una infraestructura software común, basada en CORBA, destinada
a unificar los procedimientos de control y monitorización entre dispositivos hardware y
software (muy numerosos) del observatorio, a la vez que abstrayendo los protocolos de
comunicación subyacentes. La figura 2.6 ilustra la arquitectura de ACS.
ACS consta de un sistema de alarmas, gracias a la contribución del CERN y heredado
del LHC (Large Hadron Collider). Desgraciadamente, además de tener una complejidad
abrumadora, éste no responde a las exigencias del gestor de alarmas que se quiere implementar en el marco de este proyecto fin de carrera. En efecto, el sistema de alarmas
del ACS está enfocado a la monitorización de componentes separados, i.e. un poco como
el STS del Subaru Telescope expuesto en el apartado 2.5, y no permite combinar varios
sensores en la definición de una misma alarma. Además, supone la instalación de todo el
framework ACS.
2.2.2.3.
Motores de inferencia
En una fase temprana de la realización de este proyecto, apareció claro que el sistema Ciclope Alarms debiera ser capaz de, por un lado leer los datos correspondientes a
las variables monitorizadas (meteorológicas en un principio al menos) y en base a estas
lecturas, comprobar si las alarmas definidas se tienen que disparar parar llevar a cabo las
acciones asociadas. En otros términos, tiene que actuar como un motor de inferencia lógica. Llegado a este punto, quedó bastante obvio de que soluciones software a esta clase
de problema existı́an ya y que ignorarlas para desarrollar todo desde cero habrı́a sido una
mala opción, llevando al autor a reinventar la rueda. Ası́ que una buena parte del estudio
del arte detallado en este capı́tulo fue dedicado al estudio de los motores de reglas exis18
tentes, basados en software libre, y más particularmente del sistema elegido finalmente,
Drools.
En el párrafo 2.2.2.3.1, se mencionan brevemente los motores de inferencia estudiados, y los criterios que han llevado a la decisión final, antes de centrarnos en ésta, en el
párrafo 2.2.2.3.2.
2.2.2.3.1. Motores de inferencia/reglas (Rule Engines) Los motores de inferencia
que se han considerado son los siguientes:
Mandarax[42].
CLIPS[60].
JESS[41].
Hammurapi Rules[33].
Open Rules[55].
Drools[40].
JESS, a pesar de ser bastante utilizado fue descartado rápidamente por no ser de código abierto. CLIPS fue descartado por no utilizar Java. Mandarax, publicado bajo la licencia LGPL, no acabó siendo muy adecuado para este proyecto al proporcionar encadenamiento hacia atrás y no hacia adelante.
Open Rules entra una categorı́a llamada BRMS (Business Rules Management Systems) y su enfoque es claramente de utilización en empresas (reglas utilizando MS Excel,
. . . ) por lo que no convenció demasiado tampoco.
Hammurapi Rules era una opción viable pero resultó ser menos completa (por lo tanto
implicando más desarrollo de software), y con menor utilización que Drools.
Por fin Drools, a veces denominado JBoss Rules, pareció una buena opción por las
razones siguientes:
Código abierto (licencia ASL i.e. Apache).
Integración con Java.
Proyecto Open Source muy activo.
Comunidad de usuarios importante.
Algoritmo de encadenamiento hacia adelante optimizado (ReteOO).
19
Figura 2.7: Logotipo de Drools (fuente: documentación de Drools [39])
Figura 2.8: Esquema de un motor de reglas (fuente: documentación de Drools [37])
2.2.2.3.2. Drools La parte central de un sistema de reglas como Drools es el motor de
inferencia capaz de procesar un extenso conjunto de reglas y hechos. La figura 2.8 ilustra
la estructura tı́pica de un motor de inferencia. El motor de inferencia compara los hechos
observados con las reglas definidas para inferir conclusiones, las cuales desencadenan
acciones. Una regla tiene dos partes y utiliza Lógica de Primer Orden en cuanto a la
representación del conocimiento.
El proceso de comparar los hechos nuevos o existentes con las reglas definidas se
llama ’Pattern Matching’ y es responsabilidad del Motor de inferencia (Inference Engine).
Varios algoritmos son capaces de solucionar esta clase de problema lógica, dentro de los
cuales encontramos:
Linear (e.g. Uni-Rete).
Rete [22].
Treat[44, 45].
Leaps[46].
Drools implementa y extiende el algoritmo Rete [22, 23]. Su implementación se denomina ReteOO para subrayar el hecho de que está optimizada para sistemas orientados a
objetos. Cabe destacar que existen extensiones propietarias (no publicadas) del algoritmo
20
Rete, implementadas en motores de reglas de código cerrado. Por razones obvias, no se
detallarán aquı́. Varias de las alternativas a Drools estudiadas en la sección precedente
también implementan el algoritmo Rete.
Las reglas se almacenan en la memoria de producción (Production Memory) y los
hechos en la Memoria de Trabajo (Working Memory).
El algoritmo RETE es obra del Doctor Charles Forgy y fue publicado en su tesis
doctoral en 1978-79. [22]. La palabra RETE viene del latı́n y significa red. El algoritmo
RETE tiene dos partes: compilación de reglas y ejecución.
El algoritmo de compilación describe como las reglas definidas en la Memoria de
Producción pueden generar una red de discriminación eficaz. En términos no técnicos,
una red de discriminación se usa para filtrar los datos. La idea es filtrar los datos según se
vayan propagando en la red.
El lector interesado en los pormenores del algoritmo podrá referirse al manual de
Drools[38] o por supuesto a las publicaciones de su autor, el Dr Charles Forgy[22, 23].
Sin embargo, querrı́a resaltar aquı́ que tanto el algoritmo inicial como su implementación ReteOO incluyen optimizaciones en el proceso de encadenamiento lógico, tales
como por ejemplo sistemas de caches, indexación de los resultados, permitiendo que el
sistema gane en eficacia y escalabilidad, dado que no tiene que evaluar siempre las condiciones lógicas en su totalidad (en pocas palabras, se comparten entre reglas similares los
resultados de la evaluación de condiciones lógicas idénticas. . . ).
Para ilustrar lo anterior, se puede hacer la prueba siguiente: elaborar un conjunto sencillo de reglas lógicas, similares a las que se definirán en Ciclope Alarms (i.e. basadas en
variables meteorológicas) y visualizar, gracias al plugin de Drools para Eclipse la red que
el motor de inferencia de Drools construye.
El conjunto de reglas utilizadas para la prueba es el siguiente:
#created on: 24 mai 2009
package org.ciclope
import org.ciclope.alarms.engine.Archive;
import org.ciclope.alarms.engine.actions.TriggerEngine;
rule
when
then
end
rule
when
then
end
"2"
$archive:Archive(windSpeed>12.0)
TriggerEngine.triggerAlarm(2,$archive);
"3"
$archive:Archive(windSpeed>12.0)
TriggerEngine.triggerAlarm(3,$archive);
rule "10"
when $archive:Archive(windSpeed>12.0 && (barometer>1000 || windSpeed>12.0) || inTemp>20.0)
then TriggerEngine.triggerAlarm(10,$archive);
end
rule "11"
when $archive:Archive(inTemp>20.0 ||windSpeed>12.0 )
then TriggerEngine.triggerAlarm(11,$archive);
end
La red construida por el motor de inferencias de Drools se encuentra en la figura 2.9.
Los cı́rculos azules representan la evaluación de una condición lógica simple e.g. windSpeed > 12.0 (2). Los cı́rculos amarillos representan la evaluación de la condición lógica
21
Figura 2.9: Red de reglas sintetizada por el plugin Drools para Eclipse
completa de una regla. Por fin los cı́rculos negros representan las acciones. Determinadas condiciones lógicas simples como windSpeed > 12.0 aparecen en varias reglas. Aún
ası́ solo tenemos un cı́rculo azul, significando que la evaluación sólo se hará una vez y
se guardará en memoria para utilización en otras reglas. De la misma manera, las reglas
2 y 3 tienen la misma condición global o sea que ’comparten’ el mismo cı́rculo amarillo, que apunta a dos acciones (cı́rculos negros) distintos. La optimización conseguida es
apreciable dado que un algoritmo menos refinado (que recorriese las reglas una por una
y evaluara todas las condiciones una y otra vez) tendrı́a que evaluar 8 condiciones lógicas simples y 4 combinaciones. Con ReteOO, bajamos a la evaluación de 3 condiciones
lógicas y 3 combinaciones.
22
2.3.
Conclusiones
Esta fase previa a la elaboración del proyecto fin de carrera que constituye el estudio
del estado del arte ha tenido varios beneficios.
Primero, el estudio del estado del arte en temas de publicación de datos meteorológicos, expuesto en la sección 2.1, ha permitido aclarar los conceptos teóricos necesarios a la
resolución del primer objetivo planteado en este proyecto fin de carrera y cuya realización
está expuesta en el capı́tulo 3.
Segundo, el estudio de las soluciones realmente implementadas en observatorios astronómicos ha tenido un tremendo interés. Se ha visto que las soluciones adoptadas difieren mucho de un observatorio a otro, dependiendo de las exigencias de automatización, o
flexibilidad requeridas. La mayorı́a de ellos utilizan soluciones software desarrolladas en
interno. Aún ası́, algunos promueven la reutilización de software, utilizando frameworks
de código abierto como INDI [47], IRC [48], o ACS [20]. Si bien estos frameworks pueden tener un interés para el Observatorio Astronómico de Montegancedo, no solucionan
de manera satisfactoria la gestión de alarmas que se quiere implementar.
Por fin, el estudio del estado del arte sobre motores de inferencia, ha hecho posible la
elección de un componente software (Drools) permitiendo solucionar parte del problema
de la gestión de alarmas, el encadenamiento hacia adelante de reglas lógicas.
23
24
Capı́tulo 3
Publicar datos meteorológicos en
Internet
En este capı́tulo, se expone el trabajo realizado en el marco de este proyecto fin de
carrera para realizar el primer objetivo planteado en el capı́tulo 1, publicar los datos de la
estación meteorológica del Observatorio Astronómico Montegancedo para que los mismos sean accesibles para el mayor número de personas posibles.
Se ha visto en la sección 2.1 que para que la información meteorológica llegue al
mayor número posible de usuarios finales, dicha información tiene que transitar por las
redes de información meteorológica asentadas.
A lo largo del capı́tulo se detallan los pasos que han sido necesarios para poder publicar datos meteorológicos en las redes siguientes:
Awekas[7].
CWOP[52].
Personal Weather Stations[57]:
• Weather For You[69].
• Hamweather[34].
Weather Underground[70].
Para cada red, los pasos seguidos siguen un patrón común. Se pueden dividir en tres
pasos:
1. Dar de alta la estación en el servicio / Obtener un ID (opcional).
2. Configurar el software de la estación para el servicio.
3. Comprobar el buen funcionamiento / Hacer modificaciones en la configuración del
servicio.
25
Cabe destacar que este capı́tulo ha sido redactado con la intención de ser lo más reutilizable posible, en el sentido de que pueda servir de guı́a para cualquier persona u
organización deseando publicar los datos de una estación meteorológica. Por este motivo, siempre y cuando ha sido posible, las explicaciones son genéricas y deberı́an de poder
aplicarse en cualquier caso. Los pasos 1 y 3 no dependen ni del tipo de estación ni del software utilizado. Sin embargo, la realización del segundo paso depende altamente de ambos
componentes por lo cual las explicaciones acerca de este paso sólo se aplican al caso de
una estación Davis Vantage Pro 2 [18], operada con el software wview[66], combinación
utilizada en el Observatorio Astronómico Montegancedo.
3.1.
Localización de la estación
Antes de entrar en los detalles del proceso de alta de cada servicio en concreto, conviene hacer un breve repaso sobre coordenadas geográficas. En efecto, todos los servicios
detallados a continuación necesitan las coordenadas geográficas de la estación meteorológica bien sea durante el propio proceso de alta bien sea más tarde durante la configuración de la estación. Dichas coordenadas incluyen:
Latitud.
Longitud.
Altitud.
Unas coordenadas geográficas solo tienen sentido en el contexto de un sistema geodésico concreto (llamado también datum) ya que es éste quien define rigurosamente las referencias necesarias para poder medirlas. En todo el resto del documento, salvo mención explicita del contrario, las coordenadas geográficas se referirán al sistema geodésico
WGS84[67]. Se trata del único sistema geodésico funcionando a nivel global (i.e. toda
la Tierra) y es un estándar de facto (existen y se utilizan muchos otros, pero a niveles
nacionales o continentales1 ). El sistema GPS lo utiliza.
3.1.1.
Latitud
La latitud es un ángulo expresando la posición norte-sur de un punto en la Tierra.
Toma valores entre 0°(en el Ecuador) y 90°(en cualquiera de los Polos). Para diferenciar
los hemisferios, se debe añadir la letra N para Norte (North) o S para Sur (South) o el
signo + para Norte o - para Sur. Una notación correcta será entonces -34°o 34°S. Cabe
destacar que se puede encontrar la notación, redundante, -34°S.
3.1.2.
Longitud
La longitud es un ángulo expresando la posición este-oeste de un punto en la Tierra, calculada desde el meridiano de Greenwich (llamado a veces meridiano cero). Toma
1
En España, se utiliza por ejemplo el datum europeo ED50.
26
Figura 3.1: Latitud y longitud (autor: José Alberto Bermúdez y el Instituto Superior de
Formación y Recursos en Red para el Profesorado [8])
valores entre 0°(en el meridiano de Greenwich) y 180°. Para poder diferenciar un punto
localizado al este del meridiano de Greenwich con otro localizado al oeste del meridiano
de Greenwich, se debe añadir la letra E para Este (East), W para Oeste (West) o el signo
+ para Este, - para Oeste. Una notación correcta será entonces -175°o 175°W. Cabe destacar que se puede encontrar la notación, redundante, -175°W. La figura 3.1 ilustra los
conceptos de latitud y longitud.
3.1.3.
Altitud
La altitud es la elevación vertical de un punto respecto a una referencia dada. En nuestro caso, la referencia será el nivel del mar (medio)2 . Esta medida puede ser positiva o
negativa según el caso. El cálculo preciso de la altitud queda fuera del ámbito de este
documento. Sin embargo, no se suele necesitar un nivel de precisión muy alto para estaciones meteorológicas. Uno de los aspectos más relevantes de la altitud en cuanto a
estaciones meteorológicas es que tiene cierta influencia sobre la presión atmosférica. A
bajas altitudes (menos de cuatro kilómetros o sea cualquier lugar habitable) la presión
disminuye en 1,25 mbar cada 10 metros.[59] Sabiendo que una medición normal ronda
los 1000 mbar (i.e. una atmósfera), una diferencia de 100 metros induce una deferencia
relativa de presión del orden del 1 %. . . En la sección 3.1.5, se verá algunas técnicas para
medir o inferir la altitud de una estación meteorológica con una precisión razonable.
2
En España, la referencia es Alicante.
27
3.1.4.
Tipos de unidades para coordenadas y conversiones
Si la definición de latitud, longitud o altitud plantea poca ambigüedad 3 , el sistema de
unidades utilizado para expresar dichas coordenadas puede variar de un servicio meteorológico a otro lo cual puede llevar a confusiones y pequeños desajustes. Se detallan a
continuación los sistemas de unidades más utilizados ası́ como técnicas para llevar a cabo
conversiones.
Existen tres tipos de unidades en los cuales se pueden expresar la longitud y la latitud:
DMS o Grados Minutos Segundos (Degree Minutes Seconds en inglés). Se trata
de un sistema sexagesimal i.e. 1 grado corresponde a 60 minutos, 1 minuto a 60
segundos, e.g. 40º24’23”N - 3º50’19”W.
DD o Grados decimales (Decimal Degrees) e.g. 40.4061N - 3.8383W (recordad
que el punto suele servir de coma en los sistemas anglosajones). Cabe destacar que
Google Maps (y Google Earth) utiliza éste.
Formato LORAN: es un hı́brido de los sistemas anteriores. Las coordenadas LORAN especifican grados y minutos decimales i.e. 1 grado corresponde a 60 minutos, y los minutos pueden venir con una parte decimal (en vez de los segundos del
sistema DMS) e.g. 40°24.38N - 3°50.32W.
Para hacer conversiones rápidas y fiables entre DMS, DD y formato LORAN, se recomienda el uso de la siguiente página: http://www.directionsmag.com/latlong.php
Existen dos tipos de unidad para expresar la altitud: los metros (sistema SI) y los pies
o feet (sistema imperial - US). La conversión es fácil,
1f t = 0, 3048m
1m = 3, 2808f t
Existen muchas páginas web capaces de realizar este tipo de conversión. Por ejemplo,
buscar en Google la frase ’xx metros en pies’ da el resultado de la conversión automáticamente [29].
3.1.5.
Técnicas para obtener coordenadas geográficas
Para obtener las coordenadas geográficas de un punto, existen varias técnicas que
podemos dividir en dos tipos:
Medición directa.
Servicios de localización en Internet.
Cabe destacar que dentro del ámbito de este documento, sólo se pretende exponer
brevemente algunas técnicas permitiendo obtener, de manera práctica y con un grado de
precisión razonable, las coordenadas geográficas de una estación meteorológica y no hacer un estudio exhaustivo sobre geolocalización. El lector interesado podrá encontrar más
información sobre geodesia en los siguientes artı́culos de la NGA[50] o, en castellano, en
las páginas del IGN, especialmente en su glosario cartográfico[36].
3
Al menos, para el nivel de precisión requerido en este campo.
28
Medición directa
Para medir directamente coordenadas geográficas, se puede utilizar un receptor GPS.
Dado la variedad de receptores disponibles en el mercado, es imprescindible referirse a la
documentación del receptor utilizado para conseguir mediciones de buena calidad. Según
el modelo, puede hacer falta añadir a la medición de la altura un factor correctivo que
se puede calcular en la URL: http://earth-info.nga.mil/GandG/wgs84/gravitymod/egm96/
intpt.html[51]. Algunos receptores incluyen dicha corrección.
La precisión de los receptores GPS ha ido incrementando con el tiempo4 . Se puede,
en algunos casos, conseguir una precisión del orden de 20 metros o hasta 2 metros utilizando GPS diferenciales (DGPS). Cabe destacar que la precisión vertical (medición de
altitud) siempre es peor que la precisión horizontal en un factor 2 aproximadamente (por
puras razones matemáticas). En caso de que dicha precisión sea peor que 10 metros, se
recomienda el uso de un altı́metro (bien calibrado). Algunos modelos de estación meteorológica incluyen un altı́metro.
Servicios de Internet
Para determinar coordenadas sin tener el material mencionado previamente se puede
utilizar los servicios siguientes:
Para latitud/longitud:
• Google Earth / Google Maps.
• http://mapper.acme.com/.
Para altitud:
• Google Earth / Google Maps.
• http://www.earthtools.org/height/[latitud en DD]/[longitud en DD].
• http://seamless.usgs.gov/Website/Seamless/viewer.htm.
• Mapas del IGN: http://www.ign.es.
3.2.
Awekas
Awekas es un acrónimo para Automatisches WEtterKArten System o Sistema automático de mapas meteorológicos. Como su nombre indica, este sistema genera mapas
a partir de la información proporcionadas por estaciones meteorológicas. A contrario de
otros servicios de este tipo (como los detallados a continuación), no es la estación meteorológica que manda los datos sino el propio sistema Awekas que recoge los datos
generados por la estación. Para conseguir eso, la estación tiene que generar un fichero
conteniendo los datos meteorológicos y guardarlo en un lugar accesible desde Internet (en
una página web). Ası́ Awekas podrá, periódicamente recuperar dicho fichero y utilizar la
4
Sobretodo desde que E.E.U.U. desactivó la Selective availability[73].
29
Figura 3.2: Dar de alta una estación en Awekas
información. Cabe destacar que este proceso de generación de ficheros está soportado por
wview por lo que solo hace falta darse de alta en la página de Awekas y activar/configurar
este servicio en wview, como viene detallado a continuación.
3.2.1.
Darse de alta
La página para dar de alta una nueva estación está en el menú Community y dentro
de ello, en el submenú Register new. La URL directa es la siguiente: http://www.awekas.
at/en/benutzer.php?mode=new. Se incluye, en la figura 3.2, una captura de pantalla del
formulario que contiene.
A continuación, se proporcionan algunas recomendaciones para rellenar los datos que
hacen falta:
Desactivar el campo Email Public (cuidado está activado por defecto).
Longitud y latitud: en formato DMS.
Date format: YYYYMMDD (si se utiliza wview).
30
Localization: es el nombre bajo el cual aparecerá la estación.
Report mode: seleccionar wview.
Path to the data file: URL donde Awekas podrá recoger el fichero de datos generados
por wview (u otro). En principio será url base/awekas wl donde la url base es la
URL donde se publican los datos de la estación.
Después de salvar los datos, un correo electrónico será mandado a la dirección de
correo proporcionada. Dicho correo electrónico contiene un código de activación. Este
código se tiene que introducir en un formulario web que se puede encontrar aquı́: http:
//www.awekas.at/en/freischaltung.php.
3.2.2.
Configurar wview
En el caso de Awekas, se puede empezar por esta etapa en vez de la etapa de alta. Con
wview, los pasos a seguir son los siguientes:
Copiar el fichero template apropiado (suele estar en /etc/wview/html).
cp [ruta_wview]/etc/wview/html/awekas_wl.htx-metric [ruta_wview]/etc/wview/html/
awekas_wl.htx
Añadir (o descomentar si ya existe) este fragmento en el fichero de configuración
html-templates.conf.
######################################
### AWEKAS Data Submission Template
######################################
awekas_wl.htx
Rearrancar wview.
[ruta_ejecutable_wview]/wview restart
3.2.3.
Comprobar el buen funcionamiento
Antes de todo se recomienda comprobar lo siguiente:
Los ficheros destinados a Awekas se generan bien. Para eso, basta probar la URL
rellenada en el campo Path to the data file de la página de configuración de Awekas.
Awekas es capaz de recuperarlos y no ve ningún problema en cuanto a la forma.
Para eso, en la página de Datos del usuario[6], se debe pulsar el botón Test Datafile.
Si todo está bien, los datos tendrı́an que aparecer en Awekas. Simplemente hay que recordar que es Awekas quien decide cuando recoger los ficheros generados por la estación
por lo que puede tardar en aparecer los primeros datos. Los datos recuperados en Awekas
se pueden consultar en varios sitios:
31
Figura 3.3: Mapa de España en Awekas
Mapa (en el menú Community, Member Map) e.g. para España http://www.awekas.
at/en/mitgliederkarte.php?nid=8. Véase la figura 3.3.
Página resumen datos de la estación e.g. http://www.awekas.at/en/instrument.php?
id=4936.
En Google Earth[30] utilizando uno de los ficheros proporcionados por Awekas,
disponibles en la URL: http://www.awekas.at/forum/viewtopic.php?t=2650. Véase
la figura 3.4.
Otro enlace interesante es la página de comprobación de calidad de los datos: http:
//www.awekas.at/en/qualcheck.php?id=4936. Allı́ comparan los datos de una estación con
los datos recibidos de otras estaciones del vecindario. Desde la página de la estación se
puede acceder pulsando el botón to quality checking system.
3.2.4.
Cambiar la configuración a posteriori
La página para cambiar los datos de una estación ya registrada está en el menú Community y dentro de ello, en el submenú Change user data. Se pedirá el nombre de usuario
y la contraseña previamente escogida. La URL directa es la siguiente:http://www.awekas.
at/en/benutzer.php Se puede cambiar cualquier parámetro sin problema (incluso nombre
de usuario, dirección de correo electrónico, contraseña, etc. . . )
32
Figura 3.4: Red Awekas en Google Earth
33
Figura 3.5: Petición de un Call Sign id para CWOP
3.3.
CWOP
CWOP es el acrónimo para Citizen Weather Observer Program i.e. el Programa de
Observación Meteorológica Ciudadano. Su página se puede encontrar en la URL: http:
//www.wxqa.com/.
Se trata de un servicio meteorológico al cual cualquier persona con una estación meteorológica y el software adecuado puede publicar los datos meteorológicos colectado por
dicha estación. Los datos son a continuación accesibles libremente. La NOAA (National
Oceanographic and Atmospheric Administration)[53] por ejemplo explota datos almacenados por el programa CWOP para elaborar previsiones meteorológicas (entre otras
cosas).
Para participar en el programa CWOP, se necesita un id llamado APRS Call Sign.
(Véase sección 3.3.1). Una vez conseguido ese id, hace falta configurar wview adecuadamente (véase sección 3.3.2). Una vez hecho eso, wview mandará datos a los servidores de
CWOP cada vez que se genere un nuevo archivo de datos (o casi, ver Sección 3.3.2 para
más detalles).
3.3.1.
Darse de alta
Para conseguir un Call Sign id, hay que rellenar un formulario en la página siguiente:
http://www.findu.com/citizenweather/signup.html. Es bastante simple (se piden bastante
pocos datos, ya que los datos esenciales como coordenadas geográficas están mandados
por wview en cada paquete de datos). Se incluye, en la figura 3.5, una captura de pantalla
del formulario de petición del Call Sign id.
La asignación de un Call Sign id es inmediata (no necesita activación por correo
electrónico como por Awekas). Deberı́a de tener el formato CW#### o DW### donde
los # son dı́gitos. Ya se puede configurar wview adecuadamente.
34
3.3.2.
Configurar wview
Para configurar adecuadamente wview 5 , se necesita los datos (nombres y puertos)
de los servidores de CWOP a los cuales wview intentará mandar los datos. Se tienen
que configurar tres servidores por si acaso el primero no responda y se pueda mandar
los datos a otro. Los datos de estos servidores se pueden encontrar en la página http:
//www.wxqa.com/activecwd.html.
En principio son los siguientes (pero podrı́an cambiar en un futuro ası́ que se recomienda comprobar en la página previamente mencionada):
1. cwop1.tamu.edu.
2. cwop.fuller.net.
3. sip.tssg.org.
Para todos el puerto es 23.
Hace también falta tener las coordenadas geográficas de la estación en formato LORAN, tal y como se ha explicado en la sección 3.1.4. Cuidado: los grados tienen dos
dı́gitos para la latitud (ángulo entre 0 y 90 grados) y tres para la longitud (ángulo entre 0
y 180 grados). Los ceros también se tienen que poner (e.g. 02012.44E para la longitud).
Hace falta tener un cuidado especial con este punto dado que wview no realiza ningún
tipo de comprobación sobre el formato de las coordenadas (i.e. es la responsabilidad del
usuario de entrarlas correctamente).
Una vez comprobados estos datos y teniendo el CWOP Call Sign Id, se puede configurar wview.
/usr/local/bin/wviewconfig
[just hit return to keep your current settings when prompted]
> Enable CWOP (Citizen Weather Observer Program) support?"
> (0):
Hace falta contestar 1 a esta pregunta para activar CWOP. El script pide los datos de
los servidores CWOP, pues la longitud/latitud en formato LORAN. Una vez haya acabado
el script, se puede reiniciar wview:
[ruta_script_wview]/wview restart
wview manda los datos según las instrucciones de CWOP[54]: ‘Any packet rate that
you are comfortable with is fine with us as long as it is not faster than one data packet
every 9 or 10 minutes. (. . . ) We recommend that you set your software so that the first
packet of the hour is sent in the minute that matches the last number in your CW ID or
ham callsign.’ En concreto, wview manda los datos a CWOP con una frecuencia igual
a la frecuencia de generación de archivos meteorológicos. Si se generan archivos más a
menudo que cada 10 minutos (e.g. cada 5 minutos), wview los enviará con una frecuencia
de 10 minutos. Encima, wview procura, tal y como CWOP recomienda, no mandar los
datos a minutos redondos para evitar sobrecargar los servidores de CWOP. Para eso, tiene
en cuenta el último dı́gito del Call Sign id. Por ejemplo, con un id DW2192, los datos se
mandarán a las 10:02, 10:12, 10:22. . .
5
Más detalles en el manual de wview [65].
35
Figura 3.6: Datos de una estación meteorológica en CWOP
3.3.3.
Para comprobar que los datos se mandan bien, se pueden utilizar las URLS siguientes
(substituir los # por el Call Sign Id):
http://www.findu.com/cgi-bin/wxpage.cgi?call=######.
http://www.findu.com/cgi-bin/find.cgi?call=######.
Por ejemplo,
http://www.findu.com/cgi-bin/wxpage.cgi?call=DW2192, véase la figura 3.6.
http://www.findu.com/cgi-bin/find.cgi?call=DW2192.
En caso de problema, los datos con problema de formato deberı́an aparecer en la
página: http://www.findu.com/cgi-bin/errors.cgi Si es el caso, hace falta comprobar la
configuración de wview, y el formato de los datos enviados. Una página muy útil es la
sección de FAQ de CWOP: http://www.wxqa.com/faq.html
Cuando todo está bien, se puede mandar un correo electrónico de confirmación a los
contactos de CWOP. Se trata de Russell Chadwick: mailto:Russell.B.Chadwick@noaa.
gov.
36
3.3.4.
En caso de cambio de contacto (persona o correo electrónico) o cambio de coordenadas, altitud. . . , hace falta avisar, por correo electrónico, a la persona contacto de CWOP de
los cambios. Se trata también de Russell Chadwick: mailto:Russell.B.Chadwick@noaa.
gov.
3.4.
Weather Underground
Weather Underground[70] es una empresa que proporciona servicios meteorológicos
algunos de los cuales son de pago y otros no. Dentro de los servicios gratuitos, consta la
posibilidad de publicar los datos de una estación meteorológica y acceder a unas cuantas
gráficas realizadas con los datos subidos por las estaciones meteorológicas de la red.
3.4.1.
Darse de alta
Para dar de alta una estación en Weather Underground, hay que:
1. Crear una cuenta de usuario en Weather Underground.
2. Crear una estación meteorológica con este usuario.
Para la primera etapa, hace falta rellenar un formulario en la página siguiente: http://
www.wunderground.com/members/signup.asp. Hace falta activar la cuenta con el código
que mandan automáticamente por correo electrónico (como para Awekas). Para la segunda etapa, hace falta rellenar un formulario en la página siguiente: http://www.wunderground.
com/wxstation/signup.html
Las coordenadas se tienen que poner en formato decimal. En la misma página, viene un widget de Google maps que permite localizar fácilmente la estación (y de paso
comprobar las coordenadas). , como se puede ver en la figura 3.7. La altitud se tiene que
especificar en pies. La generación del ID es inmediata; éste aparece en la página web
después de enviar el formulario completado.
3.4.2.
Configurar wview
Los pasos a seguir son los siguientes:
1. Instalar (si no es el caso ya) la librerı́a libcurl. El nombre exacto del paquete puede depender de la distribución GNU/Linux utilizada. En Ubuntu por ejemplo, se
tratará del paquete libcurl3. El paquete etiquetado dev (e.g. libcurl4-openssl-dev)
también será necesario porque hace falta recompilar wview.
2. Configurar wview para que incluya el soporte HTTP. Hace falta ejecutar los siguientes mandos en la carpeta del código fuente de wview.
./configure [station_enable_str] --enable-http
37
Figura 3.7: Formulario de Weather Underground
Opcionalmente se puede añadir al mando anterior –enable-mysql si se utiliza una
base de datos MySQL
make install
3. Ejecutar el script de configuración wviewconfig.
/usr/local/bin/wviewconfig
[just hit return to keep your current settings when prompted]
> Enable WUNDERGROUND support?
> (0):
Contestar 1 y dar los parámetros relativos a Weather Underground cuando pedidos
4. Rearrancar wview.
[ruta_ejecutable_wview]/wview start
3.4.3.
Se puede comprobar el buen funcionamiento del servicio en la página: http://www.
wunderground.com/weatherstation/WXDailyHistory.asp?ID=## donde hace falta sustituir las # por el código identificador. Véase la figura 3.8
38
Figura 3.8: Datos de una estación meteorológica en Weather Underground
3.4.4.
Modificar la configuración a posteriori
Salvo el nombre del usuario, todo se puede cambiar una vez activada la estación, en la
página: http://www.wunderground.com/wxstation/signup.html Hace faltar pulsar el botón
edit para cambiar la configuración de la estación.
3.5.
Red Personal Weather Stations
En esta sección, se va a detallar el caso de la red de Personal Weather Stations. Se
trata, como Weather Underground tratado en la sección 3.4 de una organización privada
pero tiene la particularidad de ser la asociación de tres organizaciones distintas:
Personal Weather Stations[57].
WeatherForYou[69].
Hamweather[34].
Aunque cada una de las mencionadas empresas tiene sus propios servicios, alojados en
sus respectivas páginas web, se basan en la misma red de estaciones meteorológicas.
39
Figura 3.9: Formulario de PWS
3.5.1.
Darse de alta
El proceso de alta de estación es común para toda la red Personal Weather Stations
/ Weather for you / Hamweather. La configuración y el envı́o de datos también lo es, lo
cual simplifica bastante todo el proceso.
Para dar de alta una estación en la red PWS, hay que:
1. Crear una cuenta de usuario en PWS.
2. Crear una estación meteorológica con este usuario.
Para la primera etapa, hace falta rellenar un formulario en la página siguiente: http://
www.pwsweather.com/register.php Hace falta activar la cuenta con el código que mandan
automáticamente por correo electrónico (como para Awekas). Para la segunda etapa, hace
falta rellenar un formulario en la página siguiente: http://www.pwsweather.com/station.
php. Se incluye, en la figura 3.9, una captura de pantalla del formulario mencionado.
Las coordenadas se tienen que poner en formato decimal. La altitud se tiene que especificar en pies. PWS tiene la originalidad de dejar al usuario escoger su ID (después de
comprobar que no está siendo utilizado).
40
3.5.2.
Configurar wview
Los pasos a seguir son los mismos que para Weather Underground, detallados en la
sección 3.4.2
3.5.3.
Se puede comprobar que los datos se suben bien en las URL siguientes:
Para Personal Weather Stations, http://www.pwsweather.com/obs/##.html. Véase la
figura 3.10.
Para Weather For You, http://www.weatherforyou.com/personal weather stations/
maps/international.php.
Para Hamweather, http://www.hamweather.net/weatherstations/pwsupdate.php?ID=
##.
3.5.4.
Se pueden cambiar todos los detalles de configuración de la estación en la página:
http://www.pwsweather.com/stations/profile/##.html (hay que sustituir las # por el identificador de la estación).
41
Figura 3.10: Datos de una estación meteorológica en PWS
42
Capı́tulo 4
Ciclope Alarms
En este capı́tulo, se detalla el trabajo desarrollado para concebir e implementar el
sistema Ciclope Alarms. Se estructura el presente capı́tulo según las distintas fases del
ciclo de vida de un proyecto de desarrollo software tı́pico: toma de requisitos, diseño,
implementación e integración.
Durante la realización de este Proyecto Fin de Carrera, se siguió un ciclo de vida
por iteraciones cortas validadas por demos, por lo cual las fases mencionadas no fueron
secuenciales sino más bien se complementaron una a otra, permitiendo a veces identificar
problemas en los requisitos o en el diseño y ası́ mejorar la calidad del sistema final. Dicho
ciclo de vida se inspira fuertemente en el ciclo de vida iterativo del Unified Process,
representando gráficamente por la figura 4.1
Sin embargo, para mejorar la legibilidad de la presente memoria, las distintas fases se
presentan secuencialmente.
4.1.
Toma de requisitos
Durante esta fase, necesaria en la concepción y realización de cualquier producto software, se identificaron los requisitos del sistema Ciclope Alarms. La mayor dificultad de
esta fase quizás consistió en priorizar ciertos requisitos y elegir un conjunto de requisitos
final que permitiera la implementación de una primera versión del sistema, consistente,
funcional, y fácilmente extensible. Parte de los requisitos descartados durante este proceso
se pueden encontrar en la sección 7.2.
El producto de esta fase es una Especificación de Requisitos Software, o ERS, redactada según el estándar 830 del IEEE [35]. Se puede encontrar en el anexo C.
Por comodidad, se incluye a continuación un resumen de la misma.
4.1.1.
Propósito general
El sistema Ciclope Alarms tiene como propósito general permitir la creación y la
gestión de alarmas en un observatorio astronómico, utilizando las variables disponibles,
en particular las condiciones meteorológicas. Además de dar soporte a la edición y gestión
de alarmas, el sistema deberá de proporcionar funciones de administración para supervisar
43
Figura 4.1: Ciclo de vida Iterativo - Unified Process (autor: Westerhoff [72])
el sistema de alarmas. Aunque el sistema deba de ser genérico, se tendrá que integrar en
el portal web existente Ciclope Astro.
4.1.2.
Edición de Alarmas
Un usuario del sistema debe poder crear alarmas, y una vez creadas, modificarlas o
suprimirlas. Debe poder especificar las condiciones lógicas de activación de una alarma
en base a las variables disponibles en el sistema. A cada alarma, debe poder asociar una
serie de acciones a ejecutar cuando se den todas las condiciones de la misma. Estas acciones incluyen mandar correos electrónicos, mandar mensajes SMS, y hacer aparecer
un mensaje de advertencia en la interfaz gráfica del sistema. Dicha lista de acciones se
deberá poder ampliar fácilmente.
Un usuario del sistema debe poder suscribirse a alarmas definidas por otros usuarios.
En este caso, no puede cambiar las condiciones de activación de la alarma, pero puede
definir una serie de acciones a realizar, como si hubiera definido la alarma.
Para garantizar un buen funcionamiento del sistema, se deberá incluir un sistema de
permisos, accesible a los administradores, que defina los lı́mites de utilización del sistema
por parte de los usuarios.
4.1.3.
Administración
Un administrador del sistema debe tener acceso en lectura y escritura a todas las alarmas y suscripciones definidas en el sistema. Debe poder efectuar cualquier modificación
sobre las mismas, incluyendo editarlas, suprimirlas, activarlas y desactivarlas.
44
Un administrador del sistema debe poder configurar los lı́mites de utilización del sistema por cada perfil de usuario existente. Además debe poder definir excepciones a los
permisos de perfil para cualquier usuario en concreto.
Un administrador del sistema debe poder monitorizar el funcionamiento del sistema.
Debe poder ejecutar unas acciones como activar o desactivar el sistema.
4.1.4.
Requisitos no funcionales
Además de los requisitos funcionales brevemente descritos en los apartados anteriores, se han incluido unos requisitos no funcionales:
El diseño debe de ser lo suficientemente genérico como para facilitar las siguientes
ampliaciones del sistema: nuevos tipos de acciones, nuevas variables de monitorización, nuevos observatorios a monitorizar.
La solución debe utilizar exclusivamente software libre, compatible con la licencia
GNU GPL [25].
4.2.
Diseño
El diseño del sistema Ciclope Alarms ha hecho uso importante del lenguaje de modelado UML, en particular por su gran capacidad expresiva y su capacidad en plasmar
fácilmente y de manera gráfica las grandes ideas de un diseño.
En esta sección se incluyen los diagramas UML relevantes de la fase de educción de
los requisitos i.e. los diagramas de Casos de Uso, que organizan los requisitos establecidos
en el anexo C. Se incluye también el modelo conceptual que define los conceptos claves
de la lógica de negocio del sistema.
4.2.1.
Casos de Uso
El diagrama de casos de uso de más alto nivel se encuentra en la figura 4.2. A continuación se hace una descripción de los actores involucrados antes de describir brevemente
cada caso de uso, ası́ como sus correspondientes subcasos.
4.2.1.1.
Descripción de los actores
Usuario: Se trata de un usuario cualquiera del sistema. Puede o no ser un administrador, en cuyo caso tendrá acceso a más funcionalidades del sistema. Por la
integración con el portal Ciclope Astro, se tratará de un usuario del mismo portal.
Administrador: Se trata de un superusuario del sistema. Tiene, además de las funciones accesibles a cualquier usuario, acceso a las funciones de administración del
sistema. Tiene el perfil ’admin’ dentro de los perfiles existentes en Ciclope Astro
(’basic’,’demo’, ’advanced’ y ’admin’).
45
Figura 4.2: Modelo de Casos de Uso - Nivel 0
46
Figura 4.3: Caso de Uso Gestionar Alarmas - Nivel 1
Entorno: Es un actor más bien abstracto. Representa el conjunto de condiciones
externas que puede originar la activación de una alarma en el sistema.
Condiciones meteorológicas: Se trata de un caso particular (un subconjunto por
ası́ llamarlo) del actor Entorno previamente descrito. Representa el conjunto de
variables meteorológicas colectadas por la estación meteorológica. En el ámbito de
esta entrega, se tratará del único actor de tipo Entorno.
4.2.1.2.
Descripción de los casos de uso en formato breve
Caso de Uso Gestionar Alarmas: El Usuario gestiona sus alarmas. Sus permisos,
definidos por el administrador en el caso de uso Gestionar Permisos, restringen las
funcionalidades accesibles. El diagrama del caso de uso desglosado se encuentra en
la figura 4.3. Puede abarcar uno de los subcasos siguientes:
• Definir una nueva alarma.
• Editar una alarma. Un caso particular de este subcaso de uso es Activar una
alarma o Desactivar una alarma.
• Suprimir una alarma.
Caso de Uso Gestionar Suscripciones: El Usuario gestiona sus suscripciones. Sus
permisos, definidos por el administrador en el caso de uso Gestionar Permisos,
restringen las funcionalidades accesibles. El diagrama del caso de uso desglosado
se encuentra en la figura 4.4. Puede abarcar uno de los subcasos siguientes:
• Suscribirse a una alarma. Cabe destacar que para lograr este fin, el usuario
necesita poder buscar dentro del conjunto de alarmas accesibles (i.e. públicas),
47
Figura 4.4: Caso de Uso Gestionar Suscripciones - Nivel 1
Figura 4.5: Caso de Uso Administrar Alarmas - Nivel 1
48
lo cual constituye un subcaso incluido.
• Editar una suscripción. Un caso particular de este subcaso de uso es Activar
una suscripción o Desactivar una suscripción.
• Suprimir una suscripción.
Caso de Uso Activar Alarma: El actor principal de este caso de uso es el Entorno
dado que es quien inicia la activación de una alarma cuando se dan las condiciones de activación previamente definidas, en el caso de uso Gestionar Alarmas. El
sistema registra debidamente todas las activaciones. Adicionalmente, si se cumplen
otras condiciones (periodo de inhibición de la alarma, número mı́nimo de activaciones previas), se puede ejecutar la alarma, i.e. ejecutar las acciones asociadas
(subcaso Ejecutar Alarma) ası́ como las acciones asociadas a las suscripciones relativas a la alarma (subcaso Ejecutar suscripción). El usuario puede participar en este
caso de uso si es receptor de una de las acciones (correo electrónico, SMS, popup).
Caso de Uso Administrar Alarmas Usuarios: El Administrador administra las
alarmas de los usuarios. El diagrama desglosado de este caso de uso se encuentra
en la figura 4.5. Cabe destacar que para monitorizar y actuar sobre diversas alarmas, debe de ser capaz de buscar dentro de las alarmas creadas por los usuarios,
filtrando por los criterios de búsqueda que le interesan en un momento dado. Esto
constituye un subcaso incluido llamado Buscar Alarma. Una vez haya encontrado
la o las alarmas que quiere modificar, puede editarlas, suprimirlas, desactivarlas o
reactivarlas.
Caso de Uso Administrar Suscripciones Usuarios: Este caso de uso es el equivalente del precedente, aplicado a las suscripciones.
Caso de Uso Administrar Sistema: El Administrador monitoriza y configura a
nivel global el sistema.
Caso de Uso Gestionar Permisos: El Administrador define las restricciones de
utilización del sistema aplicables a cada perfil de usuario. Puede también definir
excepciones para usuarios en concreto siempre y cuando dicha excepción es más
restrictiva que los permisos asociados al perfil correspondiente.
4.2.2.
Modelo conceptual
El modelo conceptual es útil a la hora de definir precisamente los conceptos que va
a manejar el sistema, ası́ como las relaciones que tienen entre ellos. En el caso de nuestro sistema, los conceptos centrales son sin duda las alarmas y las suscripciones. Otros
conceptos importantes son las condiciones de activación de las mismas, ası́ como las acciones (cada una perteneciendo a un tipo de acción determinado) asociadas. El diagrama
representando el modelo conceptual se puede encontrar en la figura 4.6. Los objetos representado por tres puntos corresponden a probables futuras extensiones del sistema, es
decir, nuevos tipos de variables de monitorización y nuevos tipos de acciones. El lector
interesado en estos temas puede referirse a la sección 4.4.
49
Figura 4.6: Modelo conceptual
50
4.3.
Implementación
4.3.1.
Arquitectura
La arquitectura del sistema, y sus dependencias con sistemas externos, en particular
con el portal web Ciclope Astro se puede representar mediante un diagrama de componentes, en la figura 4.7.
El sistema Ciclope Alarms se puede dividir en dos partes: la interfaz gráfica o GUI, implementada con el framework Google Web Toolkit, y el motor de alarmas, independiente,
incluyendo un motor de inferencia Drools. Ambas partes del sistema están interconectadas para llevar a cabo operaciones especı́ficas mediante el uso de Java RMI (Remote
Method Invocation). Estas operaciones incluyen la comunicación necesaria para monitorizar y operar el motor de alarmas desde la GUI, ası́ como la notificación de alarmas de
tipo popup desde el motor de alarmas hacia la GUI.
La interfaz gráfica es un módulo en el sentido de Google Web Toolkit, por lo cual,
puede funcionar de manera independiente, lo que se denomina en el resto del documento
modo standalone. En el ámbito de este proyecto fin de carrera, este módulo se ha integrado
en el portal Ciclope Astro.
Los demás componentes implicados en el funcionamiento del sistema son el módem
GSM, que el motor de alarmas utiliza para mandar SMS cuando se ejecutan alarmas de
este tipo, un servidor de correo electrónico, que tanto la interfaz gráfica como el motor de
alarmas utilizan, y el flujo RSS producido por la estación meteorológica. Todo el sistema
Ciclope Alarms necesita acceder a la base de datos donde están almacenadas las alarmas
para cumplir sus funciones.
51
Figura 4.7: Arquitectura general
52
4.3.2.
Esquema de la base de datos
El esquema de la base de datos se encuentra en la figura 4.11. Representa exhaustivamente las tablas del sistema Ciclope Alarms y sus columnas, ası́ como las relaciones entre
ellas. Para mejorar la legibilidad del mismo, se proporcionan también otros esquemas representando subconjuntos del modelo de datos. El modelo de permisos está en la figura
4.10, el modelo de alarmas está en la figura 4.8 y el modelo de suscripciones está en la
figura 4.9.
A continuación se incluye una descripción de las tablas, organizada por los subconjuntos previamente mencionados.
4.3.2.1.
Submodelo: Alarmas
El submodelo alarmas se puede encontrar en la figura 4.8. Las tablas que lo constituyen son las siguientes:
ALARMS: Esta tabla almacena la información relativa a las alarmas definidas en
el sistema. Como se puede apreciar en las figuras 4.11 y 4.8, y como era de prever
en un sistema de alarmas, tiene un rol central en el sistema. Cada alarma pertenece
a un usuario, el usuario quien definió la alarma. Esta relación está materializada
por la clave ajena USER con la tabla TBL ASTRO USERS. Cada alarma aplica a
un observatorio en concreto, por lo cual tiene otra clave ajena, ID OBSERVATORY
hacia TBL ASTRO OBSERVATORIES. Las condiciones de activación de una alarma tiene una estructura de árbol y sigue el patrón composite. Un registro de la tabla
ALARMS está relacionado, a través de la clave ajena LOGICAL CONDITION ID,
a la condición lógica raı́z guardada en la tabla COMPOUND CONDITIONS.
COMPOUND CONDITIONS: Esta tabla guarda las condiciones lógicas compuestas de activación de una alarma. Cada condición compuesta tiene una serie de hijos (al mı́nimo uno) que pueden ser compuestos también o simples (SIMPLE CONDITIONS), siguiendo el patrón composite. Cada registro tiene los siguientes
campos:
• LOGICAL OPERATOR: Operador lógico (AND o OR) definiendo la relación
lógica entre las condiciones hijas (compuestas y/o simples).
• IS POSITIVE CONDITION: campo binario. Si toma el valor false, invierte
el sentido lógico de la condición compuesta (NOT).
• ID PARENT: clave enlazando a la condición compuesta padre en la misma
tabla, si la hay. Puede ser NULL si la condición compuesta es la condición
raı́z de una alarma.
SIMPLE CONDITIONS: Esta tabla guarda las condiciones lógicas simples de una
alarma. Cada registro tiene los siguientes campos:
• THRESHOLD: umbral de la condición.
53
• TYPE OF THRESHOLD: uno de los valores siguientes: greater than , lower than, greater equal than, lower equal than, equal, not equal.
• VARIABLE: variable objeto de la condición simple.
• ID PARENT: clave ajena enlazando a la condición compuesta padre en COMPOUND CONDITIONS.
• LOG ALARMS ACTIVATED: Esta tabla guarda el log de las activaciones
de las alarmas del sistema. Cada registro está relacionado con una alarma en
concreto a través de la clave ajena ID ALARM hacia la tabla ALARMS.
• LOG ALARMS EXECUTED: Esta tabla guarda el log de las ejecuciones de
las alarmas del sistema. Cada registro está relacionado con una alarma en
concreto a través de la clave ajena ID ALARM hacia la tabla ALARMS.
• TBL ASTRO OBSERVATORIES: Esta tabla almacena información básica
acerca de los observatorios dados de alta en el sistema. El campo SHORT NAME es un código utilizado en el sistema para identificar el observatorio.
• ACTIONS: Esta tabla almacena la información relativa a las acciones asociadas a una alarma o una suscripción.
Los campos SUBJECT y TEXTUAL DESCRIPTION guardan la información
de personalización de las acciones definida por los usuarios. Por ejemplo,
SUBJECT puede guardar el asunto del correo electrónico que se tiene que
mandar cuando se ejecute la alarma. Cada acción es de un tipo concreto, que
se guarda en el campo TYPE OF ACTION, clave ajena hacia la tabla TYPES OF ACTION.
• TYPES OF ACTION: Esta tabla guarda los distintos tipos de acción disponibles.
• MTM ALARM ACTION: Esta tabla almacena las relaciones entre la tabla de
alarmas y la tabla de acciones.
• MTM USERS ACTIONS: Esta tabla guarda los usuarios receptores una acción.
• MTM USER ROLES ACTIONS: Esta tabla guarda los receptores de tipo perfil de una acción.
• MTM UNREGISTERED USERS ACTIONS: Esta tabla sirve para guardar
receptores anónimos, i.e. correspondiendo a personas no dadas de alta en el
sistema como usuario. Se utiliza el campo genérico CONTACT INFORMATION para guardar según el caso direcciones de correo electrónico o números
de teléfono.
• TBL ASTRO USERS: Esta tabla guarda la información relativa a los usuarios del sistema. Es idéntica a la tabla de usuarios de Ciclope Astro. Sólo se
modificó para añadirle el campo MOBILE PHONE, que permite almacenar
un número de móvil.
54
Figura 4.8: Esquema de la base de datos - Alarmas
55
4.3.2.2.
Submodelo: Suscripciones
El submodelo suscripciones se puede encontrar en la figura 4.9. Las tablas que lo
constituyen son las siguientes:
ALARM SUBSCRIPTIONS : Esta tabla almacena la información relativa a las suscripciones definidas en el sistema. Un registro representa una suscripción. Una suscripción está relacionada con una alarma, a través de la clave ajena ID ALARM.
Una suscripción pertenece a un usuario, por lo que existe una clave ajena hacia
TBL ASTRO USERS.
MTM SUBSCRIPTION ACTION: Esta tabla almacena las relaciones entre la tabla
de suscripciones y la tabla de acciones.
ALARMS: explicada en la sección 4.3.2.1.
TB ASTRO USERS: explicada en la sección 4.3.2.1.
ACTIONS: explicada en la sección 4.3.2.1.
TYPES OF ACTION: explicada en la sección 4.3.2.1.
MTM USERS ACTIONS: explicada en la sección 4.3.2.1.
MTM USER ROLES ACTIONS: explicada en la sección 4.3.2.1.
MTM UNREGISTERED USERS ACTIONS: explicada en la sección 4.3.2.1.
4.3.2.3.
Submodelo: Permisos
El submodelo permisos se puede encontrar en la figura 4.10. Las tablas que lo constituyen son las siguientes:
GENERAL PRIVILEGES: Esta tabla almacena los permisos genérico i.e. no asociados a ningún tipo de acción en concreto para cada perfil de usuario. El campo
TYPE OF GENERAL PRIVILEGE es el nombre del parámetro de perfil y el campo VALUE el valor asociado para el perfil USER ROLE.
GENERAL EXCEPTIONS: Esta tabla guarda las excepciones a los permisos definidos en la tabla GENERAL PRIVILEGES. Cada registro tiene los campos siguientes:
• ID GENERAL PRIVILEGE: clave ajena al permiso definido en la tabla GENERAL PRIVILEGES.
• USER ALIAS: clave ajena al usuario (definido en TBL ASTRO USERS) objeto de la excepción.
• OVERRIDE VALUE: valor del permiso correspondiente.
56
Figura 4.9: Esquema de la base de datos - Suscripciones
ACTION SPECIFIC PRIVILEGES: Esta tabla almacena los permisos asociados a
un tipo de acción en concreto para cada perfil de usuario.
El campo TYPE OF ACTION SPECIFIC PRIVILEGE es el nombre del parámetro de perfil y el campo VALUE el valor asociado para el perfil USER ROLE. La
clave ajena TYPE OF ACTION enlaza al tipo de acción correspondiente (en la tabla TYPES OF ACTION).
ACTION SPECIFIC EXCEPTIONS: Esta tabla guarda las excepciones a los permisos definidos en la tabla ACTION SPECIFIC PRIVILEGES. Su estructura es
similar a la de la tabla GENERAL EXCEPTIONS.
4.3.2.4.
Submodelo: Configuración
Por fin, las siguientes tablas constituyen el submodelo de configuración del sistema.
Se pueden encontrar en la figura 4.11.
BANK HOLIDAYS: Esta tabla guarda, para cada observatorio la lista de los dı́as
festivos i.e. dı́as de cierre del mismo. Cada registro está relacionado con un observatorio en concreto gracias a la clave ajena ID OBSERVATORY hacia la tabla
TBL ASTRO OBSERVATORIES.
WORKING HOURS: Esta tabla almacena, para cada observatorio, las horas de
apertura y cierre del mismo para cada dı́a de la semana. Un registro tiene los siguientes campos:
57
Figura 4.10: Esquema de la base de datos - Permisos
• DAY OF WEEK: dı́a de la semana (e.g. monday).
• TYPE: tipo de horario. Puede tomar los valores closed (cerrado todo el dı́a),
fullTime (abierto todo el dı́a), o PartialTime (abierto parte del dı́a).
• START: hora de apertura. Sólo aplica si TYPE es PartialTime.
• STOP: hora de cierre. Sólo aplica si TYPE es PartialTime.
• ID OBSERVATORY: clave ajena hacia la tabla TBL ASTRO OBSERVATORIES.
58
Figura 4.11: Esquema de la base de datos
59
4.3.3.
Diagrama de Clases
Para mejorar la legibilidad del mismo, no se proporciona un diagrama de clases completo, sino varios diagramas, cada uno representando una parte del sistema. Cabe destacar
que sólo se pretende describir en el presente apartado la capa de lógica de negocio. La
capa de acceso de base de datos (utilizando Ibatis), puramente técnica, es obviada. La capa de acceso a servicios remotos (RPC) de GWT tampoco se detalla aquı́ por las mismas
razones. Por fin todos los componentes puramente gráficos (widgets, panels, y otros componentes de GWT) tampoco se detallan aquı́. Sin embargo, se mencionarán brevemente
en el apartado 4.3.4.
La implementación de la parte central del modelo de lógica del negocio, centrada en
las alarmas se puede representar por el diagrama de clases de la figura 4.12. Este diagrama
de clases presenta semejanzas con el modelo conceptual de la figura 4.6.
Podemos destacar la implementación del patrón de diseño Composite con las clases LogicalExpression, MultipleCondition y SimpleCondition. LogicalExpression es una
clase abstracta representando cualquier tipo de condición lógica. MultipleCondition y
SimpleCondition heredan de este clase. Una instancia de la clase MultipleCondition tiene
hijos de tipo LogicalExpression que son, conforme al patrón Composite, bien de tipo SimpleCondition o bien de tipo MultipleCondition. Este modelo Composite permite expresar
cualquier anidación de condiciones lógicas que se pueda necesitar en la definición de una
alarma.
Otro punto del diagrama de clases interesante de mencionar es el hecho de que la
mayorı́a de las clases de este modelo implementan la interfaz GWTTranslatable, que define el método toI18nString(), responsable de proporcionar una descripción del objeto,
traducida al lenguaje deseado según las técnicas de internacionalización de Google Web
Toolkit.
60
Figura 4.12: Diagrama de Clases - Alarmas
61
Figura 4.13: Estados de una alarma
En complemento de este diagrama de clases, se adjunta un diagrama de estado, en la
figura 4.13, ilustrando los distintos estados por los cuales puede pasar una alarma, en su
ciclo de vida, ası́ como las transiciones posibles entre los mismos.
Cuando se crea una alarma, su estado es Pendiente de activación. En efecto, el motor
de alarmas necesitar actualizar la lista de alarmas que tiene que operar para incluirla.
Cuando es el caso, ésta pasa a ser Operativa. Cualquier cambio de la alarma por parte del
usuario hace pasar la alarma de Operativa a Pendiente de cambio por las mismas razones.
En cualquier momento, un administrador puede desactivar la alarma que pasará a ser
Descactivada por el administrador. Si el usuario modifica la alarma, ésta pasará a ser
Pendiente de revisión, para que el administrador pueda decidir o reactivar la alarma, o
mantenerla desactivada.
El usuario puede desactivar la alarma en cualquier momento siempre y cuando esté activa (Operativa, Pendiente de activación o Pendiente de cambio). En este caso, el estado de
la alarma pasa a ser Desactivada por el usuario. Puede reactivarla más tarde bajo ciertas
condiciones, detalladas en la sección 5.1.2.
4.3.4.
Integración de la GUI con Ciclope Astro
A lo largo de la implementación de la GUI del sistema Ciclope Alarms, se intentó , en
vista de una buena integración al portal existente Ciclope Astro, ceñirse a las normas de
diseño y de nombrado en vigor en el proyecto Ciclope Astro.
Como mencionado en la sección 4.3.1, la interfaz gráfica de Ciclope Alarms es un
módulo GWT. Se puede utilizar en modo standalone, llamando al módulo descrito en
el fichero AlarmConfiguratorStandAlone.xml o integrarlo dentro de otra aplicación web
62
Figura 4.14: Interfaz gráfica - modo standalone
llamando al módulo descrito en el fichero AlarmConfigurator.xml. La única diferencia
entre ambos módulos es la clase responsable de inicializar el módulo, conocida como
entry-point en la terminologı́a GWT. La sección 6.4 proporciona más detalles sobre la
utilización del sistema Ciclope Alarms en modo standalone.
La figura 4.14 incluye una captura de pantalla de la interfaz gráfica de Ciclope Alarms
en modo standalone.
Los pasos seguidos para integrar el módulo en el portal web Ciclope Astro han sido
los siguientes:
Actualización/adición de librerı́as: Ibatis, Log4J, . . .
Cambios de configuración en los ficheros siguientes:
• server-conf/web.xml, para incluir el mapeo de las servlets (llamadas gwt-rpc)
necesarias.
• CiclopeAstro.gwt.xml: para incluir el módulo Ciclope Alarms.
63
Figura 4.15: Interfaz gráfica - integrado con Ciclope Astro
Carga de la estructura de tablas necesarias mediante scripts sql (véase sección 6.2
para más detalles).
Único cambio en el código fuente del portal Ciclope Astro: clase LoginPanel.java,
para cargar los tabs de Ciclope Alarms cuando un usuario entra en el portal.
La figura 4.15 incluye una captura de pantalla de la interfaz gráfica de Ciclope Alarms,
integrada en el portal Ciclope Astro.
4.3.5.
Motor de Alarmas
En este apartado, se detalla la implementación del motor de alarmas del sistema Ciclope Alarms. Dicho motor de alarmas incluye un motor de inferencia lógica Drools [40].
Tiene vocación a ejecutarse como un demonio del sistema. Para llevar a cabo tal propósito, utiliza la librerı́a de Apache Commmons-Daemon, basada para su versión ’Unix’ en
jsvc (servicios Java en entornos tipo Unix)[2]. En una instalación tı́pica (véase sección 6),
se arranca dicho demonio durante el arranque del sistema con un script localizado en la
carpeta /etc/init.d.
64
Las funciones del motor de alarmas incluyen, leer periódicamente los valores de las
variables monitorizadas (en el ámbito de este entrega, las variables de la estación meteorológicas, publicadas en un flujo RSS), comprobar si dichas condiciones cumplen con las
condiciones de activación de una alarma definida (es la responsabilidad del motor de inferencia Drools), y si tal es el caso ejecutar las acciones asociadas. Para poder llevar a cabo
estas funcionalidades, saca provecho de las funcionalidades proporcionadas por el paquete java.util.concurrent de Java 1.5 [64], que introduce una mejoras al modelo tradicional
de Thread (java 1.4 y anteriores). Permite, entre otras cosas, una planificación periódica
de hilos de ejecución.
Adicionalmente, implementa una interfaz RMI que permita el control remoto del mismo desde la GUI (a partir del portal web Ciclope Astro).
El diagrama de clases correspondiente a la implementación del motor de alarmas se
encuentra en la figura 4.16. Destaca la definición de varias interfaces, que permite facilitar ciertas ampliaciones previstas del sistema, como se ha detallado en la sección 4.4.
En efecto, cualquier clase responsable de ejecutar una acción tiene que implementar la
interfaz ActionExecutor. De la misma manera, cualquier clase responsable de la lectura
de variables tiene que heredar de la clase abstracta AbstractFactsFetcher, e implementar
la interfaz FactsFetcherInterface.
La clase EngineDaemon, punto de entrada del motor de alarmas, implementa la interfaz Daemon, definida por la librerı́a Commons Daemon. Tiene el rol de inicializar y
gestionar todos los componentes del motor, i.e. el motor de inferencia Drools ası́ como
todos los lectores de variables. También inicializa el servidor RMI que permite mantener
comunicaciones y control remoto con la interfaz gráfica.
4.4.
Notas para futuras extensiones
En esta sección, se detallan los pasos a seguir para llevar a cabo las futuras extensiones
del sistema previstas en la sección C.3.2.
4.4.1.
Inclusión de una nueva variable de monitorización
Para incluir una nueva variable se deben realizar los siguientes cambios:
En base de datos: añadir los valores necesarios en el campo enum VARIABLE de
la tabla SIMPLE CONDITIONS.
En el módulo gwt: añadir los valores necesarios en la clase enum Variable.
En el motor de alarmas:
• Añadir en la clase Archive, tantos campos como nuevas variables monitorizadas.
65
Figura 4.16: Diagrama de Clases - Motor de Alarmas
66
• Si necesario, crear una nueva clase, heredando AbstractFactsFetcher e implementando la interfaz FactFetcherInterface, responsable de leer los datos.
• Añadir una instancia ’Singleton’ en la lista de AbstractFactsFetcher manejada
por el motor de inferencia Drools.
4.4.2.
Inclusión de un nuevo tipo de acción
Para incluir un nuevo tipo de acción se deben realizar los siguientes cambios:
En base de datos:
• Añadir un registro en la tabla TYPES OF ACTION.
• Añadir en la tabla ACTION SPECIFIC PRIVILEGES los permisos asociados
al nuevo tipo de acción.
En el módulo gwt: añadir el valor necesario en la clase enum TypeOfAction.
En el motor de alarmas: crear una nueva clase implementando la interfaz ActionExecutor e instanciarla siguiendo el patrón Singleton en la clase TriggerEngine.
4.4.3.
Inclusión de un nuevo observatorio
Para incluir un nuevo observatorio se deben realizar los siguientes cambios:
En base de datos:
• Añadir un registro en la tabla TBL ASTRO OBSERVATORIES.
• Añadir en la tabla WORKING HOURS los horarios de apertura del nuevo
observatorio.
En el módulo gwt: añadir el valor necesario en la clase enum Observatory.
Instalar un nuevo motor de alarmas responsable de gestionar las alarmas del observatorio, siguiendo los pasos de la sección 6.3.
En el módulo gwt: añadir en la clase ServicesAdminAlarmsModuleImpl la configuración del servidor RMI del nuevo motor de alarmas.
67
68
Capı́tulo 5
Manual de Usuario
Este capı́tulo incluye instrucciones para utilizar debidamente el sistema Ciclope Alarms.
Dado que el sistema ofrece algunas funcionalidades que solo un usuario de perfil administrador puede utilizar, este capı́tulo se descompone en dos secciones, una primera detallando las operaciones accesibles a todos los usuarios, y otra sección dedicada a las
operaciones accesibles a los administradores.
5.1.
Manual de Usuario
Para utilizar cualquier función del sistema Ciclope Alarms, el usuario debe previamente estar autenticado en el portal Ciclope Astro. El usuario puede entonces, definir una
nueva alarma, editar las alarmas que creó previamente, suscribirse a una alarma, o editar
las suscripciones que tiene.
5.1.1.
Definir una nueva alarma
Para definir una nueva alarma, tiene que abrir la pestaña ’Nueva Alarma’. La definición de una alarma consta de tres etapas, una de configuración global de la alarma, otra
de definición de las condiciones de activación de la alarma y por fin la definición de las
acciones que el sistema tiene que realizar cuando se den las condiciones de ejecución de
la alarma.
5.1.1.1.
Configuración global
El usuario tiene que definir los campos siguientes:
Descripción: Es una descripción textual de la alarma. Tiene solo un valor indicativo, aún ası́ se recomienda elegir una descripción adecuada para poder encontrarla
fácilmente una vez definida.
Periodo de inhibición: Se trata del tiempo mı́nimo, en minutos, entre dos ejecuciones consecutivas de la alarma. Por ejemplo, si se define 20 minutos, tiene que
69
transcurrir al menos 20 minutos después de la ejecución de la alarma para que se
ejecute otra vez (si las condiciones se siguen cumpliendo, se inhibirá la alarma).
Número mı́nimo de activaciones / Intervalo de tiempo: Estos dos parámetros solo
tienen sentido en conjunto. Se tiene que entender como el número mı́nimo de activaciones de la alarma en los últimos x minutos e.g. (3 ocurrencias mı́nimas durante
20 minutos) antes de la ejecución de las acciones. Siguiendo el ejemplo de configuración propuesto antes (3 activaciones mı́nimas durante 20 minutos), si la alarma se
activa a las 14:00, 14:05, 14:20, se ejecutará la acción en el minuto 20. En cambio
si la alarma se activa a las 14:00, 14:15, 14:25, 14:30, se ejecutará la acción en el
minuto 30.
Pública: Si la alarma es pública, los demás usuarios podrán suscribirse a la alarma.
Por defecto, la alarma es pública, pero el usuario puede hacerla privada, si ası́ lo
desea.
Observatorio: se trata del observatorio de referencia, i.e. al cual aplicará la alarma.
5.1.1.2.
Condiciones de activación
Para crear una alarma, el usuario tiene que definir las condiciones de activación de
dicha alarma. Para eso, el usuario puede definir condiciones lógicas sobre el valor de
una variable conocida por el sistema e.g. velocidad del viento, humedad, . . . Puede combinar varias condiciones con operadores lógicos AND, NOT, y OR. La combinación de
condiciones lógicas tiene una estructura de árbol, por la cual puede navegar, abriendo y
cerrando ramas en la interfaz gráfica. Para añadir condiciones, tiene que utilizar los menús
señalados por ’Añadir una condición’ en la rama donde quiere añadirla.
Para quitar una condición, hace falta pulsar el botón ’Suprimir’ en el nivel de la rama
que se quiere suprimir.
El número de condiciones que el usuario puede definir en una determinada alarma
es limitado. Cuando alcanza este lı́mite, se deshabilitan automáticamente los menús que
permiten añadir condiciones. Vuelven a ser activos si se quita una condición.
5.1.1.3.
Acciones
Por fin, el usuario tiene que configurar las acciones que se realizarán cuando se ejecute
la alarma. Esto implica que no estemos dentro del periodo de inhibición de la alarma y
que las condiciones de activación se hayan cumplido al menos el número mı́nimo de veces
especificado (dentro del intervalo de tiempo definido). Si la alarma está desactivada, bien
sea por el usuario, o por un administrador, no se ejecutarán la acciones.
Para configurar una acción, el usuario puede elegir el tipo de acción que desea, dentro
de la lista de acciones accesibles (correo electrónico, SMS, popup, . . . ). Esta lista puede
variar según los permisos otorgados por el administrador. Para cada acción, el usuario
puede configurar algunos elementos textuales en el panel ’Texto configurable’, como el
asunto y el cuerpo de un correo electrónico o el mensaje de un SMS.
70
Si el usuario elige la opción correo electrónico, cuando se ejecute la alarma el sistema
mandará un correo electrónico a la dirección de correo configurada en su cuenta. Si el
usuario elige la opción SMS, cuando se ejecute la alarma el sistema mandará un SMS al
número de móvil configurado en su cuenta. Si el usuario elige la opción popup, cuando
se ejecute la alarma el sistema abrirá un popup en el portal si el usuario está conectado en
este momento. (Si no está conectado en este momento, la alarma se perderá).
Puede añadir una acción pulsando el icono
. De la misma manera, puede quitar
. El número de acciones que el usuario puede definir en
una acción pulsando el icono
una determinada alarma es limitado. Cuando alcanza este lı́mite, desaparecen automáticamente los iconos que permiten añadir acciones. Vuelven a aparecer si se quita una acción.
Más detalles acerca de los lı́mites de utilización de la aplicación se pueden encontrar en
la sección 5.2.4.
5.1.1.4.
Confirmación
Cuando está bien configurada, se puede crear la alarma, pulsando el botón ’Crear’. El
sistema notificará al usuario del éxito de la operación o, en caso de problema, le proporcionará un mensaje explicativo. Cabe destacar que el sistema necesita cierto tiempo antes
de poder tener en cuenta la alarma. La alarma está entonces en el estado ’Pendiente de
activación’ hasta que el sistema la incluya efectivamente. Cuando ocurra, el estado de la
alarma pasará a ser ’Operativa’.
Se incluye en la figura 5.1 una captura de pantalla del panel de creación de una alarma,
incluyendo el mensaje de confirmación del sistema.
El número de alarmas que el usuario puede definir es limitado. Cuando alcanza este
lı́mite, se deshabilita automáticamente el panel de creación de alarmas. Vuelve a ser activo
si se suprime una alarma. Más detalles acerca de los lı́mites de utilización de la aplicación
se pueden encontrar en la sección 5.2.4.
5.1.2.
Editar una alarma
El usuario puede acceder a las alarmas que ha definido previamente abriendo la pestaña ’Mis alarmas’. En este panel, en el cual aparece una lista de las alarmas, puede activar
y desactivar sus alarmas y consultar el estado de las mismas.
Cada alarma tiene un estado general, representando el estado global de la alarma.
Puede ser ’Activa’ o ’Inactiva’. ’Activa’ significa que la alarma no tiene ningún problema.
’Inactiva’ significa que la alarma no se ejecutará. Este estado general se puede leer en la
columna ’¿Activa?’ de la manera siguiente: si la alarma está activa se ve ası́:
ası́:
, y sino
.
Además de este estado general, que indica el estado de la alarma a grandes rasgos,
cada alarma tiene en cada momento un estado más especı́fico, que informa de manera
más precisa del estado real de la alarma.
Estos estados son:
71
Figura 5.1: Crear una nueva alarma
Operativa: La alarma está funcionando de manera correcta. Las acciones se ejecutan
cuando se den las condiciones especificadas.
Pendiente de activación: La alarma acaba de ser creada. Por lo tanto, el sistema todavı́a no la ha incluido en su lista de alarmas que comprobar. El sistema actualiza
periódicamente esta lista. Después de la actualización, la alarma pasa a ser ’Operativa’.
Pendiente de cambio: La alarma acaba de ser cambiada. Por lo tanto el sistema tiene
que actualizar la alarma. Cuando la alarma está en este estado, la alarma se puede
ejecutar en base a su antigua configuración.
Desactivada por el usuario: La alarma ha sido desactivada por el usuario. Puede ser
reactivada por el usuario bajo ciertas condiciones, explicadas a continuación.
Desactivada por el administrador: En cualquier momento, un administrador puede
tomar la decisión de desactivar una alarma. Solo un administrador puede reactivar
la alarma.
Pendiente de revisión: Una alarma en estado ’Desactivada por el administrador’ pasa a ’Pendiente de revisión’ cuando el usuario modifica la alarma Desactivada. Este
cambio de estado permite al administrador saber que la alarma ha sido cambiada y
que puede revisar la alarma. Puede entonces reactivar la alarma o desactivarla otra
vez.
72
Figura 5.2: Gestionar sus alarmas
Este estado aparece entre paréntesis, al lado de la checkbox ’¿Activa?’.
En todo momento, el usuario puede desactivar una alarma activa, desmarcando la checkbox ’¿Activa?’. El estado de la alarma pasará a ser ’Desactivada por el usuario’. Puede
reactivar una alarma en el estado ’Desactivada por el usuario’ marcando la checkbox
’¿Activa?’, siempre y cuando no ha llegado al número máximo de alarmas activas.
En efecto, el número de alarmas activas de manera simultánea que el usuario puede
tener es limitado. Cuando se alcanza este lı́mite, no se pueden reactivar alarmas en el estado ’Desactivada por el usuario’ dado que se deshabilitan automáticamente las ’checkbox’
correspondientes. Vuelven a ser activas si se desactivan más alarmas. Más detalles acerca
de los lı́mites de utilización de la aplicación se pueden encontrar en la sección 5.2.4.
y
El usuario puede reordenar sus alarmas por prioridad usando los botones
para, respectivamente hacer subir la alarma seleccionada en la lista, o hacerla bajar.
El usuario puede cambiar el carácter público de la alarma marcando o desmarcando
la ’checkbox’ correspondiente.
El usuario puede suprimir una alarma pulsando el botón ’Suprimir’ correspondiente.
El sistema le pedirá confirmación antes de seguir, en particular cuando la alarma tiene
suscriptores. En este caso, si el usuario desea seguir con la supresión de la alarma, el
sistema mandará automáticamente un correo electrónico a los suscriptores para avisarlos.
Todos los cambios realizados en este panel, salvo la supresión de alarmas, se tienen
que confirmar pulsando el botón ’Guardar’. Puede anular los cambios (salvo las alarmas
suprimidas) pulsando el botón ’Cancelar’.
Se incluye en la figura 5.2 una captura de pantalla del panel de gestión de las alarmas.
73
Figura 5.3: Editar una alarma
Para editar una alarma más en detalle, tiene que pulsar el botón editar correspondiente.
En el panel que aparece, puede editar toda la configuración de la alarma. La interfaz es
muy parecida a la de creación de una alarma. La gran diferencia respecto a ésta consiste
en la presencia de un botón ’Guardar’ en vez de ’Crear’ y otro botón ’Cancelar’ que
permite volver al panel de gestión general de las alarmas. Hace falta confirmar los cambios
pulsando el botón ’Guardar’. Si se quiere desechar los cambios, es suficiente pulsar el
botón ’Cancelar’.
Se incluye en la figura 5.3 una captura de pantalla del panel de edición de una alarma.
Cabe destacar que el sistema necesita cierto tiempo antes de poder tener en cuenta
los cambios realizados a la alarma. La alarma está entonces en el estado ’Pendiente de
cambio’ hasta que el sistema la incluya efectivamente. Cuando ocurra, el estado de la
alarma pasará a ser ’Operativa’ otra vez.
5.1.3.
Suscribirse a una alarma
Además de poder definir y editar sus propias alarmas, tal y como se ha detallado
previamente, el usuario tiene también la posibilidad de suscribirse a alarmas definidas por
otros usuarios. Ası́ el usuario puede beneficiarse de la experiencia y el trabajo de otros
usuarios, reutilizando alarmas ya completamente definidas y configuradas. De este modo,
el usuario solo tiene que definir las acciones que quiere que se ejecuten cuando se den las
condiciones de la alarma.
74
Las etapas necesarias para suscribirse a una alarma son las siguientes:
Buscar la alarma a la cual suscribirse.
Configurar las acciones personalizadas.
Confirmar la suscripción.
Para suscribirse a una alarma definida por otro usuario, el usuario tiene que abrir la
pestaña ’Suscribir’.
5.1.3.1.
Buscar una alarma
Para poder escoger una alarma que le interese, el usuario puede buscar dentro de las
alarmas públicas del sistema, especificando uno o varios de los criterios de búsqueda siguientes: usuario creador de la alarma, rol del usuario creador, variables monitorizadas,
observatorio monitorizado, descripción de la alarma, periodo de inhibición, número máximo de activaciones durante intervalo de tiempo fijo antes de ejecución. Puede ordenar los
resultados por fecha de creación y por fecha de última ejecución, pulsando el botón correspondiente.
Se actualiza la lista de resultados dinámicamente (i.e. en cuanto el valor de un filtro
es cambiado), aún ası́ el usuario dispone de un botón ’Buscar’ para forzar un refresco
ası́ como de un botón ’Quitar Filtros’ para eliminar todos los filtros especificados.
En caso de haber un número importante de resultados, se muestran los resultados en
varias páginas.
5.1.3.2.
Configurar las acciones
Cuando ha encontrado una alarma a la cual le interesa suscribirse, el usuario tiene
que pulsar el botón ’Suscribir’, lo cual le llevará a otro panel donde pueda especificar las
acciones que quiere asociar a ella.
El usuario puede configurar las acciones que quiere asociar a su suscripción del mismo
modo que cuando define su propia alarma. Los pasos a seguir son similares a los descritos
en la sección 5.1.1.3.
Cuando está bien configurada, puede confirmar la suscripción pulsando el botón ’Suscribir’. En cualquier momento, puede pulsar el botón ’Cancelar’ en cuyo caso no se guardará la suscripción.
Se incluye en la figura 5.4 una captura de pantalla del panel de creación de una suscripción, incluyendo el mensaje de confirmación del sistema.
5.1.4.
Editar una suscripción
El usuario puede acceder a las suscripciones que ha definido previamente abriendo la
pestaña ’Mis suscripciones’. En este panel, en el cual aparece una lista de las suscripciones, puede activar y desactivar sus suscripciones y consultar el estado de las mismas.
Como para una alarma, una suscripción tiene un estado general que puede ser ’Activa’
o ’Inactiva’ y un estado más especı́fico. Estos estados son: ’Operativa’, ’Desactivada por
75
Figura 5.4: Crear una nueva suscripción
el usuario’, ’Desactivada por el administrador’, y ’Pendiente de revisión’. Estos estados
tienen el mismo sentido que para una alarma.
El usuario puede suprimir una suscripción pulsando el botón ’Suprimir’ correspondiente. El sistema le pedirá confirmación antes de seguir.
Los cambios realizados en este panel, salvo la supresión de suscripciones, se tienen
que confirmar pulsando el botón ’Guardar’. Puede anular los cambios (salvo las suscripciones suprimidas) pulsando el botón ’Cancelar’.
Se incluye en la figura 5.5 una captura de pantalla del panel de gestión de las suscripciones.
Para editar una suscripción más en detalle, tiene que pulsar el botón ’Editar’ correspondiente. En el panel que aparece, puede editar toda la configuración de la suscripción.
La interfaz es muy parecida a la de creación de una suscripción. La gran diferencia respecto a ésta consiste en la presencia de un botón ’Guardar’ en vez de ’Suscribir’ y otro botón
’Cancelar’ que permite volver al panel de gestión general de las suscripciones. Hace falta
confirmar los cambios pulsando el botón ’Guardar’. Si se quiere desechar los cambios, es
suficiente pulsar el botón ’Cancelar’.
Se incluye en la figura 5.6 una captura de pantalla del panel de edición de una suscripción.
76
Figura 5.5: Gestionar sus suscripciones
Figura 5.6: Editar una suscripción
77
5.2.
Manual de Administrador
Un administrador es un superusuario. Por eso, tiene acceso a todas las funcionalidades
descritas en la sección 5.1. En algunos casos, dicha funcionalidad es más amplia para un
administrador.
Además de poder usar estas funcionalidades, tiene también la posibilidad de administrar las alarmas y suscripciones de cualquier usuario, definir los permisos de los mismos
y administrar el sistema.
En la sección 5.2.1, se detallan las extensiones de las funcionalidades descritas en la
sección 5.1 que se aplican en el caso de un administrador. En las secciones 5.2.2 y 5.2.3,
se describen las funciones de administración de alarmas y suscripciones definidas por
cualquier usuario. La sección 5.2.4 está dedicada a la gestión de permisos de usuario. Por
fin, la sección 5.2.5 describe las funciones de administración del sistema.
5.2.1.
Extensiones de las funcionalidades de usuario
Tal y como se explicó previamente, el administrador tiene acceso a todas las funcionalidades descritas en la sección 5.1. Puede definir alarmas, editarlas, o suscribirse a alarmas
definidas por otros usuarios. Pero puede definir acciones de manera más amplia que un
usuario. En concreto, puede escoger a los destinatarios de una alarma, i.e. tiene la posibilidad de hacer llegar una notificación de alarma a otros usuarios, lo que no puede hacer
un usuario normal.
Puede escoger involucrar a determinados usuarios del sistema, todos los usuarios de
un perfil o incluso (para correo electrónico y SMS únicamente) a personas no dadas de
alta (proporcionando respectivamente la dirección de correo y el número de móvil de la
persona correspondiente).
Para eso, tiene que seleccionar la opción correspondiente en la lista de tipo ’radio’.
La primera opción es ’usuario del sistema’. Para escoger el usuario destinatario, tiene que
seleccionarlo en la lista. Por defecto, el usuario seleccionado será el propio administrador.
La segunda opción es ’todos los usuarios de un perfil’. Para escoger el perfil, tiene que
seleccionarlo en la lista. La última opción es ’usuario anónimo’, sólo es disponible para
acciones de tipo correo electrónico o SMS. En este caso el administrador tiene que escribir
los datos de contacto de la persona, i.e. respectivamente la dirección de correo o el número
de móvil. Puede incluir los contactos de varias personas, separados por un ;
Puede añadir un destinatario pulsando el icono
. De la misma manera, puede quitar
un destinatario pulsando el icono
.
Se incluye en la figura 5.7 una captura de pantalla del panel de edición de una alarma,
en el caso de un administrador.
5.2.2.
Administrar las alarmas de otros usuarios
El panel de administración de alarmas es accesible abriendo la pestaña ’Admin. Alarmas’. En este panel, el administrador puede editar, desactivar e incluso suprimir las alarmas de cualquier usuario.
78
Figura 5.7: Edición de una alarma - administrador
Para llevar a cabo su labor de administración de una manera eficaz, puede buscar dentro de las alarmas del sistema, especificando uno o varios de los criterios de búsqueda
siguientes: usuario creador de la alarma, rol del usuario creador, variables monitorizadas, tipos de acciones definidas, estado de la alarma observatorio monitorizado, carácter
público o privado de la alarma, descripción de la alarma, periodo de inhibición, número
máximo de activaciones durante intervalo de tiempo fijo antes de ejecución. Puede ordenar los resultados por fecha de creación y por fecha de última ejecución, pulsando el
botón correspondiente.
Se actualiza la lista de resultados dinámicamente (i.e. en cuanto el valor de un filtro es
cambiado), aún ası́ el administrador dispone de un botón ’Buscar’ para forzar un refresco
varias páginas.
En este panel puede en concreto, suprimir alarmas (en este caso, el sistema pide confirmación) o cambiar el estado de una alarma. Puede, por ejemplo, desactivar una alarma
seleccionando en la lista desplegable el valor ’Desactivada por el administrador’ o reactivar una alarma seleccionando en la lista el valor ’Operativa’. Todos los cambios de estado
se tienen que confirmar pulsando el botón ’Guardar’. Cabe destacar que, una vez guardados los cambios, una desactivación de alarma tiene un efecto inmediato en el sistema.
Si quiere editar en detalle una alarma, el administrador puede pulsar el botón ’Editar’.
En el panel siguiente, puede editar todos los campos de la alarma como si fuera la suya.
Los cambios se tienen que confirmar pulsando el botón ’Guardar’.
Se incluye en la figura 5.8 una captura de pantalla del panel de administración de
alarmas, en el caso de un administrador.
79
Figura 5.8: Administrar las alarmas de otros usuarios
5.2.3.
Administrar las suscripciones de otros usuarios
El panel de administración de suscripciones es accesible abriendo la pestaña ’Admin.
Suscripciones’. En este panel, el administrador puede editar, desactivar e incluso suprimir
las suscripciones de cualquier usuario.
Para llevar a cabo su labor de administración de una manera eficaz, puede buscar
dentro de las suscripciones del sistema, especificando uno o varios de los criterios de
búsqueda siguientes: usuario creador de la alarma, rol del usuario creador, tipos de acciones definidas, estado de la suscripción. Puede ordenar los resultados por fecha de creación
y por fecha de última ejecución, pulsando el botón correspondiente.
Se actualiza la lista de resultados dinámicamente (i.e. en cuanto el valor de un filtro es
cambiado), aún ası́ el administrador dispone de un botón ’Buscar’ para forzar un refresco
varias páginas.
En este panel puede en concreto, suprimir suscripciones o cambiar el estado de una
suscripción. Puede, por ejemplo, desactivar una suscripción seleccionando en la lista desplegable el valor ’Desactivada por el administrador’ o reactivar una suscripción seleccionando en la lista el valor ’Operativa’. Todos los cambios de estado se tienen que confirmar
pulsando el botón ’Guardar’. Cabe destacar que, una vez guardados los cambios, una desactivación de suscripción tiene un efecto inmediato en el sistema.
Si quiere editar en detalle una suscripción, el administrador puede pulsar el botón
’Editar’. En el panel siguiente, puede editar todos los campos de la suscripción como si
fuera la suya. Los cambios se tienen que confirmar pulsando el botón ’Guardar’.
80
5.2.4.
Gestionar los permisos de los usuarios
Para gestionar los permisos de los usuarios, el administrador tiene que entrar en el
panel correspondiente, abriendo la pestaña ’Admin. permisos’.
El panel tiene tres partes. En la primera, localizada en la parte izquierda de la pantalla,
puede definir los permisos definidos para cada tipo de perfil (admin, basic, advanced o
demo). Para cambiar de perfil, tiene que seleccionar el perfil deseado en la lista desplegable. Puede cambiar los valores definidos para cada uno de los elementos de restricción
siguientes:
El número máximo de alarmas que un usuario del perfil seleccionado puede definir.
El número máximo de alarmas que un usuario del perfil seleccionado puede activar
al mismo tiempo.
El número máximo de condiciones lógicas que un usuario del perfil seleccionado
puede utilizar en la definición de una alarma.
El número máximo de acciones que un usuario del perfil seleccionado puede configurar para cada alarma.
El número máximo de suscriptores que puede tener una alarma definida por un
usuario del perfil seleccionado.
El número máximo de alarmas a las que un usuario del perfil seleccionado se puede
suscribir.
Para cada tipo de acción existente:
• La posibilidad o no que tiene el usuario del perfil seleccionado para utilizar
dicho tipo de acción.
• El número máximo de alarmas/suscripciones utilizando dicho tipo de acción
que un usuario del perfil seccionado puede definir.
Para activar o desactivar un tipo de acción dado, hace falta marcar o desmarcar el
botón tipo ’checkbox’ correspondiente.
Los cambios se tienen que confirmar pulsando el botón ’Guardar’ situado bajo esta
sección. Antes de hacer efectivo el cambio, el sistema propone al administrador enviar un
correo electrónico a todos los usuarios del perfil, avisando de los cambios realizados. Si
rechaza, los cambios se guardan. Si acepta, un popup aparece, con un modelo del correo
electrónico auto-rellenado, pero que puede modificar como lo desea. El popup tiene un
botón ’Enviar’ y otro ’Cancelar’. Pulsando ’Cancelar’, se cancela la operación i.e. no se
guardan los cambios ni se mandan los correos electrónicos. Pulsando ’Enviar’, el sistema
procede con la actualización de los cambios y a continuación envı́a el correo electrónico
a todos los usuario del perfil.
En la segunda parte del panel, el administrador puede definir excepciones para usuarios en concreto, i.e. valores especı́ficos de uno de los elementos de restricción del sistema
81
Figura 5.9: Gestionar los permisos
para un usuario determinado. Tiene que seleccionar el usuario deseado en la lista correspondiente (cuyo contenido se actualiza según el perfil seleccionado en la otra lista i.e.
solo contiene los usuarios del perfil seleccionado). Para añadir una excepción, tiene que
pulsar el botón ’añadir excepción’, lo cual hace aparecer un campo donde especificar el
valor que prevaldrá sobre el valor definido a nivel de perfil. Por razones de seguridad, este
valor debe de ser más restrictivo que el valor definido a nivel de perfil.
Los cambios se tienen que confirmar pulsando el botón ’Guardar’ situado bajo esta
sección. Como en el caso del cambio de permisos a nivel de perfil, el administrador tiene
la posibilidad de mandar un correo electrónico al usuario afectado.
La tercera parte del panel (a la derecha) muestra la configuración de permisos resultante para el perfil y el usuario seleccionados. Permite tener una confirmación visual de
las modificaciones aportadas a ambos. Su contenido se actualiza automáticamente según
se producen los cambios al perfil o al usuario seleccionado.
Se incluye en la figura 5.9 una captura de pantalla del panel de gestión de los permisos,
incluyendo el popup utilizado para mandar el correo electrónico a los usuarios afectados.
Cabe destacar que cuando el administrador restringe los permisos de una manera u
otra, bien sea a nivel de perfil o de usuario, existe la posibilidad de que usuarios no cumplan con las nuevas polı́ticas de permisos. (e.g. un usuario tiene configurado 5 alarmas,
y el administrador baja el número de alarmas que pueda definir un usuario de este perfil
de 5 a 3). La solución escogida para solucionar este tipo de conflicto es la siguiente: en
82
caso de conflicto, el sistema deberá tomar las acciones necesarias para que se cumplan las
nuevas polı́ticas de restricción. Dichas acciones podrán incluir desactivar o suprimir las
alarmas de más baja prioridad hasta cumplir las nuevas reglas de restricción.
5.2.5.
Administrar el sistema
Para utilizar las funciones de administración del sistema, el administrador tiene que
entrar en el panel correspondiente, abriendo la pestaña ’Administración Global’. Dichas
funciones se pueden desglosar en dos categorı́as: monitorización del funcionamiento del
sistema y configuración de horarios de funcionamiento del mismo.
5.2.5.1.
Monitorización del sistema
En este apartado se llamará ’motor de alarmas’ al componente del sistema dedicado
a la monitorización de variables y ejecución de alarmas. Cabe destacar que dicho componente es totalmente independiente del portal Ciclope Astro. Aún ası́ existen canales de
comunicación entre ambos componentes software para permitir una monitorización del
funcionamiento del primero desde el portal web. Cabe destacar que existen tantos motores de alarma como observatorios monitorizados.
El lector interesado en detalles acerca de la arquitectura del sistema está invitado a
consultar las secciones 4.3.1 y 6.
En el panel de administración global, el administrador puede consultar el estado del
motor de alarmas del observatorio seleccionado en la lista desplegable situada arriba. El
estado del motor puede tomar uno de los siguientes valores:
Arrancado: el motor está funcionando de manera correcta.
Parado: el motor está parado i.e. no se ejecuta ninguna alarma.
No disponible: no es posible establecer una comunicación remota con el motor.
Arrancando: el motor está en proceso de inicialización.
Parando: el motor está ejecutando una parada controlada.
El estado del motor está actualizado periódicamente. En cualquier momento, el administrador puede forzar dicha actualización pulsando el botón ’Refrescar Estado’.
El administrador puede actuar remotamente sobre el motor de las formas siguientes:
si está parado, lo puede iniciar, pulsando el botón ’Arrancar Motor’, si está activo, lo
puede parar o reiniciar, pulsando respectivamente los botones ’Parar Motor’ y ’Rearrancar Motor’. El sistema confirma visualmente al administrador que el motor ha recibido
correctamente la orden.
En caso de ser activo (estado Arrancado), también puede consultar las reglas activas,
en el formato nativo de Drools, en el panel desplegable cuyo tı́tulo es ’Reglas corrientes’.
El motor actualiza periódicamente las reglas para tener en cuenta las modificaciones de
las alarmas definidas o la inserción de nuevas alarmas. Aún ası́, el administrador puede
solicitar una actualización de las reglas pulsando el botón ’Refrescar Reglas’.
83
Por fin, cabe destacar que si el estado del motor es ’No disponible’, significa que
el motor tiene que ser rearrancado de forma manual, dado que no hay posibilidad de
comunicarse con ello de manera remota.
5.2.5.2.
Configuración de horarios de funcionamiento del motor de alarmas
El administrador tiene también la posibilidad de definir horas de funcionamiento del
sistema ası́ como dı́as festivos. Estas horas de funcionamiento y dı́as festivos reflejan las
horas de accesibilidad del observatorio.
Las acciones de alarmas definidas por usuarios normales se inhibirán si la ejecución
de la alarma ocurre durante uno de los dı́as festivos definidos o fuera de las horas de
funcionamiento.
Aún ası́, las alarmas definidas por administradores no se verán afectadas por la configuración de horas de funcionamiento o dı́as festivos, i.e. se ejecutarán siempre y cuando
el motor de alarmas correspondiente esté activo.
Para configurar horas de funcionamiento, el administrador tiene que desplegar el panel
’Horas de funcionamiento’. Aparece un planning semanal, de lunes a domingo. Cada dı́a
de la semana puede estar marcado como ’Tiempo completo’, en cuyo caso funciona todo
el dı́a, o ’Cerrado’ en cuyo caso no funciona en todo el dı́a. Además de estas configuraciones, se puede especificar una hora de apertura y una hora de cierre. Para marcar un dı́a
como ’abierto’ o ’cerrado’ hace falta escoger la opción correspondiente en la lista. Para
especificar horas de apertura y cierre, hace falta escoger la opción ’Tiempo parcial’ en la
lista. Una vez la opción seleccionada, aparecen zonas de texto donde especificar la hora
de apertura y la hora de cierre para este dı́a. Todos los cambios se tienen que confirmar
pulsando el botón ’Guardar’.
Para configurar dı́as festivos, tiene que desplegar el panel ’Dı́as festivos’. Aparece la
lista de dı́as festivos junto a un calendario. Para añadir un dı́a festivo, hace falta seleccionar
.
el dı́a deseado en el calendario. Para quitar un dı́a festivo, hace falta pulsar el icono
Todos los cambios se tienen que confirmar pulsando el botón ’Guardar’.
Se incluye en la figura 5.10 una captura de pantalla del panel de administración del
sistema.
84
Figura 5.10: Administrar el sistema
85
86
Capı́tulo 6
Manual de Instalación de Ciclope
Alarms
En este capı́tulo se detallan todos los pasos a seguir para instalar el sistema Ciclope
Alarms.
Para que el sistema pueda mandar SMS, es necesario tener un dispositivo hardware
ofreciendo este tipo de funcionalidad, es decir un módem GSM. Aunque el sistema podrı́a
funcionar con un móvil estándar siempre y cuando éste ofrezca algún tipo de conexión
a un ordenador (bluetooth, usb, infrarrojo), se recomienda el uso de un módem GSM
dedicado, por razones de fiabilidad. El lector interesado puede consultar el anexo B para
más detalles.
El módem GSM es el único componente hardware especı́fico necesario en la instalación del sistema Ciclope Alarms.
En la sección 6.1, se describe la instalación y configuración del módem GSM y de las
librerı́as necesarias para comunicar con él.
En la sección 6.2, se detallan los pasos a seguir para crear en una base de datos MySQL
las tablas necesarias para el funcionamiento de Ciclope Alarms.
En la sección 6.3, se detallan los pasos a seguir para instalar y configurar el componente motor de alarmas del sistema.
Por fin, en la sección 6.4, se describe la instalación y configuración de la interfaz
gráfica (GUI) del sistema.
6.1.
Instalación del módem GSM
En el ámbito de este proyecto, se utilizó un módem Siemens TC35i [17]. Aún ası́,
el sistema está diseñado para poder funcionar con cualquier tipo de módem GSM y las
etapas para instalarlo y configurarlo deberı́an de ser muy parecidas a las expuestas a continuación. En caso de duda, el lector está invitado a consultar la documentación especı́fica
del módem utilizado [62, 61].
87
6.1.1.
Cableado y puesta en funcionamiento
El cableado exacto del módem depende fuertemente del modelo. Pero cualquier modelo dispone de un compartimento permitiendo albergar una tarjeta SIM. Es recomendable
insertar ésta en el compartimento adecuado antes de alimentar el módem.
Un módem GSM (o un móvil) se puede conectar a un ordenador de varias formas,
según el modelo: conexión serie, usb, o hasta bluetooth o infrarrojos (para móviles). En
el caso de una conexión serie o usb, es necesario conectar el cable correspondiente entre
el módem y el ordenador. En el caso de que el módem disponga de una salida serie,
pero el ordenador carezca de una entrada del mismo tipo, es posible utilizar un adaptador
usb/serie.
Una vez esté conectado, y la tarjeta SIM correctamente colocada, se puede encender
el módem y proceder a las primeras pruebas.
6.1.2.
Primeras Pruebas
Para hacer las primeras pruebas con el módem, se recomienda el uso del software
minicom 1 , aunque cualquier otro método para comunicarse a un dispositivo serie (o usb)
vale.
La comunicación a bajo nivel con un módem GSM se hace mediante comandos AT.
Los comandos AT, a veces denominados comandos Hayes (por la marca del primer modelo que le llegó a utilizar) es un estándar de facto de la industria. El lector puede encontrar
una lista indicativa de estos comandos en la url http://home.intekom.com/option/hayesat.
htm, aunque se recomiende que consulta la documentación del módem [61] (los constructores soliendo tener sus propias extensiones).
La primera prueba que se recomienda hacer es mandar el comando ATI. Si todo funciona bien, el módem devuelve información del constructor y del modelo del módem.
Si el comando no funciona o devuelve un error, se recomienda comprobar el cableado y
referirse a la documentación especı́fica del módem.
La segunda prueba serı́a mandar el comando AT+CMEE=2, que permite configurar el
módem en modo verbose. Si no se configura de tal manera, cualquier error aparecerá como ’Error’, sin más detalles, lo que complica la resolución de cualquier problema. Para
comprobar que el módem ha tenido en cuenta el comando anterior, hace falta el comando
AT+CMEE?, la respuesta debe ser 2.
Llegado a esta etapa, ya se puede intentar mandar un SMS con el módem. Pero justo
antes de poder hacer eso, hace falta introducir el PIN de la tarjeta SIM. Eso se consigue
mandando el mando AT+CPIN=****, sustituyendo las **** por el código. Cuidado, como con un móvil normal, solo se dispone de tres intentos antes de bloquear la tarjeta SIM.
En este caso, se debe utilizar el código PUK (Personal Unblocking Key) de ocho dı́gitos,
con el mando AT+CPIN=PUK1,new PIN1, para asignar newPIN1 como nuevo código
PIN.
Una vez introducido correctamente el PIN de la tarjeta, el módem deberı́a de conectarse automáticamente a la red del operador contratado (u otro operador en caso de
1
Página oficial del proyecto minicom: http://alioth.debian.org/projects/minicom/.. minicom está disponible en los repositorios Debian/Ubuntu.
88
roaming). Para comprobar si está o no asociado a una red, hace falta utilizar el comando
AT+COPS?, que devuelve el estado de la conexión, y el operador de telecomunicaciones
al cual está conectado el módem.
Llegado a este punto, el módem deberı́a de estar listo para mandar su primer SMS.
Hace falta mandar el comando AT+CMGF=1 para configurar el módem en modo texto.
Después, hace falta mandar el comando AT+CMGS=*****, sustituyendo las estrellas por
el número al cual se quiere mandar el mensaje. A continuación, hace falta escribir el
mensaje deseado, acabando por CTRL+Z para mandar el mensaje.
En caso de duda o problema encontrado siguiendo estas etapas, se recomienda consultar la documentación especı́fica del módem utilizado hasta ser capaz de pasar la primera
prueba i.e. mandar un mensaje SMS con el módem.
6.1.3.
Instalación de las librerı́as java
El motor de alarmas utiliza la librerı́a SMSLib [19] para poder mandar SMS. La página oficial del proyecto SMSLib se puede encontrar en la URL: http://code.google.com/p/
smslib/. El código está distribuido bajo los términos de la licencia Apache License 2.0 [3].
La librerı́a se puede bajar en la URL: http://code.google.com/p/smslib/downloads/list. Se
puede bajar la versión binaria (smslib-v3.4.1-bin.zip) o las fuentes (smslib-v3.4.1-bin.zip)
y compilarlas. La versión binaria también incluye las fuentes.
La librerı́a SMSLib necesita para funcionar una librerı́a java que implemente las especificaciones de la Java Communications API de Sun Microsystems, disponibles en la
URL: http://java.sun.com/products/javacomm/.
Se pueden utilizar la implementación comercial de Sun o la implementación libre rxtx.
La implementación comercial de Sun Microsystems se puede encontrar en la URL:
https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS SMI-Site/en US/-/USD/
ViewProductDetail-Start?ProductRef=JAVACOMM-3.0.1-LX-SP-G-F@CDS-CDS SMI
Hace falta registrarse para bajar los binarios de la librerı́a. Cabe destacar que esta implementación es propietaria i.e. su código fuente no está disponible. Su utilización está sujeta
a la licencia ’Binary Code License Agreement’ de Sun Microsystems [63].
Otra solución es utilizar la implementación libre rxtx, disponible en la página: http://
rxtx.qbang.org/wiki/index.php/Main Page. El código de la librerı́a está publicado bajo los
términos de la licencia GNU LGPL, versión 2.1 [24]. Está disponible en los repositorios
de Debian y Ubuntu.
La librerı́a SMSLib también necesita la instalación de la librerı́a slf4j (simple logging
facade for Java). Se puede encontrar en la página:http://www.slf4j.org/download.html. El
código de la librerı́a está publicado bajo los términos de la licencia SLF4J License [58],
copia verbatim de la licencia X11.
6.2.
Instalación de la base de datos
Tanto el componente motor como la interfaz gráfica de Ciclope Alarms guardan y leen
información en una base de datos MySQL.
89
Para instalar un servidor de base de datos MySQL, hace falta instalar los paquetes
necesarios mediante el comando siguiente:
apt-get install mysql-server
La creación de las tablas necesarias al funcionamiento del sistema es distinta si se
instala el sistema solo (en modo standalone), o si se quiere integrar con el sistema existente
Ciclope Astro.
Para facilitar esta labor, se incluyen con las fuentes unos scripts sql. Se pueden encontrar en la URL: http://castro.svn.sourceforge.net/viewvc/castro/trunk/Alarms/scripts/
Para bajarlos, se puede ejecutar el comando siguiente:
wget http://castro.svn.sourceforge.net/viewvc/castro/trunk/Alarms/scripts.tar.gz -O
scripts.tar.gz
6.2.1.
Modo standalone
Los pasos para crear la base de datos en el modo standalone son los siguientes:
1. Abrir una sesión mysql con el servidor. Se necesita la contraseña de root (del servidor mysql).
mysql -u root -p
2. Cargar el script CiclopeAlarms tables structure standalone.sql. Este script crea una
base de datos llamada ALARMS, y en esta base de datos, todas las tablas necesarias.
source [directorioDelScript]/CiclopeAlarms_tables_structure_standalone.sql
3. Cargar el script CiclopeAlarms configuration data standalone.sql. Este script carga una configuración inicial, para poder empezar a utilizar la aplicación. Crea un
usuario ’admin’ con contraseña ’admin’.
source [directorioDelScript]/CiclopeAlarms_configuration_data_standalone.sql
4. Cerrar la sesión mysql.
exit
6.2.2.
Modo integrado con Ciclope Astro
Los pasos para alterar la base de datos utilizada en Ciclope Astro son los siguientes:
1. Abrir una sesión mysql con el servidor.
mysql -u root -p
2. Seleccionar la base de datos.
90
USE [NOMBRE_BASE_DE_DATOS];
3. Cargar el script CiclopeAlarms tables structure.sql. Este script crea todas las tablas
necesarias, y altera la tabla de usuarios de Ciclope Astro.
source [directorioDelScript]/CiclopeAlarms_tables_structure.sql
4. Cargar el script CiclopeAlarms configuration data.sql. Este script carga una configuración inicial, para poder empezar a utilizar la aplicación.
source [directorioDelScript]/CiclopeAlarms_configuration_data.sql
5. Cerrar la sesión mysql.
exit
6.3.
Instalación del Motor de alarmas
6.3.1.
Prerequisitos y librerı́as
Antes de poder instalar el motor de alarmas, hace falta instalar jsvc, una librerı́a java
de comunicación serie (bien sea rxtx bien sea la implementación de Sun) y ant.
Por ejemplo, si se utiliza rxtx, estas dependencias se pueden solucionar ejecutando el
comando siguiente
apt-get install jsvc librxtx-java ant
Para funcionar correctamente, el motor necesita un conjunto de librerı́as, que se detalla
en la tabla 6.1. Aún ası́, las librerı́as necesarias están disponibles en la carpeta lib/ de las
fuentes, como explicado en la sección 6.3.2, por lo cual no es imprescindible instalarlas
por separado.
Tabla 6.1: Librerı́as necesarias para el motor de alarmas
Librerı́a
GWT
Ibatis
Junit
Log4J
Versión
1.5.3
URL
http://google-web-toolkit.googlecode.com/files/
gwt-linux-1.5.3.tar.bz2
2.3.4.726 http://community.ebuyershield.com/apache/ibatis/
binaries/ibatis.java/ibatis-2.3.4.726.zip
3.8.2
http://sourceforge.net/project/showfiles.php?group
id=15278&package id=12472&release id=398352
1.2.15
http://www.apache.org/dyn/closer.cgi/logging/log4j/
1.2.15/apache-log4j-1.2.15.tar.gz
91
JavaMail
1.4.2
activation
1.1.1
rxtx
SLF4J
SMSLib
2.1-7r2
1.5.6
3.4.1
Drools
4.0.7
Commons Daemon
1.0.1
Driver MySQL
3.0.17
6.3.2.
https://cds.sun.com/is-bin/INTERSHOP.enfinity/
WFS/CDS-CDS Developer-Site/en US/-/USD/
ViewProductDetail-Start?ProductRef=javamail-1.4.
2-oth-JPR@CDS-CDS Developer
ViewProductDetail-Start?ProductRef=jaf-1.1.
1-fcs-oth-JPR@CDS-CDS Developer
http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip
http://www.slf4j.org/dist/slf4j-1.5.6.tar.gz
http://smslib.googlecode.com/files/smslib-v3.4.
1-bin.zip
http://download.jboss.org/drools/release/4.0.7.19894.
GA/drools-4.0.7-bin.zip
http://mirrors.homepagle.com/apache/commons/
daemon/binaries/commons-daemon-1.0.1.tar.gz
http://dev.mysql.com/get/Downloads/Connector-J/
mysql-connector-java-3.0.17-ga.tar.gz/from/pick
Instalación
Las fuentes del motor de alarmas se pueden encontrar en la URL: http://castro.svn.
sourceforge.net/viewvc/castro/trunk/Alarms/AlarmEngine.tar.gz?view=tar.
Los pasos a seguir para instalar el motor de alarmas son los siguientes:
1. Bajar las fuentes.
wget http://castro.svn.sourceforge.net/viewvc/castro/trunk/Alarms/AlarmEngine.tar.
gz -O AlarmEngine.tar.gz
2. Descomprimir las fuentes.
tar -xzvf AlarmEngine.tar.gz && cd AlarmEngine
3. Compilar las fuentes, utilizando ant.
ant -f build.xml
4. Ejecutar el script de instalación.
cd scripts
sh install.sh
Este script realiza los siguientes pasos (de manera transparente para el usuario):
a) Crea si necesario todos las carpetas necesarias:
/etc/ciclope-alarms: Carpeta de configuración.
92
/usr/share/ciclope-alarms: Carpeta de instalación.
/usr/share/ciclope-alarms: Carpeta de las librerı́as.
/var/log/ciclope-alarms: Carpeta de logs.
b) Crea si necesario un usuario ciclope-alarms, encargado de ejecutar el motor
de alarmas.
c) Copia todos los ficheros necesarias en las carpetas adecuadas.
d) Copia en /etc/init.d el script de arranque del motor.
e) Genera los enlaces simbólicos (en las carpetas /etc/rc*.d) necesarios para que
el motor funcione como un servicio i.e. se arranca solo al inicio de la máquina
y se para cuando se apaga la máquina.
6.3.3.
Configuración
Para completar la instalación del motor, solo hace falta configurarlo. Toda la configuración se puede encontrar en la carpeta /etc/ciclope-alarms, en distintos ficheros de
configuración.
A continuación, se repasan los distintos ficheros de configuración, comentando partes
de su contenido, y explicando los valores de las propiedades clave.
drools.properties: parámetros de drools.
#in seconds
fireRules.frequency:60 #frecuencia de comprobacion de las alertas, en segundos
fireRules.first.delay:15 #retraso de la primera comprobacion, en segundos
#in seconds
updateRules.frequency:600 #frecuencia de actualizacion de las reglas, en
segundos updateRules.first.delay:300 #retraso de la primera actualizacion, en
segundos
global.properties:
observatory.code=## el campo SHORT_NAME del observatorio que el motor monitoriza
log4j.properties: fichero de configuración de log.
SqlMapConfigAlarms.xml: fichero de configuración de acceso a base de datos.
..
<property name="JDBC.ConnectionURL"
value="jdbc:mysql://(ip:puerto del
servidor de base de datos)/(nombre de la base de datos)" />
<property name="JDBC.Username" value="nombre de usuario" />
<property name="JDBC.Password" value="password" />
..
actions/gsm.properties:
##modem.nameCode indicative name
modem.nameCode:modem.com1
##if serial
##modem.port:/dev/ttyS0
93
##if usb
##modem.port:/dev/ttyUSB0
modem.port:/dev/ttyUSB0
#modem.baud:57600 should be fine
modem.baudRate:57600
modem.manufacturer:Siemens ## cambiar si necesario
modem.model:TC35i
## cambiar si necesario
##for USB connections with RXTX library use modem.serialPolling:true
## in other case, this property should be commented
modem.serialPolling:true
modem.pinCode: ##PIN code la SIM utilizada
actions/mail.properties:
mail.from= ## cuenta de correo (usuario@provedor)
mail.from.ky= ##password
# GMail
mail.smtps.host:smtp.gmail.com ## cambiar por la IP del servidor SMTP
mail.smtps.auth:true
actions/gwt.properties:
SERVICE_NAME:notifyPopup ##no cambiar
REMOTE_RMI_SERVER_IP:localhost ## IP del servidor de la GUI
REMOTE_RMI_SERVER_PORT:55025 ## puerto del servidor RMI de la GUI
facts/RSS.properties:
RSS_URL:http://tornasol.datsi.fi.upm.es/ciclope/weather/wxrss.xml
# FREQUENCY of RSS update in seconds
#FREQUENCY:60
FREQUENCY:60
rmi/RMI.properties:
RMI_LOCAL_PORT:15010 ##puerto local donde arrancar un
servidor RMI (parar comunicacion con la GUI)
SERVICE_NAME:AstroToEngineComm ##no cambiar
El motor se arranca con el comando
/etc/init.d/ciclope-alarms start
Se para con el comando
/etc/init.d/ciclope-alarms stop
Estos comandos necesitan permisos de administrador. Conviene recordar que según el
procedimiento de instalación detallado en este documento, el motor está instalado como
un servicio i.e. arranca y se detiene automáticamente cuando se inicia o se detiene el
sistema.
94
6.4.
Instalación de la GUI
En esta sección se detallan los pasos a seguir para instalar la interfaz gráfica de Ciclope Alarms en el contexto de una instalación en modo standalone, es decir en modo no
integrado con Ciclope Astro.
El lector interesado en la integración de la interfaz gŕafica con Ciclope Astro está invitado a consultar la sección 4.3.4.
6.4.1.
Prerequisitos y librerı́as
Antes de poder instalar la versión standalone de la interfaz gráfica de Ciclope Alarms,
hace falta instalar un contenedor de servlets java. Hay muchas soluciones: dentro de las
soluciones de software libre existen tomcat, JBoss y JOnAS, dentro de las soluciones
comerciales existen IBM Websphere, Bea Weblogic, . . . .
Por ejemplo, si se elige tomcat, se puede instalar ejecutando el comando siguiente
apt-get install tomcat5.5 tomcat5.5-admin
El lector está invitado a consultar la documentación especı́fica del contenedor elegido
para configurar éste debidamente.
Hace falta instalar la herramienta de compilación para Java, ant.
apt-get install ant
Para funcionar correctamente, la interfaz gráfica necesita un conjunto de librerı́as, que
se detalla en la tabla 6.2. Aún ası́, las librerı́as necesarias están disponibles en la carpeta
lib/ de las fuentes, como explicado en la sección 6.4.2, por lo cual no es imprescindible
instalarlas por separado.
Tabla 6.2: Librerı́as necesarias para la interfaz gráfica
Librerı́a
GWT
Ibatis
Junit
Log4J
JavaMail
Versión
1.5.3
URL
http://google-web-toolkit.googlecode.com/files/
gwt-linux-1.5.3.tar.bz2
2.3.4.726 http://community.ebuyershield.com/apache/ibatis/
binaries/ibatis.java/ibatis-2.3.4.726.zip
3.8.2
http://sourceforge.net/project/showfiles.php?group
id=15278&package id=12472&release id=398352
1.2.15
http://www.apache.org/dyn/closer.cgi/logging/log4j/
1.2.15/apache-log4j-1.2.15.tar.gz
1.4.2
ViewProductDetail-Start?ProductRef=javamail-1.4.
2-oth-JPR@CDS-CDS Developer
95
activation
1.1.1
Driver MySQL
3.0.17
6.4.2.
ViewProductDetail-Start?ProductRef=jaf-1.1.
1-fcs-oth-JPR@CDS-CDS Developer
http://dev.mysql.com/get/Downloads/Connector-J/
mysql-connector-java-3.0.17-ga.tar.gz/from/pick
Instalación
Las fuentes de la interfaz gráfica se pueden encontrar en la URL:http://castro.svn.
sourceforge.net/viewvc/castro/trunk/Alarms/AlarmConfigurator.tar.gz?view=tar.
Los pasos a seguir para instalar el motor de alarmas son los siguientes:
1. Bajar las fuentes.
wget http://castro.svn.sourceforge.net/viewvc/castro/trunk/Alarms/
AlarmConfigurator.tar.gz -O AlarmConfigurator.tar.gz
2. Descomprimir las fuentes.
tar -xzvf AlarmConfigurator.tar.gz && cd AlarmConfigurator
3. Configurar el acceso a base de datos. Hace falta modificar el fichero de configuración adecuado.
gedit src/org/ciclope/db/alarms/SqlMapConfigAlarms.xml
A continuación se enseña un ejemplo del fichero de configuración SqlMapConfigAlarms.xml, señalando las partes que tienen que ser cambiadas.
..
<property name="JDBC.ConnectionURL"
value="jdbc:mysql://(ip:puerto del
servidor de base de datos)/(nombre de la base de datos)" />
<property name="JDBC.Username" value="nombre de usuario" />
<property name="JDBC.Password" value="password" />
..
4. Configurar el acceso a un servidor de correo. Hace falta modificar el fichero de
configuración adecuado.
gedit src/org/ciclope/server/alarms/user/user.properties
A continuación se enseña un ejemplo del fichero de configuración user.properties:
mail.from= ## cuenta de correo (usuario@provedor)
mail.from.ky= ##password
# GMail
mail.smtps.host:smtp.gmail.com ## cambiar por la IP del servidor SMTP
mail.smtps.auth:true
5. Compilar las fuentes, utilizando el script de gwt.
96
./AlarmConfigurator-compile
6. Construir el archivo desplegable war, utilizando ant.
ant war
7. Desplegar el .war en el contenedor de servlets java escogido. La realización de este
paso depende fuertemente del tipo de contenedor escogido. En el caso de tomcat,
se recomienda el uso de la interfaz web tomcat-manager, que permite desplegar
aplicaciones web en formato .war de manera gráfica.
97
98
Capı́tulo 7
Conclusión
En este último capı́tulo, se exponen las conclusiones que se han sacado de la realización del Proyecto Fin de Carrera, ası́ como las lı́neas de futuras investigaciones posibles
con vistas a mejorar el sistema implementado.
7.1.
Conclusiones generales
Los objetivos fijados al inicio de este Proyecto Fin de Carrera eran,
Aumentar la visibilidad de la estación meteorológica, publicando sus datos a través
de Internet.
Dotar al Observatorio de un gestor de alarmas que permita la monitorización del
mismo a partir de los datos proporcionados por la estación.
El segundo objetivo tenı́a relación con los objetivos adicionales siguientes:
Configuración dinámica de alarmas vı́a el portal web Ciclope Astro.
Carácter genérico de la solución: Ciclope Alarms tiene que permitir la monitorización simultánea de varios observatorios.
Carácter extensible de la solución: el sistema se podrá ampliar fácilmente para incluir otras fuentes de de variables de monitorización (e.g. sensores) ası́ como otros
tipos de acciones a realizar.
Uso de software libre.
En cuanto a la realización del primer objetivo, se dio de alta y configuró la estación
meteorológica de la facultad en los servicios Awekas, CWOP, PWS y Wunderground,
documentando los pasos seguidos en el capı́tulo 3.
La realización del segundo objetivo fue más larga, necesitó, además del estudio del
estado del arte, una fase de toma de requisitos, una fase de diseño, una de implementación y por fin una fase de integración. A nivel de gestión de proyecto, se intentó mantener
un ciclo de vida por iteraciones cortas validadas por demos, por lo cual las fases de toma
99
de requisitos, diseño e implementación no fueron secuenciales sino más bien se complementaron una a otra, las demos permitieron a veces identificar problemas en los requisitos
o en el diseño y ası́ mejorar la calidad del sistema final.
En cuanto al cumplimiento de objetivos secundarios, cabe destacar que los objetivos
relacionados con implementar un sistema genérico y fácilmente extensible se tomaron
en cuenta desde la fase de diseño. Se han incluido en la sección 4.4 notas para realizar
las extensiones futuras previstas i.e. inclusión de otros observatorios, de nuevos tipos de
acciones o de otras fuentes de variables de monitorización.
Se utilizó exclusivamente software libre: Drools (licencia Apache), Ibatis, Google
Web Toolkit, Commons-Daemon (Apache), . . . , el software desarrollado está publicado
bajo la licencia GNU GPL versión 3 [25] y el presente documento bajo la licencia GNU
FDL versión 1.3 [26].
7.2.
Futuras Mejoras
Como se ha explicado en la sección 4.1, la fase de toma de requisito fue bastante
extensa, al tener ciclos iterativos de entrega. A lo largo de este proceso, se decidió excluir
del ámbito de esta entrega una serie de requisitos que podrı́an ampliar, en el futuro, la
funcionalidad entregada en el marco de este Proyecto Fin de Carrera.
A continuación se detallan algunos de estos requisitos, u otras áreas que podrán ser
exploradas en el ámbito de futuros trabajos.
7.2.1.
Soporte de lógica borrosa
La lógica borrosa está extensivamente utilizada en todas las áreas de control industrial
(control de plantas por ejemplo), con bastante éxito. Los conceptos de lógica borrosa se
aplicarı́an bastante bien al campo estudiado en este Proyecto Fin de Carrera dado que se
puede ver bajo un enfoque de control industrial (control de un Observatorio Astronómico,
con sus sensores y actuadores asociados). Las condiciones de activación de alarmas se
podrı́an definir con términos más entendibles como (si viento alto, entonces cerrar cúpula), delegando la tarea de definir los modelos borrosos a usuarios avanzados por ejemplo.
La utilización de lógica borrosa se descartó del ámbito de esta entrega bastante rápidamente por la complejidad adicional que implica. Da claramente terreno suficiente para
otro Proyecto Fin de Carrera.
Dada la complejidad que pueda llegar a tener la configuración de una alarma utilizando lógica borrosa, se sugiere la posibilidad de tener un modo básico (permitiendo solo
lógica booleana) y un modo avanzado con lógica borrosa.
7.2.2.
Añadir de nuevos observatorios, tipos de acciones y fuentes de
variables de monitorización
Estas áreas no son exactamente mejoras al sistema sino extensiones previstas de antemano. Parte de la realización del presente Proyecto Fin de Carrera fue dedicada a facilitar
100
estas inclusiones futuras, minimizando el esfuerzo y tiempo necesarios a implementarlas.
El lector interesado en este tema puede dirigirse a la sección 4.4 de este documento.
7.2.3.
Mejoras a la parte de edición de alarmas
Se podrı́an implementar las siguientes mejoras a la parte de edición de alarmas del
sistema, en orden de prioridad decreciente:
Permitir la definición de condiciones lógicas sobre la evolución histórica de una
variable (meteorológica o no):
• Media, min, max durante los últimos X minutos/horas.
• Diferencia relativa entre el momento presente y hace X min/horas.
• Derivada de una variable.
Incluir la posibilidad de insertar condiciones por defecto (ocultas o no) según los
casos(e.g. cúpula abierta) durante la creación de alarmas. Los casos exactos se
tendrı́an que definir, lo que se podrá hacer probablemente basándose en la experiencia del uso real del sistema.
Refinar el modelo Alarma/Suscripción añadiendo la posibilidad de definir alarmas
”multi-usuarios”(creando tal vez grupos de usuarios, o reutilizando las funciones
de contactos ya implementadas en Ciclope Astro).
Extender el carácter Público/Privado de una alarma, añadiendo la posibilidad para
el usuario (si tiene permisos suficientes) de restringir la visibilidad de una alarma a
un perfil en concreto (e.g. admin).
Favorecer la reutilización de alarmas ya definidas, impidiendo al usuario que creara una alarma idéntica a una ya definida en el sistema (bien sea por él o por otro
usuario). En caso de que lo intente, el sistema le propondrı́a suscribir a la alarma
ya definida. Este punto plantea unas insospechadas dificultades técnicas (hace falta identificar condiciones lógicas equivalentes pero expresadas de formas distintas,
problema no trivial y probablemente asociado a un coste computacional no despreciable).
Añadir la posibilidad de activar/desactivar las acciones dentro de una alarma o suscripción además de poder activar/desactivar la alarma en su totalidad.
7.2.4.
Mejoras a la parte de administración
Se podrı́an implementar las siguientes mejoras a la parte administración del sistema,
en orden de prioridad decreciente:
Añadir la posibilidad de activar/desactivar un tipo de acción (e.g. SMS, correo
electrónico) en vez de todo el sistema.
101
Cuando un administrador desactiva o reactiva una alarma, enviar un correo electrónico automáticamente a los usuarios afectados.
Añadir la posibilidad de asociar un tipo de acción a los horarios de apertura del
observatorio. De esta manera un tipo de acción sólo se realizarı́a dentro del horario
definido.
Añadir un módulo de gestión de las acciones: el administrador podrı́a crear dinámicamente nuevos tipos de acciones, subiendo un fichero de script en modo texto (o
porque no un ejecutable java .jar).
Refinar el modelo de excepciones: en esta entrega, las excepciones definidas a nivel
de usuario solo pueden restringir los permisos definidos a nivel de perfil. Podrı́a ser
interesante permitir la definición de excepciones más permisivas en determinados
casos pero se tendrı́a que diseñar una interfaz adecuada para que el administrador
conserve siempre el control de la situación (en particular identificar rápidamente
los casos de excepciones permisivas).
Mejorar la usabilidad de la definición de receptores de una acción, convirtiendo las
listas de selección de los mismos en listas de elección múltiple.
102
Apéndice A
Enabling
Wunderground/WeatherForYou
frequency configuration in wview
A.1.
Objectives
The main objective of the changes proposed here is to allow the user to configure the
frequency of consecutive submissions to the weather programs Personal weather stations
(i.e. WeatherForYou and WeatherHam) and Weather Underground (referred to as Wunderground).
In version 4.0.1 which has been taken as the base reference for the changes performed,
all HTTP submissions to these programs are automatically synchronized with the creation of internal archives. One concrete problem is that Weather Underground programs
suggests 1 that data should only be sent at a maximum frequency of every 30 minutes.
In order to comply with this restriction, the only solution is to set the archive interval
to 30 minutes, which was in our case unacceptable (we store data every five minutes and
are very pleased with this behaviour).
A.2.
Short description of desired behaviour
The desired behaviour is the following one.
1. The user configures time intervals for both programs - independently - using the
automatic configuration script wviewconfig.sh.
2. These interval values are stored in configuration file http.conf.
3. wview sends the data to each program at the configured frequency with an offset
calculated the same way as for CWOP program (taking into account last digit/character of station id) in order to perform some load-balancing on respective programs
servers.
1
http://www.pwsweather.com/faqs.php#How-often-should-I-post-to-the-PWSweather-servers
103
A.3.
Details of implementation
The concrete implementation of aforementioned changes is largely inspired of structure and code of cwop module.
During it, the present author has done its best to respect current coding conventions
and existing structures wherever it was possible to do so.
It was finally necessary to modify the following files:
http/http.c.
http/http.h.
common/sysdefs.h.
wviewconfig/wviewconfig.sh.
Most of the changes are located in http.c
A.3.1.
http/http.c
The messageHandler method has been changed to be able to:
Store the most recent archive message for later submission based on call sign instead of directly sending it.
The timerHandler method has been changed to be able to:
Check whether data has to been sent to one of the http submission programs (based
on time intervals defined in configuration file and offset of particular station id).
As for cwop, it also checks whether a new archive message has been created since
last submission (in this case, data is not sent).
The Main method has been changed to be able to:
Retrieve INTERVAL and YOUINTERVAL from http.conf file.
Calculate the offset for station id for both programs (same method as in cwop).
Initialize/destroy the timer.
Small other changes have been performed as well. Please refer to the diff file in section
A.4 for exact changes.
A.3.2.
http/http.h
All needed variables for http.c were added here. Following cwop model, HTTP MINUTE INTERVAL
has been defined in this file as well.
104
A.3.3.
common/sysdefs.h
PROC NUM TIMERS changed from 0 to 1.
A.3.4.
wviewconfig/wviewconfig.sh
Minimal changes to be able to store values for INTERVAL and YOUINTERVAL in
configuration file http.conf
A.4.
Diff report from wview version 4.01
Index: http/http.c
===================================================================
--- http/http.c (.../tags/4.0.1%20-%20official) (révision 152)
+++ http/http.c (.../branches/non-Verbose) (révision 152)
@@ -10,7 +10,8 @@
Date
Engineer
Revision
Remarks
07/12/2005
M.S. Teel
0
12/09/2007
M.S. Teel
1
Add WeatherForYou.com
+
01/30/2009
Bruno Piqueras 2
Configuring frequency of
+
data submissions
NOTES:
@@ -57,7 +58,9 @@
CFG_ID_STATIONID
CFG_ID_PASSWORD
CFG_ID_YOUSTATIONID
CFG_ID_YOUPASSWORD
+ CFG_ID_YOUPASSWORD
+ CFG_ID_INTERVAL = 4,
+ CFG_ID_YOUINTERVAL = 5
};
=
=
=
=
= 3,
0,
1,
2,
3
static char *configIDs[] =
@@ -65,7 +68,9 @@
"STATIONID",
"PASSWORD",
"YOUSTATIONID",
"YOUPASSWORD"
+ "YOUPASSWORD",
+ "INTERVAL",
+ "YOUINTERVAL"
};
/* ... methods
@@ -77,7 +82,7 @@
return size*nmemb;
}
-static void processWUNDERGROUND (WVIEW_MSG_ARCHIVE_NOTIFY *notify)
+static void processWUNDERGROUND ()
{
RADSOCK_ID
socket;
time_t
ntime;
@@ -91,7 +96,10 @@
char
curlError[CURL_ERROR_SIZE];
char
tempBfr[194];
float
rainIN = sensorAccumGetTotal (httpWork.rainAccumulator);
+ volatile WVIEW_MSG_ARCHIVE_NOTIFY
Notify;
+ memcpy ((void*)&Notify, (void*)&httpWork.ArchiveMsg, sizeof(WVIEW_MSG_ARCHIVE_NOTIFY));
+
// format the WUNDERGROUND data
ntime = time (NULL);
gmtime_r (&ntime, &gmTime);
@@ -104,31 +112,31 @@
gmTime.tm_hour, gmTime.tm_min, gmTime.tm_sec);
// check for any wind registered
if (notify->wspeed >= 0 || notify->hiwspeed >= 0)
+ if (Notify.wspeed >= 0 || Notify.hiwspeed >= 0)
{
length += sprintf (&httpBuffer[length], "&winddir=%3.3d", notify->winddir);
+ length += sprintf (&httpBuffer[length], "&winddir=%3.3d", Notify.winddir);
}
-
length += sprintf (&httpBuffer[length], "&windspeedmph=%3.3d",
(notify->wspeed >= 0) ? notify->wspeed : 0);
105
+ (Notify.wspeed >= 0) ? Notify.wspeed : 0);
length += sprintf (&httpBuffer[length], "&windgustmph=%3.3d",
(notify->hiwspeed >= 0) ? notify->hiwspeed : 0);
+ (Notify.hiwspeed >= 0) ? Notify.hiwspeed : 0);
if (notify->humidity >= 0 && notify->humidity <= 100)
+ if (Notify.humidity >= 0 && Notify.humidity <= 100)
{
length += sprintf (&httpBuffer[length], "&humidity=%d", notify->humidity);
+ length += sprintf (&httpBuffer[length], "&humidity=%d", Notify.humidity);
}
length += sprintf (&httpBuffer[length], "&tempf=%3.3d.%1.1d",
notify->temp/10, notify->temp%10);
+ Notify.temp/10, Notify.temp%10);
length += sprintf (&httpBuffer[length], "&rainin=%.2f", rainIN);
length += sprintf (&httpBuffer[length], "&baromin=%2.2d.%2.2d",
notify->barom/1000, (notify->barom%1000)/10);
+ Notify.barom/1000, (Notify.barom%1000)/10);
length += sprintf (&httpBuffer[length], "&dewptf=%2.2d.%3.3d",
notify->dewpoint/10, (notify->dewpoint%10)*100);
+ Notify.dewpoint/10, (Notify.dewpoint%10)*100);
strcpy (version, globalWviewVersionStr);
version[5] = ’-’;
@@ -168,7 +176,7 @@
return;
}
-static void processWEATHERFORYOU (WVIEW_MSG_ARCHIVE_NOTIFY *notify)
+static void processWEATHERFORYOU ()
{
RADSOCK_ID
socket;
time_t
ntime;
@@ -182,7 +190,10 @@
char
curlError[CURL_ERROR_SIZE];
char
tempBfr[194];
float
rainIN = sensorAccumGetTotal (httpWork.rainAccumulator);
+ volatile WVIEW_MSG_ARCHIVE_NOTIFY
Notify;
+ memcpy ((void*)&Notify, (void*)&httpWork.ArchiveMsg, sizeof(WVIEW_MSG_ARCHIVE_NOTIFY));
+
// format the WEATHERFORYOU data
ntime = time (NULL);
gmtime_r (&ntime, &gmTime);
@@ -195,30 +206,30 @@
gmTime.tm_hour, gmTime.tm_min, gmTime.tm_sec);
// check for any wind registered
if (notify->wspeed >= 0 || notify->hiwspeed >= 0)
+ if (Notify.wspeed >= 0 || Notify.hiwspeed >= 0)
{
length += sprintf (&httpBuffer[length], "&winddir=%3.3d", notify->winddir);
+ length += sprintf (&httpBuffer[length], "&winddir=%3.3d", Notify.winddir);
}
length += sprintf (&httpBuffer[length], "&windspeedmph=%d.0",
(notify->wspeed >= 0) ? notify->wspeed : 0);
+ (Notify.wspeed >= 0) ? Notify.wspeed : 0);
length += sprintf (&httpBuffer[length], "&windgustmph=%d.0",
(notify->hiwspeed >= 0) ? notify->hiwspeed : 0);
+ (Notify.hiwspeed >= 0) ? Notify.hiwspeed : 0);
length += sprintf (&httpBuffer[length], "&tempf=%d.%d",
notify->temp/10, notify->temp%10);
+ Notify.temp/10, Notify.temp%10);
length += sprintf (&httpBuffer[length], "&rainin=%.2f", rainIN);
length += sprintf (&httpBuffer[length], "&baromin=%2.2d.%2.2d",
notify->barom/1000, (notify->barom%1000)/10);
+ Notify.barom/1000, (Notify.barom%1000)/10);
length += sprintf (&httpBuffer[length], "&dewptf=%d.%d",
notify->dewpoint/10, notify->dewpoint%10);
+ Notify.dewpoint/10, Notify.dewpoint%10);
if (notify->humidity >= 0 && notify->humidity <= 100)
+ if (Notify.humidity >= 0 && Notify.humidity <= 100)
{
length += sprintf (&httpBuffer[length], "&humidity=%d", notify->humidity);
+ length += sprintf (&httpBuffer[length], "&humidity=%d", Notify.humidity);
}
strcpy (version, globalWviewVersionStr);
@@ -463,17 +474,15 @@
// Update the rain accumulator
106
+
+
+
+
+
+
+
-
sensorAccumAddSample (httpWork.rainAccumulator, nowTime, anMsg->sampleRain);
// Just store the most recent for later submission based on call sign
memcpy ((void*)&httpWork.ArchiveMsg, anMsg, sizeof(WVIEW_MSG_ARCHIVE_NOTIFY));
httpWork.rxFirstArchive = TRUE;
httpWork.rxArchive = TRUE;
httpWork.yourxFirstArchive = TRUE;
httpWork.yourxArchive = TRUE;
return;
// process http data transfer
if (strcmp (httpWork.stationId, "0"))
{
processWUNDERGROUND (anMsg);
}
if (strcmp (httpWork.youstationId, "0"))
{
processWEATHERFORYOU (anMsg);
}
}
else if (msgType == WVIEW_MSG_TYPE_POLL)
{
WVIEW_MSG_POLL*
pPoll = (WVIEW_MSG_POLL*)msg;
@@ -496,6 +505,73 @@
static void timerHandler (void *parm)
{
+ time_t
ntime;
+ struct tm
locTime;
+
+ ntime = time (NULL);
+ localtime_r (&ntime, &locTime);
+
+ //Initializing timer: it will be triggered at HTTP_MINUTE_INTERVAL frequency
+ //i.e. by default each minute
+ radProcessTimerStart (httpWork.timer, HTTP_MINUTE_INTERVAL);
+
+ //Weather Underground first
+ //Do we have to send data to Wunderground? => checking localtime and comparing to interval
+ if ((locTime.tm_min % httpWork.reportInterval) == (httpWork.stationIdOffset % httpWork.reportInterval))
+ {
+ radMsgLog (PRI_STATUS, "*** timerHandler - Temporal condition checked for Weather Underground...");
+ // Time to send a packet if we have any new data:
+ if (httpWork.rxArchive)
+ {
+ //process http data transfer
+ if (strcmp (httpWork.stationId, "0"))
+ {
+ processWUNDERGROUND ();
+ httpWork.rxArchive = FALSE;
+ }
+ }
+ else
+ {
+ if (httpWork.rxFirstArchive)
+ {
+ radMsgLog (PRI_MEDIUM,
+ "wvhttpd: no new archive data received since last submission to Weather Underground");
+ }
+ else{
+ radMsgLog (PRI_STATUS, "timerHandler - Weather Underground: rxArchive and rxFirstArchive FALSE");
+ }
+ }
+ }
+
+
+ //Now, weather for you
+ if ((locTime.tm_min % httpWork.youreportInterval) == (httpWork.youstationIdOffset % httpWork.youreportInterval))
+ {
+ radMsgLog (PRI_STATUS, "*** timerHandler - Temporal condition checked for Weather For You...");
+ // Time to send a packet if we have any new data:
+ if (httpWork.yourxArchive)
+ {
+ // process http data transfer
+ if (strcmp (httpWork.youstationId, "0"))
+ {
+ processWEATHERFORYOU ();
+ httpWork.yourxArchive = FALSE;
+ }
+ }
+ else
+ {
+ if (httpWork.yourxFirstArchive)
+ {
+ radMsgLog (PRI_MEDIUM,
+ "wvhttpd: no new archive data received since last submission to Weather for You:");
+ }
+ else{
+ radMsgLog (PRI_STATUS, "timerHandler - Weather for You: yourxArchive and yourxFirstArchive FALSE");
+ }
+ }
+ }
107
+
+
return;
}
@@ -624,6 +700,17 @@
else
{
strcpy (httpWork.stationId, value);
+ //Computing offset of Wunderground station id
+ //last digit % 10 or if char last digit of ASCII integer code
+ if (value[strlen(value)-1] >= ’0’ && value[strlen(value)-1] <= ’9’)
+ {
+ httpWork.stationIdOffset = atoi(&value[strlen(value)-1]);
+ }
+ else
+ {
+ httpWork.stationIdOffset = (value[strlen(value)-1] % 10);
+ }
+ httpWork.stationIdOffset %= 10;
strcpy (httpWork.password, "0");
}
@@ -644,6 +731,37 @@
strcpy (httpWork.password, value);
}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
// get the interval between two consecutive submissions to Wunderground
if (radCfGetFirstEntry (configFileId,
configIDs[CFG_ID_INTERVAL],
instance,
value)
== ERROR)
{
// we can’t do without this!
radMsgLog (PRI_CATASTROPHIC, "%s not found: WUNDERGROUND set to disabled", configIDs[CFG_ID_INTERVAL]);
strcpy (httpWork.stationId, "0");
strcpy (httpWork.password, "0");
}
else
{
int
n;
char * end;
n = strtol(value, &end, 10);
if (*end == ’\0’)
{
/* String entirely been converted */
httpWork.reportInterval = n;
}
else
{
/* String contains at least one character that cannot be converted to a number */
radMsgLog (PRI_CATASTROPHIC, "%s not parsed: WUNDERGROUND Interval set to 30 minutes", configIDs[CFG_ID_PASSWORD]);
httpWork.reportInterval = 30;
}
}
// get the YOU STATION ID
configIDs[CFG_ID_YOUSTATIONID],
@@ -658,6 +776,17 @@
else
{
strcpy (httpWork.youstationId, value);
+ //Computing offset of Weather for You station id
+ //last digit % 10 or if char last digit of ASCII integer code
+ if (value[strlen(value)-1] >= ’0’ && value[strlen(value)-1] <= ’9’)
+ {
+ httpWork.youstationIdOffset = atoi(&value[strlen(value)-1]);
+ }
+ else
+ {
+ httpWork.youstationIdOffset = (value[strlen(value)-1] % 10);
+ }
+ httpWork.youstationIdOffset %= 10;
strcpy (httpWork.youpassword, "0");
}
@@ -678,24 +807,68 @@
strcpy (httpWork.youpassword, value);
}
+
+
+
+
+
+
+
+
// get the interval for weather for you
configIDs[CFG_ID_YOUINTERVAL],
instance,
value)
== ERROR)
{
// we can’t do without this!
108
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
radMsgLog (PRI_CATASTROPHIC, "%s not found: WEATHERFORYOU set to disabled", configIDs[CFG_ID_YOUINTERVAL]);
strcpy (httpWork.youstationId, "0");
strcpy (httpWork.youpassword, "0");
}
else
{
int
n;
char * end;
n = strtol(value, &end, 10);
if (*end == ’\0’)
{
/* String entirely been converted */
httpWork.youreportInterval = n;
}
else
{
/* String contains at least one character that cannot be converted to a number */
radMsgLog (PRI_CATASTROPHIC, "%s not parsed: WEATHERFORYOU Interval set to 30 minutes", configIDs[CFG_ID_YOUINTERVAL]);
httpWork.youreportInterval = 30;
}
}
radCfClose (configFileId);
if (strcmp (httpWork.stationId, "0"))
{
radMsgLog (PRI_STATUS, "WUNDERGROUND: configured to submit station %s data to wunderground.com",
httpWork.stationId);
+ radMsgLog (PRI_STATUS,
+ "WUNDERGROUND: configured to submit station %s data every %d minutes with an offset of %d to wunderground.com",
+ httpWork.stationId,httpWork.reportInterval,httpWork.stationIdOffset);
}
if (strcmp (httpWork.youstationId, "0"))
{
radMsgLog (PRI_STATUS, "WEATHERFORYOU: configured to submit station %s data to weatherforyou.com",
httpWork.youstationId);
+ radMsgLog (PRI_STATUS,
+ "WEATHERFORYOU: configured to submit station %s data every %d minutes with an offset of %d to weatherforyou.com",
+ httpWork.youstationId,httpWork.youreportInterval,httpWork.youstationIdOffset);
}
// wait a bit here before continuing
radUtilsSleep (500);
+ //Initializing the httpd timer
+ httpWork.timer = radTimerCreate (NULL, timerHandler, NULL);
+
+
+
+
+
+
+
+
+
+
+
if (httpWork.timer == NULL)
{
radMsgLog (PRI_HIGH, "radTimerCreate failed");
httpSysExit (&httpWork);
radProcessExit ();
radSystemExit (WVIEW_SYSTEM_ID);
exit (1);
}
radProcessTimerStart (httpWork.timer, HTTP_MINUTE_INTERVAL);
// register with the radlib message router
if (radMsgRouterInit (WVIEW_RUN_DIR) == ERROR)
{
@@ -764,6 +937,7 @@
sensorAccumExit (httpWork.rainAccumulator);
radMsgRouterExit ();
+ radTimerDelete (httpWork.timer);
httpSysExit (&httpWork);
radProcessExit ();
radSystemExit (WVIEW_SYSTEM_ID);
Index: http/http.h
===================================================================
--- http/http.h (.../tags/4.0.1%20-%20official) (révision 152)
+++ http/http.h (.../branches/non-Verbose) (révision 152)
@@ -12,6 +12,8 @@
Date
Engineer
Revision
Remarks
07/12/2005
M.S. Teel
0
12/09/2007
M.S. Teel
1
Add WeatherForYou.com
+
01/30/2009
Bruno Piqueras 2
+
data submissions
NOTES:
@@ -61,8 +63,9 @@
#define __DEBUG
TRUE
+//HTTP_MINUTE_INTERVAL (in ms): used to configure timer’s frequency
+#define HTTP_MINUTE_INTERVAL
60000
109
/*
*/
... API definitions
@@ -86,6 +89,16 @@
WV_ACCUM_ID
rainAccumulator;
int
inMainLoop;
int
exiting;
+
TIMER_ID
timer;
+
WVIEW_MSG_ARCHIVE_NOTIFY
ArchiveMsg;
+
int
reportInterval;
+
int
stationIdOffset;
+
int rxFirstArchive;
+
int rxArchive;
+
int
youreportInterval;
+
int
youstationIdOffset;
+
int yourxFirstArchive;
+
int yourxArchive;
} WVIEW_HTTPD_WORK;
/* !!!!!!!!!!!!!!!!!!!! END HIDDEN SECTION !!!!!!!!!!!!!!!!!!!!!
Index: wviewconfig/wviewconfig.sh
===================================================================
--- wviewconfig/wviewconfig.sh (.../tags/4.0.1%20-%20official) (révision 152)
+++ wviewconfig/wviewconfig.sh (.../branches/non-Verbose) (révision 152)
@@ -16,7 +16,7 @@
# J Barber
02/24/06
2
Partitioned into functions; added get/set
# MS Teel
02/25/06
3
Tweaked arg and function names
# MS Teel
06/21/08
4
Better station type support
-#
+# B Piqueras 01/30/09
5
Configuring frequency of HTTP data submissions
################################################################################
@@ -294,6 +294,12 @@
if [ "" = "$YOUPASSWORD" ]; then
YOUPASSWORD=changeME
fi
+
if [ "" = "$INTERVAL" ]; then
+
INTERVAL=changeME
+
fi
+
if [ "" = "$YOUINTERVAL" ]; then
+
YOUINTERVAL=changeME
+
fi
if [ "" = "$DATE_FORMAT" ]; then
if [ "0" = "$METRIC_UNITS" ]
then
@@ -364,6 +370,8 @@
echo PASSWORD=$PASSWORD
echo YOUSTATIONID=$YOUSTATIONID
echo YOUPASSWORD=$YOUPASSWORD
+
echo INTERVAL=$INTERVAL
+
echo YOUINTERVAL=$YOUINTERVAL
echo LOCAL_FORECAST_URL=$LOCAL_FORECAST_URL
echo LOCAL_RADAR_URL=$LOCAL_RADAR_URL
echo DATE_FORMAT=$DATE_FORMAT
@@ -1551,6 +1559,21 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
echo ""
echo "-------------------------------------------------------------"
echo "Frequency - in minutes - of data submission to WUNDERGROUND (e.g. 30):"
echo -n "($INTERVAL): "
read INVAL
if [ "" = "$INVAL" ]; then
if [ "changeME" = "$INTERVAL" ]; then
echo "INTERVAL not specified - disabling WUNDERGROUND!"
STATIONID=0
PASSWORD=0
fi
else
INTERVAL=$INVAL
fi
echo ""
echo "-------------------------------------------------------------"
echo "WEATHERFORYOU Station ID (obtained when you registered with WEATHERFORYOU):"
echo -n "($YOUSTATIONID): "
read INVAL
@@ -1578,6 +1601,22 @@
YOUPASSWORD=$INVAL
fi
+
+
+
+
+
+
+
+
+
echo ""
echo "-------------------------------------------------------------"
echo "Frequency - in minutes - of data submission to WEATHERFORYOU (e.g. 30):"
echo -n "($YOUINTERVAL): "
read INVAL
if [ "" = "$INVAL" ]; then
if [ "changeME" = "$YOUINTERVAL" ]; then
echo "INTERVAL not specified - disabling WEATHERFORYOU!"
YOUSTATIONID=0
110
+
+
+
+
+
+
+
YOUPASSWORD=0
fi
else
YOUINTERVAL=$INVAL
fi
write_http_conf
@@ -1620,6 +1659,10 @@
echo "PASSWORD=$PASSWORD" >> $WVIEW_CONF_DIR/http.conf
echo "" >> $WVIEW_CONF_DIR/http.conf
+
+
+
+
echo "# INTERVAL:" >> $WVIEW_CONF_DIR/http.conf
echo "INTERVAL=$INTERVAL" >> $WVIEW_CONF_DIR/http.conf
echo "# WEATHERFORYOU Station ID:" >> $WVIEW_CONF_DIR/http.conf
echo "YOUSTATIONID=$YOUSTATIONID" >> $WVIEW_CONF_DIR/http.conf
@@ -1628,6 +1671,10 @@
echo "YOUPASSWORD=$YOUPASSWORD" >> $WVIEW_CONF_DIR/http.conf
+
+
+
+
echo "# WEATHERFORYOU INTERVAL:" >> $WVIEW_CONF_DIR/http.conf
echo "YOUINTERVAL=$YOUINTERVAL" >> $WVIEW_CONF_DIR/http.conf
echo "done."
} # end of write_http_conf
Index: common/sysdefs.h
===================================================================
--- common/sysdefs.h (.../tags/4.0.1%20-%20official) (révision 152)
+++ common/sysdefs.h (.../branches/non-Verbose) (révision 152)
@@ -15,7 +15,10 @@
CONS_ARCHIVE_INTERVAL
01/10/2006
M.S. Teel
2
Update for station
abstraction
+
01/30/2009
Bruno Piqueras 3
+
data submissions
+
NOTES:
@@ -94,7 +97,7 @@
#define CWOP_CONFIG_FILENAME
"wvcwop.conf"
#define
-#define
+#define
#define
"wvhttpd"
0
1
"http.conf"
PROC_NAME_HTTP
PROC_NUM_TIMERS_HTTP
PROC_NUM_TIMERS_HTTP
HTTP_CONFIG_FILENAME
#define PROC_NAME_SQLD
"wviewsqld"
Modification de propriétés sur .
___________________________________________________________________
Nom : svn:ignore
+
*.project
111
112
Apéndice B
Informe: Soluciones para mandar SMS
automáticamente
Introducción
El objetivo de este informe es estudiar las distintas soluciones disponibles para conseguir, en el ámbito de la monitorización de la estación meteorológica, los siguientes
objetivos:
Ser capaces de mandar SMS de manera automática (e.g. cuando se dispara una
alarma).
La solución debe ser 100 % compatible GNU/Linux.
Hay básicamente tres maneras de enfocar el problema:
1. Mandar los SMS gracias a un módem GSM.
2. Mandar los SMS gracias a un móvil convencional.
3. Utilizar servicios on-line (SMS Gateways) para mandar los SMS.
A continuación, se detallan, para cada tipo de solución, las soluciones concretas ası́ como los costes asociados para ayudar a tomar una decisión de compra. En la sección B.5,
se hará un repaso de las distintas soluciones ası́ como las ventajas e inconvenientes de
cada una.
B.1.
Módems GSM
Hay tres tipos de módems GSM capaces de mandar SMS:
Módem interno - o ’módulo’ (circuitos impresos).
Módem externo - o ’terminal’ (conexión serie RS-232).
113
Módem externo (conexión USB).
Cabe destacar, que para algunos modelos, es preciso adquirir, en complemento al propio módem, accesorios vendidos por separado tales como una antena GSM, un módulo
de lectura de tarjeta SIM, una fuente de alimentación. . . Otros modelos si incluyen éstos
(o no lo requieren).
El estudio se centró en los modelos siguientes1 , algunos de los cuales están recomendados por ozekisms[56], un SMS Gateway profesional:
Siemens/Cinterion2 TC65T (externo serie).
Siemens/Cinterion MC/TC35T (externo serie)3 .
Wavecom Fastrack M1306B (externo serie).
Wavecom Fastrack Supreme 10/20 (externo serie).
Huawei E220 (externo USB).
B.1.1.
Compatibilidad con GNU/Linux
De una manera general, los módems con conexión serie tienen más probabilidad de
ser correctamente reconocidos por el kernel Linux. Los módems USB pueden dar más
problemas, aún ası́ las versiones más recientes del kernel pueden llegar a reconocerlos.
Tabla B.1: Compatibilidad GNU/Linux de los modelos de
módems
Modelo
Siemens TC65T
Siemens TC/MC35T
Wavecom Fastrack M1306B
Compatibilidad Fuente
Sı́, en parte4
http://cihar.com/gammu/phonedb/
siemens/
http://www.xargs.com/
linux/tc65-linux.html
Sı́
http://www.celtius.com/globalpics/
usersguide/usersguide.pdf
http://archive.netbsd.se/?ml=
soekris-tech&a=2008-04&t=
7057159
Sı́
http://www.comm-co.com/
jm/index.php/GSM-Modems/
WaveCom-Fastrack-M1306B.html
http://www.queret.net/wiki/index.
php/Linux/How-to/WaveCom
1
Se descartaron modelos muy sofisticados/caros y se centró en modelos con mayor presencia en la web
o con mayor número de testimonios de utilización en Linux.
2
Siemens Wireless pasó a ser una empresa independiente llamada Cinterion. Aún ası́, se sigue utilizando
la marca Siemens.
3
Mayor ancho de banda (GPRS) para MC35 comparado con TC35, para SMS no deberı́a notarse.
4
Permite embeder Java, pero la instalación requiere Windows.
114
Wavecom Fastrack Supreme 10/20
Huawei E220
B.1.2.
Sı́
Kernel>2.6.20
http://ascendantcsi.com/ascendant/
xmlhttp/products.xhtml
http://es.wikipedia.org/wiki/
Huawei E220#Sistemas operativos
http://designbuildtestrepeat.
wordpress.com/2008/04/29/
huawei-e220-on-linux-for-sms/
Precios
Se buscaron presupuestos para los modelos de módems previamente mencionados de
tres maneras distintas:
Contactando directamente5 los distribuidores oficiales para estos modelos.
Buscando en tiendas on-line.
En e-bay - a titulo indicativo, las ofertas pudiendo variar de un dı́a a otro.
Los distribuidores oficiales de Siemens/Cinterion[16] son, en España:
Matrix Electrónica.
Xacom.
Anatronic.
Wavecom tiene un único distribuidor en España [68]: Diode.
Huawei por lo visto no tiene distribuidor oficial. Aún ası́, el modelo Huawei E220 es
fácil de encontrar (se trata del estándar de facto actual de los módems 3G y existe tanto
en versión liberada como sujetada a un contrato con Vodafone, Movistar, Orange, . . . ).
A continuación, se presenta un resumen de los precios de cada modelo según las tiendas. En caso de haber dos precios, el precio más bajo corresponde al módem sin accesorios, el precio más alto al módem más los accesorios (fuente de alimentación, antena y
cable de datos serie).
Tabla B.2: Precios de distintos modelos de módems
Matrix
Xacom
Diode
Anatronic
TC65T
116/133,4C
N/A
N/A
116/131C
TC35T
96/114C
96/114C
N/A
86/101C
Fastrack M1306B Fastrack Supreme Huawei 220
N/A
N/A
N/A
N/A
N/A
N/A
N/A
137/158C
N/A
N/A
N/A
N/A
5
Por una razón desconocida mantienen secretos sus precios y sólo los comunican por correo electrónico
después de haber contactado por teléfono. . .
115
Simyo
gsmpro.de6
wivia.com
blauden.com
ebay
B.2.
N/A
178/218C
119/150C
169C
N/A
90/130C
105/137C
105/137C
35C
N/A
N/A
80 C
111C
40 C
25C
Móvil convencional
Utilizar un móvil convencional en vez de un módem GSM dedicado puede ser una
solución más barata. Sin embargo, conviene destacar los inconvenientes de tal elección:
Fiabilidad más baja.
Problemas con baterı́a.
Problemas con cargador (algunos cortan la comunicación).
Problemas varios debidos a la complejidad del sw embedido.
Posibilidad de parada no ordenada del móvil (necesidad de un reboot manual).
Menos velocidad para mandar SMS pudiendo ocasionar retrasos.
Muchos modelos de móvil pueden, al menos teóricamente, servir para mandar SMS
desde un ordenador (mediante conexión USB, Bluetooth, u otra). Ozenkisms recomienda
los siguientes modelos:[56]
Tabla B.3: Modelos de móviles recomendados por Ozenkisms
Motorola
Nokia
Samsung Ericsson
Timeport DataSuite 3.0 SHG-E600 GM12
c380
DataSuite 2.0 SHG-E700 A2218
Cardphone
SHG-E800 A2628
Cardphone II
GM12
22
GM22
30
GM25
31
T20
32
T28
3220
T29
3650
T39
5100
T60
6
14C portes.
116
Sony Ericsson Siemens
Z1010
A50
Z600
A55
T28
A60
T68i
C35
T226
C55
T230
M1
T237
M20
T250i
M35
T270
M50
T280
M55
T280i
ME45
5110
5210
6070
6080
6100
6110
6150
6210
6220
6250
6310
6310i
T61
T65
T68
R250
R320
R300
R380
R520
117
T300
T300
T303
T310
T316
T320
T600
T610
T616
T630
T650
T650i
K320
K330
K500
K510i
K530i
K550
K600
K630
K660
K660i
K750i
K770
K770i
K810
K810i
K850
K850i
W550i
W580i
W600i
W800i
R380
R600
P800
P900
MC60
S25
S35
S45i
S55
SL45
SL45i
SL55
ST55
ST60
2128
3508
U10
SX1
Partiendo de la lista precedente y comprobando la compatibilidad en la página http:
//cihar.com/gammu/phonedb/[75], se reducen las opciones a la tabla siguiente.
Tabla B.4: Móviles compatibles con GNU/Linux
Nokia Sony Ericsson Siemens
3220
Z1010
A60
3650
Z600
C55
5110
T68i
M55
6070
T230
ME45
6080
T610
MC60
6100
T630
S55
6210
T650i
SL45i
6220
K510i
6310
K530i
6310i
K660i
K750i
K810i
K850i
W550i
W580i
W800i
P800
De una manera general, se recomendarı́a en prioridad la marca Nokia, por la mayor
compatibilidad constatada empı́ricamente (véase enlaces presentados a continuación) y el
éxito del proyecto gnokii[28]. Para temas de configuración y/o compatibilidad con Linux,
se recomiendan los siguientes enlaces:
http://doc.ubuntu-fr.org/gsm-nokia
http://www.gnokii.org/[28]
http://doc.ubuntu-fr.org/sms-via-gsm
http://doc.ubuntu-fr.org/gammu
http://doc.ubuntu-fr.org/gnome-phone-manager
http://cihar.com/gammu/phonedb/
A nivel de precio, utilizar un móvil puede ser una opción menos costosa que un
módem GSM profesional. Sin embargo, dado que el móvil necesita permitir algún tipo
de conexión con el ordenador bien sea por USB, bluetooth o infrarrojos, y que tendrı́a en
el caso ideal que estar liberado (o de tarjeta como mucho), los precios no son tan bajos.
Algunas de las ofertas más interesantes encontradas en Internet incluyen7 :
7
El lector atento se habrá percatado de que los móviles no están en la lista presentada antes. No están
recomendados por ozekisms[56] pero están en la lista de compatibilidad de Gammu[75].
118
Un Nokia 2630/2760 a 49 C:http://tiendamovil.orange.es/moviles-nokia-tarjeta-de%
200%20a%2049.htm.
Un Sony Ericsson a 60C:http://www.maxmovil.com/tienda/index.php?page=pp producto.
php&md=0&codp=3869.
B.3.
Tarifas GSM Operadoras clásicas
Tanto para la solución involucrando un módem GSM como para su variante con un
móvil convencional, hace falta contratar los servicios de una operadora telefónica para
mandar SMS. En el caso de los módems, un compartimento dedicado suele permitir la
inserción de una tarjeta SIM.
A continuación se presenta algunas de las ofertas actuales dignas de interés dados
nuestros objetivos. Dicho estudio fue elaborado en parte gracias a la página web gsmspain.com [31].
B.3.1.
Movistar
Tarjeta Movistar: 15 c/SMS IVA inc., sin cuota.
Tarjeta Mi Gente: 10 c/SMS IVA inc. con números favoritos (hasta 5),15 c/SMS
IVA inc. para otros destinos nacionales, sin cuota.
Opción ahorro Nacional : club SMS: 2 euros/mes, 50 % descuento hacia Movistar.
Opción Mi favorito: alta 7 euros, sin cuota, 7 c/SMS IVA inc.
B.3.2.
Vodafone
Tárifas SMS (nacional): 17 c/SMS IVA inc. Posibilidad de comprar SMS por lotes
(bonos) pero tienen una validez de un mes 200 SMS por 20,88 C IVA inc. http://www.
vodafone.es/particulares/servicios/sms/ahorra/index.jsp
B.3.3.
Orange
Contrato SMS: 9 C/mes, 150 SMS (los siguientes 15c/SMS).
Tarjeta SMS: 15c/SMS (descuentos hacia Orange).
B.3.4.
Yoigo
Tarjeta 1: 10c/SMS pero 6 euros consumo min mensual.
Tarejta 2: id. pero no hay consumo min.
Tarjeta 8: 8c/SMS pero 6 euros consumo min mensual.
119
B.3.5.
Operadores virtuales
Tarjeta Simyo: 9c/SMS.
Tarjeta Blau: 8c/SMS, 2C min./mes.
Tarjeta Eroski: 10c/SMS.
Tarjeta pepephone: 10c/SMS.
B.4.
Servicios on-line
Otra solución para mandar SMS consiste en contratar servicios a empresas especializadas, delegándoles la tarea de enviar los SMS. Dicha solución tiene la ventaja de no
necesitar ningún tipo de hardware adicional. Sin embargo, se pierde en flexibilidad y sobretodo, en caso de escoger esta solución, se creará una dependencia futura con la empresa
escogida.
También existen servicios en Internet totalmente gratuitos para mandar SMS (pero
con limitaciones) y hasta software que automatiza el envı́o hacia éstos, pero proporciona
muy poca fiabilidad por lo que se descartó esta solución.
A continuación se presenta algunas de las ofertas comerciales serias para mandar SMS
a través de Internet. Los protocolos concretos para interactuar con ellos y mandar los SMS
varı́an ligeramente de uno a otro pero el concepto es parecido (HTTP, API proporcionadas
por la empresa, . . . )
Altiria: http://www.altiria.com/web/sms mms/pasarela envio sms 12c/SMS sin IVA.
Movilia: http://www.movilia.com/info/inf cost.jsp 12c/SMS sin IVA.
Descom SMS: http://www.descomsms.com/tarifas lssi1.html 11.5c/SMS, posibilidad de comprar lotes de caducidad un mes.
http://www.smspubli.com/precios/, 2 niveles de fiabilidad el más caro 11c/SMS,
API SMPP/HTTP.
http://www.clickatell.com/pricing/message cost.php, APIs diversas 9c/SMS.
120
B.5.
Conclusión
Las ventajas e inconvenientes de cada tipo de solución se pueden resumir en la tabla B.5.
Tabla B.5: Ventajas e inconvenientes de cada tipo de solución
SMS
Solución
Módem GSM
Ventajas
Gran fiabilidad
Independencia
Móvil Convencional Más barato que un módem GSM
Gateway SMS
HW no necesario
Inconvenientes
Hardware algo costoso
Fiabilidad reducida
Dependencia con empresa
contratada
Fiabilidad a demostrar
Por estas razones, y teniendo en cuenta los objetivos ası́ como las exigencias económicas y tecnológicas, clasificarı́a las soluciones propuestas en el orden de preferencia siguiente:
1. Módem GSM - Más fiable, más independiente:
a) TC/MC35iT - fiable, sencillo, eficaz.
b) Wavecom Fastrack Supreme/M1306B - buenos testimonios.
c) TC65T- fiable, completo, pero Windows necesario para instalar J2ME 8 .
2. Móvil convencional.
3. SMS Gateway.
8
No imprescindible, nos podemos conformar con los comandos AT.
121
122
Apéndice C
ERS Ciclope Alarms
C.1.
Introducción
Este documento es una Especificación de Requisitos Software (ERS) para el Sistema
Ciclope Alarms. Esta especificación se ha estructurado basándose en las directrices dadas
por el estándar IEEE 830, 1998 [35].
C.1.1.
Propósito
El objeto de la especificación es definir de manera clara y precisa todas las funcionalidades y restricciones del sistema Ciclope Alarms.
C.1.2. Ámbito del Sistema
El sistema Ciclope Alarms tiene como propósito permitir la monitorización del Observatorio Astronómico de Montegancedo a través de un gestor de alarmas altamente configurable. Los usuarios debidamente habilitados podrán definir alarmas, cuyas condiciones
de activación involucrarán las variables accesibles en lectura al sistema. En el ámbito
de esta entrega, se tratará de las variables meteorológicas colectadas por la estación meteorológica[14]. A más largo plazo, se prevé incluir otras variables tales como sensores
fı́sicos asociados a la cúpula del observatorio. El sistema será capaz de llevar a cabo determinadas acciones tales como mandar un correo electrónico o un mensaje SMS.
La GUI del sistema se tendrá que integrar en el portal web Ciclope Astro[12]. Aunque
tenga que ser lo suficientemente genérico como para permitir la monitorización de varios
observatorios astronómicos a la vez, en el ámbito de esta entrega, el sistema se integrará en
el Observatorio Astronómico de Montegancedo.
C.1.3.
Definiciones, Acrónimos y Abreviaturas
C.1.3.1.
Definiciones
Usuario: Un usuario habilitado a utilizar el sistema Ciclope Alarms. Tiene que ser
registrado como usuario del portal Ciclope Astro.
123
Administrador: Un usuario habilitado a administrar el sistema Ciclope Alarms. Tiene que ser administrador del portal Ciclope Astro.
Perfil/Rol de Usuario: Cada perfil o rol de usuario corresponde a una categorı́a
determinada de usuario. Existen cuatro perfiles: admin, basic, advanced y demo.
Corresponden con los perfiles definidos en el portal Ciclope Astro.
Activación de alarma: Salvo mención explı́cita de lo contrario, por activación de una
alarma, se referirá al momento cuando se cumplen las condiciones lógicas definidas
para la alarma.
Ejecución de alarma: Salvo mención explı́cita de lo contrario, por ejecución de
una alarma, se referirá al momento cuando se ejecutan las acciones definidas para
la alarma. Una ejecución necesita una activación previa pero la activación de una
alarma no implica necesariamente su ejecución.
C.1.3.2.
Acrónimos
ERS: Especificación de Requisitos Software (SRS en inglés).
MAO: Montegancedo Astronomical Observatory.
SMS: Short Message Service.
OSS: Open Source Software.
GNU: GNU is Not Unix.
GNU FDL: GNU Free Documentation License.
GNU GPL: GNU General Public License.
GUI: Graphical User Interface.
C.1.3.3.
Abreviaturas
C.1.4.
Referencias
Estándar IEEE 830[35]
C.1.5.
Visión general del Documento
Este documento consta de tres secciones. La sección C.1 es la Introducción y proporciona una visión general de la ERS. En la sección C.2 se da una descripción general del
sistema, con el fin de conectar las principales funciones que deberá realizar, los datos asociados y los factores, restricciones, supuestos y dependencias que afectan al desarrollo,
sin entrar en excesivos detalles. En la sección C.3 se definen detalladamente los requisitos
que deberá satisfacer el sistema.
124
C.2.
Descripción General
C.2.1.
Perspectiva del producto
El sistema Ciclope Alarms, en su primera versión, permitirá la edición de alarmas basadas en condiciones lógicas involucrando variables meteorológicas. Cuando se den las
condiciones de activación de una alarma el sistema ejecutará la (o las) accione(s) asociada(s) dentro de los tres siguientes tipos: mandar un correo electrónico, mandar un mensaje
SMS, o avisar a un usuario conectado al portal Ciclope Astro mediante la aparición de un
popup en su navegador web (o pop-up). En siguientes versiones, se prevé la inclusión de
otros tipos de variables (e.g. sensor de apertura de la cúpula) ası́ como de nuevas acciones
(e.g. abrir/cerrar la cúpula) por lo que el diseño original deberá ser lo suficientemente
genérico. Otra evolución probable es la inclusión de otros observatorios.
Las GUI necesarias a la edición de alarmas ası́ como a la administración del sistema
serán integradas al portal web Ciclope Astro.
C.2.2.
Funciones del sistema
Las funciones del sistema se pueden clasificar según dos categorı́as:
1. Edición de alarmas.
2. Administración del sistema.
C.2.2.1.
Edición de alarmas
El sistema deberá permitir al usuario crear, editar, o suprimir alarmas. Según el perfil
del usuario, éste tendrá acceso a ciertas partes de la funcionalidad y verá su uso restringido
según la configuración establecida por el administrador.
El sistema deberá también permitir al usuario suscribirse a alarmas definidas por otros
usuarios.
Los requisitos completos relativos a esta parte se podrán encontrar en la sección
C.3.1.1.
C.2.2.2.
Administración de Ciclope Alarms
Las funciones de administración que tendrá que implementar el sistema se podrán
agrupar según las tres siguientes categorı́as:
Gestión de permisos de los usuarios.
Control de las alarmas definidas por los usuarios.
Configuración global del sistema.
Los requisitos completos relativos a esta parte se podrán encontrar en la sección
C.3.1.2
125
C.2.3.
Caracterı́sticas de los Usuarios
El modelo de usuarios será idéntico al modelo previamente utilizado en Ciclope Astro. Sólo los usuarios de perfil admin tendrán acceso a las funciones de administración del
sistema. Las demás funciones del sistema (creación, edición de alarmas, . . . ) serán accesibles a todos los perfiles de usuario. Sin embargo, restricciones particulares se aplicarán
a cada usuario según detallado en las secciones C.3.1.2.3.1 y C.3.1.2.3.2.
C.2.4.
Restricciones
Todo el software utilizado como base, librerı́a, o componente tiene que ser ’Open
Source’ (OSS). El software del sistema será publicado bajo la licencia GNU GPL versión
3[25], y toda su documentación bajo la licencia GNU FDL[26].
C.2.5.
Suposiciones y Dependencias
C.2.5.1.
Suposiciones
Se asume que los requisitos aquı́ descritos son estables.
C.2.5.2.
Dependencias
Existe una dependencia con el portal Ciclope Astro existente, dado que parte del sistema se tendrá que integrar en él. En particular, se reutilizará en su totalidad el modelo de
usuarios de Ciclope Astro.
Existen dependencias con todos los sistemas externos con los cuales el sistema se
tendrá que comunicar para llevar a cabo sus funciones:
wview: para la lectura de datos meteorológicos (mediante flujo RSS).
Servidor de correo: para mandar correos electrónicos.
Módem GSM: para mandar mensajes SMS.
C.3.
Requisitos Especı́ficos
C.3.1.
Requisitos funcionales
C.3.1.1.
Edición de alarmas
C.3.1.1.1.
Definición de alarmas
C.3.1.1.1.1. Requisito(1) El usuario podrá crear X alarmas, donde X será configurable por el administrador (véase los requisitos C.3.1.2.3.1 y C.3.1.2.3.2).
126
C.3.1.1.1.2. Requisito(2) Para crear una alarma, el usuario tendrá que definir las
condiciones de activación de dicha alarma. Para eso, el usuario podrá definir una condición lógica sobre el valor de una variable conocida por el sistema (i.e. que sea capaz de
obtener). En concreto, podrá escoger dentro de las variables meteorológicas recolectadas
por la estación meteorológica. Dado que se prevé que se pueda en un futuro vigilar el
estado de sensores u otras variables ası́ que el diseño deberá ser genérico. Véase requisito
C.3.2.1.
C.3.1.1.1.3.
Requisito(3) El formato de una condición lógica será:
[variable][comparador][ref erencia]
C.3.1.1.1.4.
Requisito(4) Los comparadores admitidos serán:
>, ≥, <, ≤, =, 6=
C.3.1.1.1.5.
OR, NOT.
Requisito(5) El usuario podrá utilizar los operadores lógicos: AND,
C.3.1.1.1.6. Requisito(6) El valor [referencia] podrá ser binario (true/false) o un
valor numérico.
C.3.1.1.1.7. Requisito(7) Para definir una alarma, el usuario podrá combinar condiciones lógicas mediante operadores lógicos. El número de condiciones que pueda definir
en la misma alarma será limitado (dicho número será configurable por el administrador
según se ha mencionado en los requisitos C.3.1.2.3.1 y C.3.1.2.3.2).
C.3.1.1.1.8. Requisito(8) El usuario podrá anidar condiciones lógicas mediante el
uso de paréntesis.
C.3.1.1.1.9. Requisito(9) El usuario podrá añadir una descripción textual de la
alarma definida.
C.3.1.1.1.10. Requisito(10) Todas las alarmas creadas por un usuario serán públicas por defecto. Sin embargo, el usuario tendrá la posibilidad de hacerla privada.
C.3.1.1.1.11. Requisito(11) Las alarmas creadas por un administrador serán privadas por defecto. El administrador tendrá la posibilidad de hacerla pública.
C.3.1.1.1.12. Requisito(12) Para crear una alarma, el usuario deberá escoger una
o varias acciones que el sistema deberá llevar a cabo cuando se cumplan las condiciones
de activación de la alarma.
127
C.3.1.1.1.13. Requisito(13) Las acciones disponibles serán: mandar un correo electrónico, mandar un mensaje SMS, avisar con un pop-up a usuarios conectados al portal Ciclope
Astro.
C.3.1.1.1.14. Requisito(14) Según su perfil, un usuario tendrá acceso a un subconjunto determinado de tipos de acciones, configurable por el administrador (véase los
requisitos C.3.1.2.3.1 y C.3.1.2.3.2).
C.3.1.1.1.15. Requisito(15) Si el usuario elige la opción correo electrónico, cuando se ejecute la alarma el sistema mandará un correo electrónico a la dirección de correo
configurada en su cuenta.
C.3.1.1.1.16. Requisito(16) Si el usuario elige la opción SMS, cuando se ejecute
la alarma el sistema mandará un SMS al número de móvil configurado en su cuenta.
C.3.1.1.1.17. Requisito(17) Si el usuario elige la opción pop-up, cuando se ejecute la alarma el sistema abrirá un pop-up en el portal si el usuario está conectado en ese
momento. (Si no está conectado en ese momento, la alarma se perderá1 ).
C.3.1.1.1.18. Requisito(18) Un usuario normal no podrá involucrar a otras personas en las acciones que elige (e.g. mandar un correo electrónico a otros usuarios). Para
eso, existe el sistema de suscripciones (los usuarios interesados por una alarma podrán
suscribirse).
C.3.1.1.1.19. Requisito(19) Si el administrador elige la opción correo electrónico,
podrá configurar las direcciones de correo a las cuales tiene que llegar la alarma:
Direcciones de correo electrónico de usuarios.
Direcciones de correo electrónico de todos los usuarios de un perfil.
Introducir manualmente una o varias direcciones de correo electrónico.
C.3.1.1.1.20. Requisito(20) Si el administrador elige la opción SMS, podrá elegir
mandarlo al móvil de un usuario, o introducir manualmente dicho número. Podrá también,
según las restricciones definidas, elegir mandarlo a varias personas, o incluso a todos los
usuarios de un perfil.
C.3.1.1.1.21. Requisito(21) Si el administrador elige la opción pop-up, podrá elegir la opción: a un usuario, a un tipo de perfil de usuarios destinatarios, o a todos los
usuarios.
1
En concreto, si el usuario no está conectado, la alarma no le llegará nunca.
128
C.3.1.1.1.22. Requisito(22) Para cualquier aviso textual (correo electrónico, popup o SMS), el usuario podrá configurar el texto enviado (un modelo por defecto será propuesto).
C.3.1.1.1.23. Requisito(23) Para limitar la frecuencia de ejecución de la misma
alarma y ası́ reducir el ’spam’ generado por sucesivas activaciones, se podrá definir para
cada alarma tres parámetros ’Periodo de inhibición de alarmas’, ’Número mı́nimo de
activaciones’ y ’Intervalo de tiempo’ antes ejecución:
Periodo de inhibición: numero mı́nimos de minutos que tiene que transcurrir entre
dos ejecuciones de acción (las condiciones se siguen comprobando, sólo la acción
se inhibe).
Número mı́nimo de activaciones en Intervalo de tiempo: número mı́nimo de activaciones de la alarma en los últimos x minutos e.g. (3 ocurrencias mı́nimas durante
20 minutos).
Siguiendo el ejemplo de configuración propuesto antes (3 activaciones mı́nimas durante 20 minutos), si la alarma se activa a las 14:00, 14:05, 14:20, se ejecutará la acción
en el minuto 20. En cambio si la alarma se activa a las 14:00, 14:15, 14:25, 14:30, se
ejecutará la acción en el minuto 30.
C.3.1.1.2.
Suscripciones
C.3.1.1.2.1. Requisito(24) El usuario podrá suscribirse a Y alarmas (no suyas),
donde Y será configurable por el administrador (véase los requisitos C.3.1.2.3.1 y C.3.1.2.3.2).
C.3.1.1.2.2. Requisito(25) Para suscribirse a una alarma definida por otro usuario,
el usuario deberá seleccionar la alarma que le interesa dentro de las alarmas publicadas, y
escoger una o varias acciones dentro de las accesibles dados sus permisos.
C.3.1.1.2.3. Requisito(26) Para poder encontrar más fácilmente las alarmas que
le puede interesar, el usuario podrá buscar dentro de las alarmas públicas definidas por
otros usuarios mediante filtros de búsqueda adaptados. En particular, tendrá la posibilidad
de:
Buscar por:
• Usuario dueño de la alarma.
• Rol de usuario del dueño de la alarma.
• Descripción textual de la alarma.
• Variables utilizadas en la condición lógica de la alarma.
• Periodo de inhibición de la alarma.
• Número mı́nimo de activaciones antes de ejecución.
129
• Intervalo de tiempo asociado al número mı́nimo de activaciones antes de ejecución.
Ordenar los resultados por:
• Fecha de creación de la alarma.
• Fecha de última ejecución de la alarma.
C.3.1.1.2.4. Requisito(27) El usuario podrá elegir acciones para suscripciones del
mismo modo que cuando crea una alarma. (En particular las mismas restricciones definidas a nivel de perfil y/o usuario por el administrador se aplicarán).
C.3.1.1.2.5. Requisito(28) Una alarma dada podrá aceptar un número lı́mite de Z
usuarios suscriptores, donde Z será configurable por el administrador (véase los requisitos
C.3.1.2.3.1 y C.3.1.2.3.2).
C.3.1.1.3.
Otras tareas de gestión
C.3.1.1.3.1. Requisito(29) El usuario podrá editar cualquier alarma o suscripción
que haya creado previamente. Véase los requisitos C.3.1.1.3.5 y C.3.1.1.3.6 para detalles
sobre la supresión de una alarma.
C.3.1.1.3.2. Requisito(30) El usuario podrá consultar (pero no modificar) el estado de sus alarmas /suscripciones (e.g. un estado podrá ser ”Desactivado por el administrador”).
C.3.1.1.3.3. Requisito(31) El usuario podrá consultar la fecha de última ejecución
de cada una de sus alarmas / suscripciones.
C.3.1.1.3.4. Requisito(32) El usuario podrá activar/desactivar una alarma / suscripción. Véase el requisito C.3.1.1.3.7 para detalles sobre las restricciones que pueden
afectar la activación de una alarma.
C.3.1.1.3.5. Requisito(33) En cualquier momento, el usuario podrá borrar una
alarma / suscripción. Véase el requisito C.3.1.1.3.6 para detalles sobre la supresión de
una alarma.
C.3.1.1.3.6. Requisito(34) Si hay usuarios suscritos a la alarma que se quiere borrar, el sistema preguntará al usuario si desea seguir con la supresión. En caso positivo,
el sistema suprimirá la alarma y las suscripciones y avisará por correo electrónico a los
usuarios suscritos.
130
C.3.1.1.3.7. Requisito(35) El usuario podrá ordenar sus alarmas por prioridad.
Sólo podrá activar las N alarmas de mayor prioridad. En caso de reordenar una alarma
activada en una prioridad más baja que N, la alarma será automáticamente desactivada,
después de avisar al usuario.
C.3.1.2.
C.3.1.2.1.
Administración de Ciclope Alarmas
Configuración global del sistema
C.3.1.2.1.1.
ma.
Requisito(36) El administrador podrá activar/desactivar todo el siste-
C.3.1.2.1.2. Requisito(37) El administrador podrá definir franjas horarias de funcionamiento (i.e. activación) del módulo de alarmas. Fuera de éstas, el sistema funcionará en un modo restringido, procesando y ejecutando exclusivamente las alarmas definidas por el administrador, ası́ como las suscripciones asociadas a las mismas.
C.3.1.2.1.3. Requisito(38) El administrador podrá definir dı́as festivos puntuales.
Durante éstos, el sistema funcionará en un modo restringido, procesando y ejecutando
exclusivamente las alarmas definidas por el administrador, ası́ como las suscripciones
asociadas a las mismas.
C.3.1.2.2.
Control de las alarmas definidas por los usuarios
C.3.1.2.2.1. Requisito(39) El administrador podrá editar las alarmas/suscripciones definidas por cualquier usuario.
C.3.1.2.2.2. Requisito(40) Para poder realizar esta labor eficazmente, el administrador podrá buscar dentro de las alarmas y suscripciones definidas mediante filtros de
búsqueda adaptados, similares a los definidos en el requisito C.3.1.1.2.3.
C.3.1.2.2.3. Requisito(41) El administrador podrá desactivar cualquier alarma o
suscripción. Cuando el administrador desactiva una alarma por este método, el estado de
la alarma pasa a ser Desactivada por el administrador. Tiene el mismo efecto que si el
usuario desactiva él mismo la alarma i.e. no se activará.
C.3.1.2.3.
Gestión de permisos de los usuarios
C.3.1.2.3.1. Requisito(42) El administrador podrá definir para cada perfil cada
uno de los siguientes elementos de restricción:
El número máximo de alarmas que un usuario del perfil dado puede definir.
131
El número máximo de alarmas que un usuario del perfil dado puede activar al mismo
tiempo.
El número máximo de condiciones lógicas que un usuario del perfil dado puede
utilizar en la definición de una alarma.
El número máximo de acciones que un usuario del perfil dado puede configurar
para cada alarma.
El número máximo de suscriptores que puede tener una alarma definida por un
usuario del perfil dado.
El número máximo de alarmas a las que un usuario del perfil dado se puede suscribir.
Para cada tipo de acción existente, el administrador podrá definir:
• La posibilidad o no que tiene el usuario del perfil dado para utilizar dicho tipo
de acción.
• El número máximo de alarmas utilizando acciones de este tipo.
C.3.1.2.3.2. Requisito(43) El administrador podrá redefinir para cada usuario cualquier restricción configurada a nivel de perfil. Dichas excepciones prevaldrán sobre las
configuraciones a nivel de perfil.
C.3.1.2.3.3. Requisito(44) Las excepciones sólo podrán tener un carácter restrictivo (no podrán aumentar los permisos de un usuario comparado con su perfil).
C.3.1.2.3.4. Requisito(45) Cuando el administrador restringe permisos de una manera u otra, bien sea a nivel de perfil o de usuario, existe la posibilidad de que usuarios
no cumplan con las nuevas polı́ticas de permisos. (e.g. un usuario tiene configurado 5
alarmas, y el administrador baja el número de alarmas que pueda definir un usuario de
este perfil de 5 a 3). La solución escogida para solucionar este tipo de conflicto es la siguiente: en caso de conflicto, el sistema deberá tomar las acciones necesarias para que se
cumplan las nuevas polı́ticas de restricción. Dichas acciones podrán incluir desactivar las
alarmas de más baja prioridad hasta cumplir las nuevas reglas de restricción. El administrador tendrá la opción de mandar un correo electrónico o un SMS a todos los usuarios
potencialmente afectados (i.e. del perfil configurado).
C.3.2.
Requisitos de reusabilidad
C.3.2.1 Requisito(46) El diseño deberá ser lo suficientemente genérico para poder
incluir fácilmente en el futuro nuevos tipos de variables (e.g. sensores).
C.3.2.2 Requisito(47) El diseño deberá ser lo suficientemente genérico para poder
incluir fácilmente en el futuro nuevos tipos de acciones.
132
C.3.2.3 Requisito(48) El diseño deberá prever la inclusión de otros observatorios
en el sistema.
C.3.3.
Requisitos de interfaces externas
C.3.3.1 Requisito(49) El sistema tendrá que ser capaz de comunicarse con los siguientes elementos externos:
Flujo RSS conteniendo datos meteorológicos (wview).
Servidor de correo electrónico.
Módem GSM.
C.3.4.
Requisitos tecnológicos
C.3.4.1 Requisito(50) Las interfaces gráficas necesarias se desarrollarán con Google Web Toolkit.
C.3.4.2
Requisito(51) Los accesos a bases de datos se harán con Ibatis.
133
134
Bibliografı́a
[1] Agencia Estatal de Meteorologı́a. Página oficial. http://www.aemet.es.
[2] The Apache Software Foundation. Página oficial de commons daemon. http:
//commons.apache.org/daemon/.
[3] The Apache Software Foundation. Apache License, version 2.0. http://www.apache.
org/licenses/LICENSE-2.0, January 2004.
[4] Astrophysical Institute Potsdam. Documentación del observatorio robótico STELLA. http://www.aip.de/stella/index.php?id=docs.
[5] Astrophysical Institute Potsdam. Observatorio robótico STELLA. http://www.aip.
de/stella/.
[6] Awekas. Página de configuración de datos de usuario. http://www.awekas.at/en/
benutzer.php.
[7] Awekas. Página oficial. http://www.awekas.at.
[8] José Alberto y Instituto Superior de Formación y Recursos en Red para el Profesorado Bermúdez. Gráfico de la latitud y longitud de la Tierra. http://es.wikipedia.org/
wiki/Coordenadas geogr%C3%A1ficas, 2008.
[9] Calar Alto Astronomical Observatory. Condiciones automáticas de apertura y cierre
en Calar Alto. http://www.caha.es/CAHA/visit.html#weather.
[10] Canada France Hawaii Telescope. Página oficial. http://www.cfht.hawaii.edu/.
[11] G. Chiozzi, B. Gustafsson, B. Jeram, M. Plesko, M. Sekoranja, G. Tkacik, and K. Zagar. CORBA-based Common Software for the ALMA project. http://www.eso.org/
projects/alma/develop/acs/OtherDocs/ACSPapersAndSlides/spie2002.pdf, 2002.
[12] Ciclope. Portal web Ciclope Astro. http://www.ciclope.info/CiclopeAstro/.
[13] Ciclope. Proyecto Ciclope. http://www.ciclope.info.
[14] Ciclope. Página web de la estación meteorológica del Observatorio Astronómico
Montegancedo. http://www.ciclope.info/weather/.
135
[15] Ciclope. Repositorio de fuentes del proyecto Ciclope Astro. https://sourceforge.net/
projects/castro.
[16] Cinterion Wireless Modules. Distribuidores de Cinterion en España. http://www.
cinterion.com/spain-andorra.html.
[17] Cinterion Wireless Modules.
cinterion.com/tc35it.html.
Modelo de módem GSM TC35iT.
http://www.
[18] Davis Instrument. Modelo de estación meteorológica Davis Vantage Pro 2. http:
//www.davisnet.com/weather/products/weather product.asp?pnum=06163.
[19] T. Delenikas. About SMSLib. http://code.google.com/p/smslib/wiki/About, April
2009. Apache v2 license.
[20] European Southern Observatory. Documentación del proyecto ACS. http://www.
eso.org/∼almamgr/AlmaAcs/.
[21] Fabra-ROA telescope at Montsec. Página oficial. http://www.am.ub.es/bnc/.
[22] Charles Forgy. On the efficient implementation of production systems. PhD thesis,
Carnegie-Mellon University, 1979.
[23] Charles Forgy. Rete: A Fast Algorithm for the Many Pattern/Many Object Pattern
Match Problem. Artificial Intelligence, 19:17–37, 1982.
[24] Free Software Foundation, Inc. GNU Lesser General Public License, version 2.1.
http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html, February 1999.
[25] Free Software Foundation, Inc. GNU General Public License. http://www.gnu.org/
licenses/gpl.html, June 2007.
[26] Free Software Foundation, Inc. GNU Free Documentation License. http://www.
gnu.org/licenses/fdl.html, November 2008.
[27] Free Software Foundation, Inc. Licencia de Documentación Libre de GNU. http:
//stuff.danexnow.org/gfdl es.html, November 2008.
[28] Gnokii. Página oficial del proyecto gnokii - móviles Nokia en Linux. http://www.
gnokii.org/.
[29] Google Inc. Conversiones diversas con Google. http://www.google.es/intl/es/help/
features.html#calculator.
[30] Google Inc. Google Earth. http://earth.google.com/intl/es/.
[31] gsmspain.com. Comparación de tarifas GSM. http://www.gsmspain.com/tarifas/.
[32] Enrique de Guindos. Estación meteorológica distribuida. Novática, (191):55–60,
January 2008.
136
[33] Hammurapi Group. Página oficial. http://www.hammurapi.biz/hammurapi-biz/ef/
xmenu/hammurapi-group/products/hammurapi-rules/index.html.
[34] Hamweather. Página oficial. http://www.hamweather.com/.
[35] The Institute of Electrical and Electronics Engineers. IEEE Recommended Practice
for Software Requirements Specifications IEEE Std. 830, 1998.
[36] Instituto Geográfico Nacional. Glosario geográfico. http://www.ign.es/ign/es/IGN/
ane glosario.jsp.
[37] JBoss Inc. A Basic Rete network. http://downloads.jboss.com/drools/docs/4.0.7.
19894.GA/html single/index.html#d0e379.
[38] JBoss Inc. Drools Reference Manual. http://downloads.jboss.com/drools/docs/4.0.
7.19894.GA/html/index.html.
[39] JBoss Inc. Logotipo de Drools. http://downloads.jboss.com/drools/docs/4.0.7.
19894.GA/html single/index.html#preface.
[40] JBoss Inc. Página oficial de Drools. http://www.jboss.org/drools/.
[41] Jess. Página oficial. http://www.jessrules.com/.
[42] Mandarax Project. Página oficial. http://mandarax.sourceforge.net/.
[43] Meteohub. Página oficial. http://www.meteohub.de/.
[44] Daniel P. Miranker. TREAT: A Better Match Algorithm for AI Production Systems.
Technical report, Department of Computer Science, University of Texas, April 1987.
[45] Daniel P. Miranker. TREAT: A new and efficient Match Algorithm for AI Production
Systems. PhD thesis, Computer Science Department, Columbia University, January
1987.
[46] Daniel P. Miranker, D. Brant, B. Lofaso, and D. Gadbois. On the Performance of
Lazy Matching in Production Systems, 1990. Proc. National Conference on Artificial Intelligence.
[47] Jasem Mutlaq. Página oficial del proyecto INDI. http://indi.sourceforge.net/index.
php/Main Page.
[48] National Aeronautics and Space Administration. Interoperable Remote Component
(IRC) Architecture. http://aaa.gsfc.nasa.gov/IRC/.
[49] National Astronomical Observatory of Japan. Página oficial del Telescopio Subaru.
http://www.naoj.org/.
[50] National Geospatial-Intelligence Agency. Artı́culos básicos de geodesia. http://
earth-info.nga.mil/GandG/coordsys/geoarticles/geoarticles.html.
137
[51] National Geospatial-Intelligence Agency. NGA EGM96 Geoid Calculator. http:
//earth-info.nga.mil/GandG/wgs84/gravitymod/egm96/intpt.html.
[52] National Oceanographic and Atmospheric Administration. CWOP. http://www.
wxqa.com/.
[53] National Oceanographic and Atmospheric Administration. Página oficial. http://
weather.noaa.gov/.
[54] National Oceanographic and Atmospheric Administration. Sección de FAQ de
CWOP. http://www.wxqa.com/faq.html.
[55] OpenRules, Inc. Página oficial. http://www.openrules.com/.
[56] ozekisms. Lista de módems GSM recomendados. http://ozekisms.com/index.php?
ow page number=148.
[57] Personal Weather Stations. Página oficial. http://www.pwsweather.com.
[58] QOS.ch. SLF4J License. http://www.slf4j.org/license.html.
[59] Relación entre altitud y presión atmosférica. http://www.astrosurf.com/luxorion/
meteo-pression.htm.
[60] Gary Riley. Página oficial de CLIPS. http://clipsrules.sourceforge.net/.
[61] Siemens. TC35i AT Command Set. Siemens, September 2005. Versión 03.01.
[62] Siemens. TC35i Terminal Hardware Interface Description. Siemens, December
2005. Versión 03.01.
[63] Sun
Microsystems,
Inc.
Binary
Code
License
Agreement.
WFS/CDS-CDS SMI-Site/en US/-/USD/ViewLicense-Start?
LicenseUUID=7OzACUFBibMAAAEYzrg5AXiO&ProductUUID=
aOPACUFBJXMAAAEYG3U5AXjS&cnum=&evsref=&sln=.
[64] Sun Microsystems, Inc. JavaDoc del paquete java.util.concurrent. http://java.sun.
com/j2se/1.5.0/docs/api/java/util/concurrent/ScheduledExecutorService.html.
[65] Mark Teel.
Manual de wview - Configuración del servicio CWOP.
http://www.wviewweather.com/release-notes/wview-User-Manual.html#16.
CWOP-SubmittingYourDatatoNOAAandtheCWOPSystem.
[66] Mark Teel. wview. http://www.wviewweather.com/.
[67] U.S. Department of Defense. World Geodetic System 84. http://earth-info.nga.mil/
GandG/publications/tr8350.2/wgs84fin.pdf.
138
[68] Wavecom.
Distribuidores de Wavecom en España.
http://www.wavecom.
com/modules/movie/scenes/locator/index.php?locator=distributors&country=
ES&zone=ze europe.
[69] Weather For You. Página oficial. http://weatherforyou.com/.
[70] Weather Underground. Página oficial. http://www.wunderground.com.
[71] WeatherBug. Página oficial. http://weather.weatherbug.com/.
[72] Westerhoff. Iterative development model schema. http://en.wikipedia.org/wiki/File:
Iterative development model V2.jpg, September 2006.
[73] Wikipedia. GPS: Selective Availability.
Positioning System#Selective availability.
http://en.wikipedia.org/wiki/Global
[74] World Meteorological Organization. Página oficial. http://www.wmo.int.
[75] Michal Čihař. Lista de móviles compatibles con Gammu. http://cihar.com/gammu/
phonedb/.
139

Ciclope Weather, monitorización de datos meteorológicos y gestión

Transcripción

Documentos relacionados

Descarga aqui - Carol Automatismos Igualada SA

TRB221