Ciclope Weather, monitorización de datos meteorológicos y gestión
Transcripción
Ciclope Weather, monitorización de datos meteorológicos y gestión
FACULTAD DE INFORMÁTICA ÉCOLE SUPÉRIEURE D’ÉLECTRICITÉ UNIVERSIDAD POLITÉCNICA DE MADRID FACULTAD DE INFORMÁTICA TRABAJO FIN DE CARRERA CICLOPE WEATHER Monitorización de datos meteorológicos y gestión de alertas para un observatorio astronómico AUTOR: Bruno PIQUERAS TUTOR: Francisco Manuel SÁNCHEZ MORENO Madrid, 7 de julio de 2009 À 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 términos de la Licencia de Documentación Libre de GNU, Versión 1.3[27] o cualquier otra versió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 traducción al castellano de dicha licencia en la URL: http://stuff.danexnow.org/gfdl es. html”. Sólo la versión original de la licencia, en inglé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 Informática de la portada es propiedad de la UPM. El logotipo de Supélec de la portada es propiedad de Supélec. 1 Excepto las imágenes y textos gentileza de terceras partes. Sus autores se citarán expresamente en este texto. V Agradecimientos À 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 compañeros de Accenture y Coritel del proyecto BTGS y en particular: • Rocı́o Cantero Sánchez, por el testing del módem GSM • Ernesto Paternina Moya, por el alpha testing de Ciclope Alarms A Enrique de Guindos, del Centro Astronómico Hispano-Alemán, en Calar Alto (Almerı́a) por sus explicaciones sobre los sistemas informáticos de control del CAHA. A Pablo de Vicente, del Observatorio Astronómico Nacional para sus explicaciones sobre el funcionamiento del Centro Astronó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 robótico STELLA [5]. A William Cruise, del Canada France Hawaii Telescope [10], por su tiempo y explicaciones acerca de los sistemas informáticos de control del CFHT. Al Dr. Jorge Nuñ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 realización del presente Proyecto Fin de Carrera, gracias. . . VII Índice general 1. Introducción 1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1. Publicar datos meteorológicos en redes de información rológica . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2. Gestor de alarmas Ciclope Alarms . . . . . . . . . . . . 1.2. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . 1.3. Ciclope Astro y el Observatorio Astronómico Montegancedo . . 1.4. Trabajo del autor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . meteo. . . . . . . . . . . . . . . . . . . . . . . . . 2. Estado del Arte 2.1. Ciclo de vida de datos meteorológicos . . . . . . . . . . . . . . . . . . . 2.1.1. Producción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2. De los datos a la información: el papel de las redes de información meteorológica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3. Consumo de información meteorológica . . . . . . . . . . . . . . 2.2. Gestores de alarma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1. Observatorios astronómicos . . . . . . . . . . . . . . . . . . . . 2.2.1.1. Centro Astronómico Hispano-Alemán A.I.E. - Calar Alto (Almerı́a) . . . . . . . . . . . . . . . . . . . . . . . 2.2.1.2. Centro Astronó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 robó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 meteorológicos en Internet 3.1. Localización de la estació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. Técnicas para obtener coordenadas geográ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 configuración a posteriori . . . . . . . CWOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1. Darse de alta . . . . . . . . . . . . . . . . . . . . 3.3.2. Configurar wview . . . . . . . . . . . . . . . . . . 3.3.3. Comprobar el buen funcionamiento . . . . . . . . 3.3.4. Cambiar la configuración a posteriori . . . . . . . Weather Underground . . . . . . . . . . . . . . . . . . . . 3.4.1. Darse de alta . . . . . . . . . . . . . . . . . . . . 3.4.2. Configurar wview . . . . . . . . . . . . . . . . . . 3.4.3. Comprobar el buen funcionamiento . . . . . . . . 3.4.4. Modificar la configuración a posteriori . . . . . . . Red Personal Weather Stations . . . . . . . . . . . . . . . 3.5.1. Darse de alta . . . . . . . . . . . . . . . . . . . . 3.5.2. Configurar wview . . . . . . . . . . . . . . . . . . 3.5.3. Comprobar el buen funcionamiento . . . . . . . . 3.5.4. Cambiar la configuración a posteriori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Ciclope Alarms 4.1. Toma de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1. Propósito general . . . . . . . . . . . . . . . . . . . . . . . 4.1.2. Edición de Alarmas . . . . . . . . . . . . . . . . . . . . . . 4.1.3. Administración . . . . . . . . . . . . . . . . . . . . . . . . 4.1.4. Requisitos no funcionales . . . . . . . . . . . . . . . . . . 4.2. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1. Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1.1. Descripción de los actores . . . . . . . . . . . . . 4.2.1.2. Descripción de los casos de uso en formato breve 4.2.2. Modelo conceptual . . . . . . . . . . . . . . . . . . . . . . 4.3. Implementació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: Configuració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. Integración de la GUI con Ciclope Astro . . . . . . 4.3.5. Motor de Alarmas . . . . . . . . . . . . . . . . . 4.4. Notas para futuras extensiones . . . . . . . . . . . . . . . 4.4.1. Inclusión de una nueva variable de monitorización 4.4.2. Inclusión de un nuevo tipo de acción . . . . . . . . 4.4.3. Inclusió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. Configuración global . . . . . . . . . . . . . . . . . . 5.1.1.2. Condiciones de activación . . . . . . . . . . . . . . . . 5.1.1.3. Acciones . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1.4. Confirmació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 suscripció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. Monitorización del sistema . . . . . . . . . . . . . . . 5.2.5.2. Configuració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 Instalación de Ciclope Alarms 6.1. Instalación del módem GSM . . . . . . . . . 6.1.1. Cableado y puesta en funcionamiento 6.1.2. Primeras Pruebas . . . . . . . . . . . 6.1.3. Instalación de las librerı́as java . . . . 6.2. Instalación de la base de datos . . . . . . . . 6.2.1. Modo standalone . . . . . . . . . . . 6.2.2. Modo integrado con Ciclope Astro . . 6.3. Instalación del Motor de alarmas . . . . . . . 6.3.1. Prerequisitos y librerı́as . . . . . . . . 6.3.2. Instalación . . . . . . . . . . . . . . 6.3.3. Configuración . . . . . . . . . . . . . 6.4. Instalación de la GUI . . . . . . . . . . . . . 6.4.1. Prerequisitos y librerı́as . . . . . . . . 6.4.2. Instalación . . . . . . . . . . . . . . 87 87 88 88 89 89 90 90 91 91 92 93 95 95 96 XI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 7. Conclusión 7.1. Conclusiones generales . . . . . . . . . . . . . . 7.2. Futuras Mejoras . . . . . . . . . . . . . . . . . . 7.2.1. Soporte de lógica borrosa . . . . . . . . . 7.2.2. Añadir de nuevos observatorios, tipos de variables de monitorización . . . . . . . 7.2.3. Mejoras a la parte de edición de alarmas . 7.2.4. Mejoras a la parte de administració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 automáticamente B.1. Módems GSM . . . . . . . . . . . . . . . . . . . . . . B.1.1. Compatibilidad con GNU/Linux . . . . . . . . B.1.2. Precios . . . . . . . . . . . . . . . . . . . . . B.2. Móvil convencional . . . . . . . . . . . . . . . . . . . B.3. Tarifas GSM Operadoras clá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. Conclusión . . . . . . . . . . . . . . . . . . . . . . . C. ERS Ciclope Alarms C.1. Introducción . . . . . . . . . . . . . . . . . . . C.1.1. Propósito . . . . . . . . . . . . . . . . C.1.2. Ámbito del Sistema . . . . . . . . . . . C.1.3. Definiciones, Acrónimos y Abreviaturas C.1.3.1. Definiciones . . . . . . . . . C.1.3.2. Acrónimos . . . . . . . . . . C.1.3.3. Abreviaturas . . . . . . . . . C.1.4. Referencias . . . . . . . . . . . . . . . C.1.5. Visión general del Documento . . . . . C.2. Descripció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. Edición de alarmas . . . . . . . . . . . . . . . . . . . 125 C.2.2.2. Administració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. Edición de alarmas . . . . . . . . . . . . . . . . . . . 126 C.3.1.1.1. Definición de alarmas . . . . . . . . . . . . . 126 C.3.1.1.2. Suscripciones . . . . . . . . . . . . . . . . . 129 C.3.1.1.3. Otras tareas de gestión . . . . . . . . . . . . 130 C.3.1.2. Administración de Ciclope Alarmas . . . . . . . . . . 131 C.3.1.2.1. Configuración global del sistema . . . . . . . 131 C.3.1.2.2. Control de las alarmas definidas por los usuarios131 C.3.1.2.3. Gestió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 tecnológicos . . . . . . . . . . . . . . . . . . . . . . 133 C.3.4.1. Requisito(50) . . . . . . . . . . . . . . . . . . . . . . 133 C.3.4.2. Requisito(51) . . . . . . . . . . . . . . . . . . . . . . 133 Bibliografı́a 135 XIII Índice de figuras 2.1. Ciclo de vida de la información meteorológica . . . . . . . . . . . . . . . 2.2. Meteohub: configuración de publicación de datos hacia redes de información meteorológica (fuente: página oficial de Meteohub [43]) . . . . . . . 2.3. Gnome Weather Applet . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4. WeatherBug Widget for Windows (fuente: página web oficial de WeatherBug [71]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5. Configuración de una alarma en STS (autor: David Cook) . . . . . . . . . 2.6. Estructura de ACS (fuente: documentación de ACS [11]) . . . . . . . . . 2.7. Logotipo de Drools (fuente: documentación de Drools [39]) . . . . . . . 2.8. Esquema de un motor de reglas (fuente: documentació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: José Alberto Bermúdez y el Instituto Superior de Formación y Recursos en Red para el Profesorado [8]) . . . . . . . . . 3.2. Dar de alta una estación en Awekas . . . . . . . . . . . . . . . . . . . . . 3.3. Mapa de España en Awekas . . . . . . . . . . . . . . . . . . . . . . . . . 3.4. Red Awekas en Google Earth . . . . . . . . . . . . . . . . . . . . . . . . 3.5. Petición de un Call Sign id para CWOP . . . . . . . . . . . . . . . . . . 3.6. Datos de una estación meteorológica en CWOP . . . . . . . . . . . . . . 3.7. Formulario de Weather Underground . . . . . . . . . . . . . . . . . . . . 3.8. Datos de una estación meteorológica en Weather Underground . . . . . . 3.9. Formulario de PWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.10. Datos de una estación meteoroló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 gráfica - modo standalone . . . . . . Interfaz grá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 suscripción . . . . . . . 5.5. Gestionar sus suscripciones . . . . . . . . 5.6. Editar una suscripción . . . . . . . . . . . 5.7. Edició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 Índice de tablas 2.1. Soluciones software para operar una estación meteorológica . . . . . . . 9 6.1. Librerı́as necesarias para el motor de alarmas . . . . . . . . . . . . . . . 6.2. Librerı́as necesarias para la interfaz gráfica . . . . . . . . . . . . . . . . . 91 95 B.1. B.2. B.3. B.4. B.5. Compatibilidad GNU/Linux de los modelos de módems . Precios de distintos modelos de módems . . . . . . . . . Modelos de móviles recomendados por Ozenkisms . . . Móviles compatibles con GNU/Linux . . . . . . . . . . Ventajas e inconvenientes de cada tipo de solució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 estación meteorológica Ciclope Weather [14] ası́ como el gestor de alarmas de la misma para permitir la monitorización del Observatorio Astronómico de Montegancedo a partir del portal web Ciclope Astro [12]. El trabajo realizado por el autor se organiza según dos grandes objetivos: Publicar los datos de la estación meteorológica en redes de información meteorológica para hacerlos accesibles a un mayor número de usuarios finales. Diseñar e implementar un gestor de alarmas flexible, genérico y fácilmente ampliable: Ciclope Alarms. Résumé Le Projet de Fin d’Études exposé dans ce document s’inscrit dans la continuité du projet Ciclope [13]. Ses objectifs sont d’améliorer le fonctionnement de la station météorologique Ciclope Weather [14] et en particulier de son système d’alarmes afin de permettre le contrôle de l’Observatoire Astronomique de Montegancedo à partir du portail web Ciclope Astro [12]. Le travail réalisé par l’auteur s’organise selon deux grands objectifs: Publier les données de la station météorologique auprès des réseaux d’information météorologique afin de les rendre accessibles au plus grand nombre d’utilisateurs possible. Concevoir et réaliser un système d’alarmes flexible, générique et facilement extensible: Ciclope Alarms. Capı́tulo 1 Introducción El clima y las condiciones meteorológicas en general siempre han tenido una importancia crucial para las actividades humanas. En la antigüedad, se observaban rituales para apaciguar a los dioses y que éstos proporcionaran condiciones meteorológicas propicias a buenos cultivos. Los griegos solı́an sacrificar animales a Poseidó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 catástrofes naturales, como lo demuestra regularmente la actualidad. La monitorización de las condiciones meteorológicas ası́ como la predicción de las mismas se han convertido en disciplinas imprescindibles en determinados campos. Por ejemplo, los aeropuertos tienen estaciones meteorológicas dedicadas a esta tarea para asegurar la seguridad de los vuelos. Ası́ pueden suspender la realización de los despegues y aterrizajes si las condiciones meteorológicas no son adecuadas. Los observatorios astronómicos suelen también contar con la presencia de una estación meteorológica esta vez para poder proteger equipos costosos de las intemperies. En efecto, las observaciones astronómicas sólo se pueden realizar si las condiciones meteorológicas lo permiten. En caso contrario, la cúpula o el techo deslizante del observatorio se tiene que cerrar para proteger el telescopio ası́ como otros tipos de instrumentos astronómicos. Tradicionalmente, esta decisión está tomada por operadores presentes en el sitio. Pero, es cada vez más común delegar esta tarea a sistemas informáticos, especialmente en observatorios muy automatizados, o ubicados en sitios poco accesibles. El Observatorio Astronómico Montegancedo, inaugurado el 23 de enero del 2009 y ubicado en el campus de la Facultad de Informática de la Universidad Politécnica de Madrid tiene la vocación de tener un funcionamiento totalmente autó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 astronómicas utilizando los recursos del observatorio. Por eso, debe permitir, a medio plazo, observaciones astronómicas en cualquier hora del dı́a. Estas reflexiones y exigencias constituyen el punto de partida de la realización de este Proyecto Fin de Carrera, titulado Ciclope Weather - Monitorización de datos meteorológicos y gestión de alertas para un observatorio astronómico. 1 1.1. Objetivos La situación inicial, i.e. antes de la realización de este Proyecto Fin de Carrera era la siguiente: el Observatorio Astronómico Montegancedo estaba a punto de estar inaugurado y su estación meteorológica, anterior al Observatorio, llevaba dos años funcionando, capturando y almacenando datos en base de datos. Gracias al software de control de la estación, wview [66], se publicaban los datos en la página web siguiente: http://www.ciclope.info/weather y con el fin de monitorizar las condiciones meteorológicas, se utilizaba el gestor de alarmas integrado en wview. Este gestor de alarmas, como se verá en la sección 2.2.2.1 , no cumple con todas las expectativas de los usuarios. La realización del presente Proyecto Fin de Carrera pretende aportar mejoras a esta situación inicial, realizando principalmente dos objetivos: Publicar los datos de la estación meteorológica en redes de información meteorológica para que sean accesibles a un mayor número de usuarios finales. Mejorar la gestión de alarmas en el Observatorio, concibiendo e implementando un gestor de alarmas flexible, configurable y que se pueda fácilmente ampliar en el futuro. 1.1.1. Publicar datos meteorológicos en redes de información meteorológica El objetivo principal perseguido en esta parte es hacer un estudio sobre los métodos para publicar datos meteorológicos en redes de información meteorológica, documentando los pasos a seguir para cada uno y aplicarlos al caso de la estación meteorológica Ciclope Weather. 1.1.2. Gestor de alarmas Ciclope Alarms El objetivo de mejorar la gestión de alarmas en el Observatorio es sin duda el objetivo cuya realización habrá necesitado más tiempo y esfuerzo, convirtiéndolo de facto en el objetivo principal del presente Proyecto Fin de Carrera. A lo largo del diseño y de la realización del mencionado gestor de Alarmas, bautizado Ciclope Alarms, se tuvieron en cuenta los objetivos secundarios siguientes: Configuración dinámica de alarmas vı́a el portal web Ciclope Astro. Carácter genérico de la solución: Ciclope Alarms tiene que permitir la monitorización simultánea de varios observatorios. Carácter extensible de la solución: el sistema se podrá ampliar fácilmente para incluir otras variables de monitorización (e.g. sensores) ası́ como otros tipos de acciones a realizar. 2 La solución debe utilizar exclusivamente software libre, compatible con la licencia GNU GPL [25]. Se publicará, bajo los té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: Introducción (el presente capı́tulo). Proporciona una visión general del trabajo realizado y de los objetivos seguidos. Capı́tulo 2: Estado del Arte. Presenta el estudio del arte necesario a la realizació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 meteoroló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 meteorológicos en Internet. En este capı́tulo, se detallan los pasos seguidos para publicar los datos meteorológicos recolectados por una estación meteorológica en varias redes de información meteorológica. Capı́tulo 4: Ciclope Alarms. En esta sección, se detallan el diseño y la implementación del gestor de alarmas Ciclope Alarms. Capı́tulo 5: Manual de Usuario. En este capı́tulo, se exponen las instrucciones de utilización del sistema Ciclope Alarms. Capı́tulo 6: Manual de instalación. Este anexo incluye las instrucciones de instalación del sistema Ciclope Alarms. Capı́tulo 7: Conclusión. En este último capı́tulo, se presentan las conclusiones obtenidas de la realizació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 aplicación wview para mejorar la flexibilidad de la misma a la hora de publicar datos meteorológicos en las redes Wunderground y WeatherForYou. Este anexo está enteramente redactado en inglés dado que se trata de una contribución al proyecto de software libre wview, de á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 automáticamente (una de las funciones de Ciclope Alarms), ası́ como recomendaciones acerca de la solución má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 estándar IEEE 830 Recommended Practice for Software Requirements Specifications[35]. 1.3. Ciclope Astro y el Observatorio Astronómico Montegancedo El Observatorio Astronómico Montegancedo, situado en la Facultad de Informática de la Universidad Polité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 Año Internacional de la Astronomı́a 2009. Se trata del primer observatorio astronó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 astronómicos, creación de escenarios y control de telescopios, cámaras y cúpulas de forma remota, y permite a cualquier internauta acceder desde su casa al observatorio para vivir diferentes experiencias astronómicas. A finales de 2008, Ciclope Astro obtuvo el segundo premio de la octava edición de Nuevas Aplicaciones para Internet, organizado por la Cátedra de Internet de Nueva Generació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, además de aprender a cambiar los diferentes parámetros de las cámaras para obtener buenas imágenes astronómicas. Aunque para acceder al control del observatorio hay que realizar previamente una reserva, en cualquier momento se puede ver desde casa lo que está ocurriendo a través de cuatro webcams que actualizan sus imágenes cada 20 segundos si no se está registrado y cada segundo si el usuario está registrado. El observatorio está ubicado en el Edificio 6 de la FIUPM, en el Campus de Montegancedo, Boadilla del Monte. Dentro de la cúpula está instalado un telescopio de 10”, robotizado y automatizado mediante ordenador, y diversos equipos que sirven tanto como servidor de las aplicaciones web, como de conexión y difusión de las imágenes y vı́deos que captan las webcams dispuestas por la cúpula. Todos corren con sistemas GNU/Linux. El principal objetivo del observatorio robotizado es controlar hasta el más mı́nimo detalle de un proyecto astronómico, automatizando todas las tareas y haciéndolas accesibles y controlables a través de Internet. Antes de su inauguración el observatorio astronómico de Montegancedo ya habı́a tenido varias experiencias participativas de éxito. Una de ellas tuvo lugar en julio del 2008, cuando colaboró en una observación divulgativa de los cráteres de la luna. La actividad se realizó en pantalla gigante en el museo Cosmo Caixa de Madrid y su retransmisión pudo seguirse en directo a través de Internet. 4 1.4. Trabajo del autor Este proyecto se inscribe en el marco del proyecto Ciclope[13]. Su realización se basa y complementa los siguientes sistemas existentes: Ciclope Weather[14]: estación meteorológica de la Facultad de Informática. Ciclope Astro[12]: Portal Web 2.0 permitiendo, entre otras funcionalidades, el control remoto del Observatorio Astronómico de Montegancedo. Para alcanzar los objetivos expuestos en este capı́tulo, el autor ha realizado los trabajos siguientes: Estudio teórico del estado del arte, tanto para la publicación de datos meteorológicos en Internet, como para la gestión de alarmas, aplicada al ámbito de un observatorio astronómico. Se encuentra en el capı́tulo 2. Registro de la estación meteorológica Ciclope Weather en las redes meteorológicas Awekas, CWOP, PWS, Wunderground y configuración de wview para subir los datos hacia ellas. Los pasos están documentados en el capı́tulo 3. Ligera modificación del software wview para adecuarse mejor a las exigencias de PWS. Dichos cambios están documentados en el anexo A. Elaboración de un informe sobre soluciones existentes para mandar SMS. Este informe se puede encontrar en el anexo B. Diseño e implementación del sistema Ciclope Alarms. Integración del mismo en el portal Ciclope Astro. Elaboración de un manual de usuario y un manual de instalació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 áreas tecnológicas que tienen un papel central en la realización de los objetivos planteados, que son: la publicación de datos meteorológicos y la concepción de un sistema gestor de alarmas para un observatorio astronómico. En la sección 2.1, se presenta el panorama general que constituye el flujo de datos meteorológicos, de la producción a la consumición de los mismos, detallando el papel de las redes y organizaciones involucradas en el proceso. En la sección 2.2, se describen varias formas de enfocarse a la problemática general de gestión de alarmas, en particular aplicada al ámbito de un observatorio astronómico. Se exponen brevemente las soluciones adoptadas por varios observatorios astronómicos, ası́ como soluciones software que pueden ser pertinentes para la implementación de un gestor de alarmas. Por fin, en la sección 2.3, se exponen las conclusiones del presente estudio del estado del arte. 2.1. Ciclo de vida de datos meteorológicos En esta sección se pretende detallar el ciclo de vida tı́pico que pueden conocer los datos meteorológicos, desde su producción hasta su consumo. En efecto, este ciclo de vida sigue un paradigma productor/consumidor, un productor es cualquier persona u organización disponiendo del material necesario a la colección de datos meteorológicos, y un consumidor es cualquier persona u organización interesada en información meteorológica. Este ciclo de vida está ilustrado sinté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 meteorológicos. En el apartado 2.1.2, se detallan las redes existentes que permiten el almacenamiento de los datos meteorológicos ası́ como la transformación y la transmisión de los mismos hasta los usuarios finales. Por fin, el apartado 2.1.3 se dedica a los distintos modos de consumo de información meteorológica. 7 Figura 2.1: Ciclo de vida de la información meteorológica 2.1.1. Producción La primera etapa, en el ciclo de vida de datos meteorológicos, es sin duda la producción de los mismos. Para generar datos meteorológicos, dispositivos hardware especı́ficos, o sensores son necesarios. Un sensor suele ser dedicado a la medición de una variable meteorológica en concreto, por ejemplo la temperatura, o la presión atmosférica. Por esta razón, se suelen agrupar en un mismo dispositivo, que constituye entonces una estación meteorológica, distintos sensores para medir un rango más o menos amplio de variables meteoroló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 meteoroló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 más general utilizarlos. Una lista de soluciones software que permiten operar una estación meteorológica se encuentra en la tabla 2.1. Cada solución software permite operar un rango más o menos amplio de estaciones meteorológicas. 8 Tabla 2.1: Soluciones software para operar una estación meteoroló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 estació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 estación meteorológica, almacenar los datos medidos y utilizarlos de manera local. 2.1.2. De los datos a la información: el papel de las redes de información meteorológica Si bien utilizar datos meteorológicos de una forma exclusivamente local puede tener un interés, en particular en la monitorización de una actividad local (aeropuerto, observatorio astronómico, planta. . . ), muchas aplicaciones, como la predicción meteorológica, requieren la recolección de datos de varios sitios, para posterior procesado en vista de convertir lo que son datos brutos en información valiosa. Las redes de información meteorológica cumplen esta doble función de intermediarios y transformadores entre los productores de datos (brutos) y los consumidores de información meteorológica. Se puede distinguir dos tipos de redes de información meteorológica, las redes oficiales, que operan con un paradigma jerárquico, recolectando datos meteorológicos de estaciones meteorológicas de confianza y varias redes privadas, que admiten además de los datos de las redes oficiales, datos procedentes de estaciones meteoroló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 están coordenadas a nivel internacional por la Organización Mundial de Meteorologı́a o World Meteorological Organization[74], que es un programa financiado por la ONU. Éste cuenta con la cooperación de 188 paı́ses y territorios miembros. Las redes de información meteorológica gestionadas por la OMM tienen una estructura jerárquica, con divisiones regionales, los Regional Telecommunication Hubs. Éstos están compuestos por redes nacionales, operadas por los organismos nacionales competentes. Por ejemplo, en España, este papel está desempeñ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 participació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 meteorológicas, descritas en el apartado 2.1.1, suelen incluir la funcionalidad necesaria para publicar datos meteoroló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 organización responsable de la estación meteorológica debe completar un proceso de alta antes de activar, en el software utilizado, la publicación de datos hacia las redes deseadas. Más detalles acerca de este tema se pueden encontrar en el capı́tulo 3. La figura 2.2 ilustra un ejemplo de configuración del software Meteohub, para publicar datos hacia distintas redes de información meteorológica. 2.1.3. Consumo de información meteorológica Existen varios canales de consumo de la información meteorológica. Tradicionalmente, dicha información meteorológica se consumı́a exclusivamente a través de los canales de comunicación que son la prensa, la radio y la televisión, en forma de informes meteorológicos, elaborados por los organismos oficiales de meteorologı́a. La revolución informática y el auge de Internet ha contribuido a la emergencia de nuevos canales de consumo. Hoy en dı́a, además de los medios tradicionales mencionados previamente, uno puede acceder a información meteorológica de manera informatizada, bien consultando páginas web dedicadas, bien instalando aplicaciones (paradigma cliente pesado) a este efecto. 10 Figura 2.2: Meteohub: configuración de publicación de datos hacia redes de información meteorológica (fuente: página oficial de Meteohub [43]) Elaborar una lista completa de las páginas web proporcionando información meteorológica es prácticamente imposible. Aún ası́, se pueden mencionar las siguientes: Páginas web de las agencias nacionales de meteorologı́a e.g. AEMet, o NOAA. Páginas web de las redes privadas mencionadas en el apartado 2.1.2. http://www.weather.com (número 1 en Alexa). http://www.accuweather.com/ (número 4 en Alexa). http://www.intellicast.com (número 7 en Alexa). Más pá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 información meteoroló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: página web oficial de WeatherBug [71]) En Mac OS, Meteorologist. La mayorı́a de las páginas web mencionadas en este apartado, ası́ como las redes de información meteorológica presentadas en el apartado 2.1.2, proveen algún widget, para instalar en entornos Windows o Mac OS. Por ejemplo, la red Weatherbug [71] publica en su página web, un widget para Windows, como se puede apreciar en la figura 2.4. Tanto las pá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 sección es estudiar el estado del arte de la gestión de alarmas en el ámbito astronómico, con el fin de ayudar a la concepción e implementación de un gestor 12 de alarmas adecuado para el Observatorio Astronómico Montegancedo. En el apartado 2.2.1, se exponen las soluciones adoptadas por varios observatorios astronómicos en el mundo. En el apartado 2.2.2, se repasan las soluciones software disponibles que permiten responder a la problemática planteada. 2.2.1. Observatorios astronómicos 2.2.1.1. Centro Astronómico Hispano-Alemán A.I.E. - Calar Alto (Almerı́a) El Observatorio Astronómico Hispano-Alemán de Calar Alto está situado en la Sierra de Los Filabres, norte de Almerı́a (Andalucı́a, Españ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, España. Calar Alto proporciona tres telescopios con aperturas de 1.23m, 2.2m y 3.5m. Un telescopio de 1.5m, también localizado en la montaña, es operado bajo el control del Observatorio de Madrid. Este observatorio dispone de un sistema de monitorización de las condiciones meteorológicas, de desarrollo propio y propiedad del observatorio. Consta de una estación meteorológica, del constructor noruego Aanderaa, de un módulo principal que interroga cada treinta segundos el hardware de la estación y propaga los datos hasta todos los módulos que los necesitan, cierre de los telescopios, advertencias, aplicaciones de visualización de los datos . . . . Cada telescopio tiene un grado de automatismo distinto. El más pequeño es totalmente robotizado y sirve de telescopio auxiliar, i.e. aporta información a los demás telescopios que son los que sirven para las observaciones astronómicas. Por otro lado, los más grandes siempre están controlados por astrónomos. El sistema de monitorización permite tomar decisiones automáticas como cerrar una cúpula. Las condiciones de apertura o cierre de una cúpula son fijas, preestablecidas y dependen del telescopio. En caso de producirse una alarma meteorológica que provoca el cierre de una cúpula, debido al fenómeno de histéresis8 , el sistema impide la reapertura de la cúpula durante un intervalo de tiempo determinado a partir del momento en el cual las condiciones meteoroló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 automáticamente la cúpula. Para poder volverse a abrir, tienen que transcurrir 15 minutos por debajo de 12 metros por segundo. Se pueden encontrar más detalles sobre las condiciones de apertura de las cúpulas en la página web del observatorio [9]. Adicionalmente, se puede encontrar más información acerca de la estructura del sistema informático de control del observatorio en una publicación de la revista Novática [32]. 2.2.1.2. Centro Astronómico de Yebes El Centro Astronómico de Yebes está situado a unos 70 km de Madrid, en el término municipal de Yebes, en la provincia de Guadalajara. Consta de dos radiotelescopios (uno 8 Fenó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 diámetro y otro muy reciente de 40 metros de diámetro) ası́ como dos telescopios ópticos. El sistema informático de control del centro incluye una estación meteorológica, ubicada a 1,5 km de los radiotelescopios para evitar las interferencias. Está conectada al resto del centro a través de fibra óptica. El software utilizado para el control del centro está 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 meteoroló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 está operativo sino que se encuentra en fase de implementación. El objetivo es una automatización completa del sitio. El sistema de control involucra una estación meteorológica Vaisala ası́ como un detector de nubes y un detector de tormentas. El software de control, de desarrollo propio, está basado en INDI [47]. Los lı́mites de funcionamiento están fijados en ficheros de configuració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 má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 diámetro ubicado en la cima del Mauna Kea, un volcán durmiente de Hawaii, que alcanza los 4200 metros de altura. Está en funcionamiento desde 1977. El observatorio está ahora mismo en proceso de renovació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 cú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 teléfono a los responsables técnicos, en caso de problema. 2.2.1.5. Subaru Telescope El Telescopio Subaru, operado por el Observatorio Astronómico Nacional de Japón, está ubicado en la cima del Mauna Kea, en Hawaii, no muy lejos del Canada-FranceHawaii Telescope. Es uno de los telescopios má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 má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 históricas. Proveer gráficos para cualquier sensor. Dar soporte a alarmas por correo electrónico, SMS y voz (sintetizada) por teléfono. Aún ası́, el sistema STS no toma decisiones como cerrar la cúpula de manera automática. Siempre hay operadores para llevar a cabo este tipo de tareas. Las alarmas se pueden definir de manera dinámica a través de un portal web, desarrollado en un lenguaje similar a PHP. Cada alarma está asociada a un sensor en concreto. Se puede definir el valor umbral que dispara la alarma, ası́ como el número de veces que se tiene que dar la condición antes de disparar la alarma. Esta última funcionalidad tiene un interés doble: descartar falsas alarmas disparadas por sensores muy sensibles y prevenir algún problema antes de que suceda (por ejemplo, configurando una primera alarma con un umbral inferior al que corresponde a una situación problemática y utilizar el parámetro de ocurrencias consecutivas). No se puede combinar varios sensores para definir una única alarma. Las acciones que se pueden llevar a cabo cuando se dispara una alarma son las siguientes: correo electrónico, SMS y llamada telefónica. Además se pueden consultar en el portal web. Sólo el correo electrónico y las llamadas por teléfono se consideran como un método fiable al 100 % para transmitir alarmas. Por ejemplo, la persona llamada puede teclear un código en su teléfono para confirmar al sistema la recepción de la alarma (y que va a actuar en consecuencia). El mayor problema con los mensajes SMS es que su entrega no está garantizada en un intervalo de tiempo concreto (en casos extremos se han visto retrasos de 48 horas en la recepció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 configuración de una alarma asociada a un sensor en concreto. 2.2.1.6. Observatorio robótico STELLA El observatorio robótico STELLA [5] está compuesto por dos telescopios robóticos (STELLA-I y STELLA-II), operando sin necesidad de intervención humana ninguna. El observatorio es un proyecto del Astrophysikalisches Institut Potsdam (AIP)9 y cuenta con la colaboración del Instituto de Astrofı́sica de Canarias (IAC). Está 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 observación, si las condiciones meteorológicas lo permiten y se cierran al final de la observación o si las condiciones meteorológicas 9 Instituto de Astrofı́sica de Potsdam. 15 Figura 2.5: Configuración de una alarma en STS (autor: David Cook) empeoran. La estación meteoroló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, está programado en Java. Los lı́mites definiendo las alarmas se pueden configurar mediante ficheros de configuración. Además de cerrar los techos, el sistema puede mandar correos electrónicos cuando se dispara una alarma. Más documentación acerca del observatorio robótico STELLA se puede encontrar en la página del observatorio [4]. 2.2.2. Soluciones software disponibles En esta sección, se estudian las soluciones software disponibles que permiten responder al menos en parte a la problemática de la gestión de alarmas para un observatorio astronómico. En el apartado 2.2.2.1, se presenta la solución actualmente utilizada en el Observatorio Astronó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 ámbito astronómico. Por fin, en el apartado 2.2.2.3 se presentan las soluciones disponibles parar solucionar un subproblema de la gestión de alarmas, el encadenamiento hacia adelante de reglas lógicas. 16 2.2.2.1. wview wview[66] es el software que gestiona actualmente la estación meteorológica de la facultad [14]. A parte de las funciones de recolectar, almacenar y publicar los datos meteorológicos de la estación, incluye un gestor de alarmas (wvalarmd). Su funcionamiento es sencillo por no decir rudimentario: se especifica en un fichero de configuración de texto plano cada variable que se quiere monitorizar, un valor de umbral, y la ruta hacia un script que se ejecutará cuando el valor de la variable monitorizada supere (o pase por debajo de según el caso) el valor umbral. Un ejemplo de dicho fichero de configuració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 configuración implica cambiar el fichero de configuración y reiniciar el software. No se pueden combinar variables distintas (cada una tiene un umbral y un script asociado). No permite la integració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 configuración de wview alarms Sin embargo, cabe destacar que el análisis del funcionamiento del gestor de alarmas de wview, ayudó en la fase de toma de requisitos del sistema Ciclope Alarms. Por ejemplo, se reutilizó la posibilidad de definir periodos de inhibició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 más activos son el ESO (European Southern Observatory) 17 Figura 2.6: Estructura de ACS (fuente: documentación de ACS [11]) y el CERN. Vio la luz a raı́z del proyecto ALMA, Atacama Large Millimeter Array, proyecto astronómico de cooperación internacional (Europa, EEUU, Canada, Japón, . . . ): un interferómetro compuesto por unas 64 antenas, ubicadas en el desierto chileno de Atacama. ACS proporciona una infraestructura software común, basada en CORBA, destinada a unificar los procedimientos de control y monitorización entre dispositivos hardware y software (muy numerosos) del observatorio, a la vez que abstrayendo los protocolos de comunicación subyacentes. La figura 2.6 ilustra la arquitectura de ACS. ACS consta de un sistema de alarmas, gracias a la contribución del CERN y heredado del LHC (Large Hadron Collider). Desgraciadamente, además de tener una complejidad abrumadora, é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 está enfocado a la monitorizació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 definición de una misma alarma. Además, supone la instalación de todo el framework ACS. 2.2.2.3. Motores de inferencia En una fase temprana de la realización de este proyecto, apareció claro que el sistema Ciclope Alarms debiera ser capaz de, por un lado leer los datos correspondientes a las variables monitorizadas (meteoroló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 términos, tiene que actuar como un motor de inferencia lógica. Llegado a este punto, quedó 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 opció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 más particularmente del sistema elegido finalmente, Drools. En el párrafo 2.2.2.3.1, se mencionan brevemente los motores de inferencia estudiados, y los criterios que han llevado a la decisión final, antes de centrarnos en ésta, en el pá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 rápidamente por no ser de código abierto. CLIPS fue descartado por no utilizar Java. Mandarax, publicado bajo la licencia LGPL, no acabó siendo muy adecuado para este proyecto al proporcionar encadenamiento hacia atrás y no hacia adelante. Open Rules entra una categorı́a llamada BRMS (Business Rules Management Systems) y su enfoque es claramente de utilización en empresas (reglas utilizando MS Excel, . . . ) por lo que no convenció demasiado tampoco. Hammurapi Rules era una opción viable pero resultó ser menos completa (por lo tanto implicando más desarrollo de software), y con menor utilización que Drools. Por fin Drools, a veces denominado JBoss Rules, pareció una buena opción por las razones siguientes: Código abierto (licencia ASL i.e. Apache). Integració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: documentación de Drools [39]) Figura 2.8: Esquema de un motor de reglas (fuente: documentació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 Lógica de Primer Orden en cuanto a la representació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 ló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 implementación se denomina ReteOO para subrayar el hecho de que está optimizada para sistemas orientados a objetos. Cabe destacar que existen extensiones propietarias (no publicadas) del algoritmo 20 Rete, implementadas en motores de reglas de código cerrado. Por razones obvias, no se detallarán aquı́. Varias de las alternativas a Drools estudiadas en la sección precedente también implementan el algoritmo Rete. Las reglas se almacenan en la memoria de producció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: compilación de reglas y ejecución. El algoritmo de compilación describe como las reglas definidas en la Memoria de Producción pueden generar una red de discriminación eficaz. En términos no técnicos, una red de discriminación se usa para filtrar los datos. La idea es filtrar los datos según se vayan propagando en la red. El lector interesado en los pormenores del algoritmo podrá 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 implementación ReteOO incluyen optimizaciones en el proceso de encadenamiento lógico, tales como por ejemplo sistemas de caches, indexación de los resultados, permitiendo que el sistema gane en eficacia y escalabilidad, dado que no tiene que evaluar siempre las condiciones lógicas en su totalidad (en pocas palabras, se comparten entre reglas similares los resultados de la evaluación de condiciones lógicas idénticas. . . ). Para ilustrar lo anterior, se puede hacer la prueba siguiente: elaborar un conjunto sencillo de reglas lógicas, similares a las que se definirán en Ciclope Alarms (i.e. basadas en variables meteoroló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 evaluación de una condición lógica simple e.g. windSpeed > 12.0 (2). Los cı́rculos amarillos representan la evaluación de la condición ló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 lógicas simples como windSpeed > 12.0 aparecen en varias reglas. Aún ası́ solo tenemos un cı́rculo azul, significando que la evaluación sólo se hará una vez y se guardará en memoria para utilización en otras reglas. De la misma manera, las reglas 2 y 3 tienen la misma condición global o sea que ’comparten’ el mismo cı́rculo amarillo, que apunta a dos acciones (cı́rculos negros) distintos. La optimizació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 lógicas simples y 4 combinaciones. Con ReteOO, bajamos a la evaluación de 3 condiciones lógicas y 3 combinaciones. 22 2.3. Conclusiones Esta fase previa a la elaboració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 publicación de datos meteorológicos, expuesto en la sección 2.1, ha permitido aclarar los conceptos teóricos necesarios a la resolución del primer objetivo planteado en este proyecto fin de carrera y cuya realización está expuesta en el capı́tulo 3. Segundo, el estudio de las soluciones realmente implementadas en observatorios astronómicos ha tenido un tremendo interés. Se ha visto que las soluciones adoptadas difieren mucho de un observatorio a otro, dependiendo de las exigencias de automatización, o flexibilidad requeridas. La mayorı́a de ellos utilizan soluciones software desarrolladas en interno. Aún ası́, algunos promueven la reutilización de software, utilizando frameworks de código abierto como INDI [47], IRC [48], o ACS [20]. Si bien estos frameworks pueden tener un interés para el Observatorio Astronómico de Montegancedo, no solucionan de manera satisfactoria la gestión de alarmas que se quiere implementar. Por fin, el estudio del estado del arte sobre motores de inferencia, ha hecho posible la elección de un componente software (Drools) permitiendo solucionar parte del problema de la gestión de alarmas, el encadenamiento hacia adelante de reglas lógicas. 23 24 Capı́tulo 3 Publicar datos meteoroló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 estación meteorológica del Observatorio Astronómico Montegancedo para que los mismos sean accesibles para el mayor número de personas posibles. Se ha visto en la sección 2.1 que para que la información meteorológica llegue al mayor número posible de usuarios finales, dicha información tiene que transitar por las redes de información meteorológica asentadas. A lo largo del capı́tulo se detallan los pasos que han sido necesarios para poder publicar datos meteoroló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 patrón común. Se pueden dividir en tres pasos: 1. Dar de alta la estación en el servicio / Obtener un ID (opcional). 2. Configurar el software de la estación para el servicio. 3. Comprobar el buen funcionamiento / Hacer modificaciones en la configuración del servicio. 25 Cabe destacar que este capı́tulo ha sido redactado con la intención de ser lo más reutilizable posible, en el sentido de que pueda servir de guı́a para cualquier persona u organización deseando publicar los datos de una estación meteorológica. Por este motivo, siempre y cuando ha sido posible, las explicaciones son genéricas y deberı́an de poder aplicarse en cualquier caso. Los pasos 1 y 3 no dependen ni del tipo de estación ni del software utilizado. Sin embargo, la realización del segundo paso depende altamente de ambos componentes por lo cual las explicaciones acerca de este paso sólo se aplican al caso de una estación Davis Vantage Pro 2 [18], operada con el software wview[66], combinación utilizada en el Observatorio Astronómico Montegancedo. 3.1. Localización de la estación Antes de entrar en los detalles del proceso de alta de cada servicio en concreto, conviene hacer un breve repaso sobre coordenadas geográficas. En efecto, todos los servicios detallados a continuación necesitan las coordenadas geográficas de la estación meteorológica bien sea durante el propio proceso de alta bien sea más tarde durante la configuración de la estación. Dichas coordenadas incluyen: Latitud. Longitud. Altitud. Unas coordenadas geográficas solo tienen sentido en el contexto de un sistema geodésico concreto (llamado también datum) ya que es éste quien define rigurosamente las referencias necesarias para poder medirlas. En todo el resto del documento, salvo mención explicita del contrario, las coordenadas geográficas se referirán al sistema geodésico WGS84[67]. Se trata del único sistema geodésico funcionando a nivel global (i.e. toda la Tierra) y es un está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 ángulo expresando la posició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 añadir la letra N para Norte (North) o S para Sur (South) o el signo + para Norte o - para Sur. Una notación correcta será entonces -34°o 34°S. Cabe destacar que se puede encontrar la notación, redundante, -34°S. 3.1.2. Longitud La longitud es un ángulo expresando la posición este-oeste de un punto en la Tierra, calculada desde el meridiano de Greenwich (llamado a veces meridiano cero). Toma 1 En España, se utiliza por ejemplo el datum europeo ED50. 26 Figura 3.1: Latitud y longitud (autor: José Alberto Bermúdez y el Instituto Superior de Formació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 añadir la letra E para Este (East), W para Oeste (West) o el signo + para Este, - para Oeste. Una notación correcta será entonces -175°o 175°W. Cabe destacar que se puede encontrar la notación, redundante, -175°W. La figura 3.1 ilustra los conceptos de latitud y longitud. 3.1.3. Altitud La altitud es la elevación vertical de un punto respecto a una referencia dada. En nuestro caso, la referencia será el nivel del mar (medio)2 . Esta medida puede ser positiva o negativa según el caso. El cálculo preciso de la altitud queda fuera del ámbito de este documento. Sin embargo, no se suele necesitar un nivel de precisión muy alto para estaciones meteorológicas. Uno de los aspectos más relevantes de la altitud en cuanto a estaciones meteorológicas es que tiene cierta influencia sobre la presión atmosférica. A bajas altitudes (menos de cuatro kilómetros o sea cualquier lugar habitable) la presión disminuye en 1,25 mbar cada 10 metros.[59] Sabiendo que una medición normal ronda los 1000 mbar (i.e. una atmósfera), una diferencia de 100 metros induce una deferencia relativa de presión del orden del 1 %. . . En la sección 3.1.5, se verá algunas técnicas para medir o inferir la altitud de una estación meteorológica con una precisión razonable. 2 En España, la referencia es Alicante. 27 3.1.4. Tipos de unidades para coordenadas y conversiones Si la definición de latitud, longitud o altitud plantea poca ambigüedad 3 , el sistema de unidades utilizado para expresar dichas coordenadas puede variar de un servicio meteorológico a otro lo cual puede llevar a confusiones y pequeños desajustes. Se detallan a continuación los sistemas de unidades más utilizados ası́ como té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 inglé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 é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 rápidas y fiables entre DMS, DD y formato LORAN, se recomienda el uso de la siguiente pá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 conversión es fácil, 1f t = 0, 3048m 1m = 3, 2808f t Existen muchas páginas web capaces de realizar este tipo de conversión. Por ejemplo, buscar en Google la frase ’xx metros en pies’ da el resultado de la conversión automáticamente [29]. 3.1.5. Técnicas para obtener coordenadas geográficas Para obtener las coordenadas geográficas de un punto, existen varias técnicas que podemos dividir en dos tipos: Medición directa. Servicios de localización en Internet. Cabe destacar que dentro del ámbito de este documento, sólo se pretende exponer brevemente algunas técnicas permitiendo obtener, de manera práctica y con un grado de precisión razonable, las coordenadas geográficas de una estación meteorológica y no hacer un estudio exhaustivo sobre geolocalización. El lector interesado podrá encontrar más información sobre geodesia en los siguientes artı́culos de la NGA[50] o, en castellano, en las páginas del IGN, especialmente en su glosario cartográfico[36]. 3 Al menos, para el nivel de precisión requerido en este campo. 28 Medición directa Para medir directamente coordenadas geográficas, se puede utilizar un receptor GPS. Dado la variedad de receptores disponibles en el mercado, es imprescindible referirse a la documentación del receptor utilizado para conseguir mediciones de buena calidad. Según el modelo, puede hacer falta añadir a la medició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 corrección. La precisión de los receptores GPS ha ido incrementando con el tiempo4 . Se puede, en algunos casos, conseguir una precisión del orden de 20 metros o hasta 2 metros utilizando GPS diferenciales (DGPS). Cabe destacar que la precisión vertical (medición de altitud) siempre es peor que la precisión horizontal en un factor 2 aproximadamente (por puras razones matemáticas). En caso de que dicha precisión sea peor que 10 metros, se recomienda el uso de un altı́metro (bien calibrado). Algunos modelos de estación meteoroló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 acrónimo para Automatisches WEtterKArten System o Sistema automático de mapas meteorológicos. Como su nombre indica, este sistema genera mapas a partir de la información proporcionadas por estaciones meteorológicas. A contrario de otros servicios de este tipo (como los detallados a continuación), no es la estación meteorológica que manda los datos sino el propio sistema Awekas que recoge los datos generados por la estación. Para conseguir eso, la estación tiene que generar un fichero conteniendo los datos meteorológicos y guardarlo en un lugar accesible desde Internet (en una página web). Ası́ Awekas podrá, periódicamente recuperar dicho fichero y utilizar la 4 Sobretodo desde que E.E.U.U. desactivó la Selective availability[73]. 29 Figura 3.2: Dar de alta una estación en Awekas información. Cabe destacar que este proceso de generación de ficheros está soportado por wview por lo que solo hace falta darse de alta en la página de Awekas y activar/configurar este servicio en wview, como viene detallado a continuación. 3.2.1. Darse de alta La página para dar de alta una nueva estación está en el menú Community y dentro de ello, en el submenú 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 continuación, se proporcionan algunas recomendaciones para rellenar los datos que hacen falta: Desactivar el campo Email Public (cuidado está activado por defecto). Longitud y latitud: en formato DMS. Date format: YYYYMMDD (si se utiliza wview). 30 Localization: es el nombre bajo el cual aparecerá la estación. Report mode: seleccionar wview. Path to the data file: URL donde Awekas podrá recoger el fichero de datos generados por wview (u otro). En principio será url base/awekas wl donde la url base es la URL donde se publican los datos de la estación. Después de salvar los datos, un correo electrónico será mandado a la dirección de correo proporcionada. Dicho correo electrónico contiene un código de activación. Este có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 Añadir (o descomentar si ya existe) este fragmento en el fichero de configuració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 página de configuración de Awekas. Awekas es capaz de recuperarlos y no ve ningún problema en cuanto a la forma. Para eso, en la página de Datos del usuario[6], se debe pulsar el botón Test Datafile. Si todo está 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 estació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 España en Awekas Mapa (en el menú Community, Member Map) e.g. para España http://www.awekas. at/en/mitgliederkarte.php?nid=8. Véase la figura 3.3. Página resumen datos de la estació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. Véase la figura 3.4. Otro enlace interesante es la página de comprobación de calidad de los datos: http: //www.awekas.at/en/qualcheck.php?id=4936. Allı́ comparan los datos de una estación con los datos recibidos de otras estaciones del vecindario. Desde la página de la estación se puede acceder pulsando el botón to quality checking system. 3.2.4. Cambiar la configuración a posteriori La página para cambiar los datos de una estación ya registrada está en el menú Community y dentro de ello, en el submenú Change user data. Se pedirá el nombre de usuario y la contraseña previamente escogida. La URL directa es la siguiente:http://www.awekas. at/en/benutzer.php Se puede cambiar cualquier parámetro sin problema (incluso nombre de usuario, dirección de correo electrónico, contraseña, etc. . . ) 32 Figura 3.4: Red Awekas en Google Earth 33 Figura 3.5: Petición de un Call Sign id para CWOP 3.3. CWOP CWOP es el acrónimo para Citizen Weather Observer Program i.e. el Programa de Observación Meteorológica Ciudadano. Su página se puede encontrar en la URL: http: //www.wxqa.com/. Se trata de un servicio meteorológico al cual cualquier persona con una estación meteorológica y el software adecuado puede publicar los datos meteorológicos colectado por dicha estación. Los datos son a continuación accesibles libremente. La NOAA (National Oceanographic and Atmospheric Administration)[53] por ejemplo explota datos almacenados por el programa CWOP para elaborar previsiones meteorológicas (entre otras cosas). Para participar en el programa CWOP, se necesita un id llamado APRS Call Sign. (Véase sección 3.3.1). Una vez conseguido ese id, hace falta configurar wview adecuadamente (véase sección 3.3.2). Una vez hecho eso, wview mandará datos a los servidores de CWOP cada vez que se genere un nuevo archivo de datos (o casi, ver Sección 3.3.2 para más detalles). 3.3.1. Darse de alta Para conseguir un Call Sign id, hay que rellenar un formulario en la página siguiente: http://www.findu.com/citizenweather/signup.html. Es bastante simple (se piden bastante pocos datos, ya que los datos esenciales como coordenadas geográficas están mandados por wview en cada paquete de datos). Se incluye, en la figura 3.5, una captura de pantalla del formulario de petición del Call Sign id. La asignación de un Call Sign id es inmediata (no necesita activación por correo electró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 intentará 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 pá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 página previamente mencionada): 1. cwop1.tamu.edu. 2. cwop.fuller.net. 3. sip.tssg.org. Para todos el puerto es 23. Hace también falta tener las coordenadas geográficas de la estación en formato LORAN, tal y como se ha explicado en la sección 3.1.4. Cuidado: los grados tienen dos dı́gitos para la latitud (ángulo entre 0 y 90 grados) y tres para la longitud (ángulo entre 0 y 180 grados). Los ceros tambié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 ningún tipo de comprobació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 segú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 generación de archivos meteorológicos. Si se generan archivos más a menudo que cada 10 minutos (e.g. cada 5 minutos), wview los enviará 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 último dı́gito del Call Sign id. Por ejemplo, con un id DW2192, los datos se mandarán a las 10:02, 10:12, 10:22. . . 5 Más detalles en el manual de wview [65]. 35 Figura 3.6: Datos de una estación meteorológica en CWOP 3.3.3. Comprobar el buen funcionamiento 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, vé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 página: http://www.findu.com/cgi-bin/errors.cgi Si es el caso, hace falta comprobar la configuración de wview, y el formato de los datos enviados. Una página muy útil es la sección de FAQ de CWOP: http://www.wxqa.com/faq.html Cuando todo está bien, se puede mandar un correo electrónico de confirmación a los contactos de CWOP. Se trata de Russell Chadwick: mailto:Russell.B.Chadwick@noaa. gov. 36 3.3.4. Cambiar la configuración a posteriori En caso de cambio de contacto (persona o correo electrónico) o cambio de coordenadas, altitud. . . , hace falta avisar, por correo electrónico, a la persona contacto de CWOP de los cambios. Se trata también de Russell Chadwick: mailto:Russell.B.Chadwick@noaa. gov. 3.4. Weather Underground Weather Underground[70] es una empresa que proporciona servicios meteoroló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 estación meteorológica y acceder a unas cuantas gráficas realizadas con los datos subidos por las estaciones meteorológicas de la red. 3.4.1. Darse de alta Para dar de alta una estación en Weather Underground, hay que: 1. Crear una cuenta de usuario en Weather Underground. 2. Crear una estación meteorológica con este usuario. Para la primera etapa, hace falta rellenar un formulario en la página siguiente: http:// www.wunderground.com/members/signup.asp. Hace falta activar la cuenta con el código que mandan automáticamente por correo electrónico (como para Awekas). Para la segunda etapa, hace falta rellenar un formulario en la página siguiente: http://www.wunderground. com/wxstation/signup.html Las coordenadas se tienen que poner en formato decimal. En la misma página, viene un widget de Google maps que permite localizar fácilmente la estació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 generación del ID es inmediata; éste aparece en la página web despué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 distribución GNU/Linux utilizada. En Ubuntu por ejemplo, se tratará del paquete libcurl3. El paquete etiquetado dev (e.g. libcurl4-openssl-dev) también será 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 código fuente de wview. ./configure [station_enable_str] --enable-http 37 Figura 3.7: Formulario de Weather Underground Opcionalmente se puede añadir al mando anterior –enable-mysql si se utiliza una base de datos MySQL make install 3. Ejecutar el script de configuració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 parámetros relativos a Weather Underground cuando pedidos 4. Rearrancar wview. [ruta_ejecutable_wview]/wview start 3.4.3. Comprobar el buen funcionamiento Se puede comprobar el buen funcionamiento del servicio en la página: http://www. wunderground.com/weatherstation/WXDailyHistory.asp?ID=## donde hace falta sustituir las # por el código identificador. Véase la figura 3.8 38 Figura 3.8: Datos de una estación meteorológica en Weather Underground 3.4.4. Modificar la configuración a posteriori Salvo el nombre del usuario, todo se puede cambiar una vez activada la estación, en la página: http://www.wunderground.com/wxstation/signup.html Hace faltar pulsar el botón edit para cambiar la configuración de la estación. 3.5. Red Personal Weather Stations En esta sección, se va a detallar el caso de la red de Personal Weather Stations. Se trata, como Weather Underground tratado en la sección 3.4 de una organización privada pero tiene la particularidad de ser la asociació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 páginas web, se basan en la misma red de estaciones meteorológicas. 39 Figura 3.9: Formulario de PWS 3.5.1. Darse de alta El proceso de alta de estación es común para toda la red Personal Weather Stations / Weather for you / Hamweather. La configuración y el envı́o de datos también lo es, lo cual simplifica bastante todo el proceso. Para dar de alta una estación en la red PWS, hay que: 1. Crear una cuenta de usuario en PWS. 2. Crear una estación meteorológica con este usuario. Para la primera etapa, hace falta rellenar un formulario en la página siguiente: http:// www.pwsweather.com/register.php Hace falta activar la cuenta con el código que mandan automáticamente por correo electrónico (como para Awekas). Para la segunda etapa, hace falta rellenar un formulario en la pá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 (después de comprobar que no está siendo utilizado). 40 3.5.2. Configurar wview Los pasos a seguir son los mismos que para Weather Underground, detallados en la sección 3.4.2 3.5.3. Comprobar el buen funcionamiento Se puede comprobar que los datos se suben bien en las URL siguientes: Para Personal Weather Stations, http://www.pwsweather.com/obs/##.html. Vé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. Cambiar la configuración a posteriori Se pueden cambiar todos los detalles de configuración de la estación en la página: http://www.pwsweather.com/stations/profile/##.html (hay que sustituir las # por el identificador de la estación). 41 Figura 3.10: Datos de una estación meteoroló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 según las distintas fases del ciclo de vida de un proyecto de desarrollo software tı́pico: toma de requisitos, diseño, implementación e integración. Durante la realización de este Proyecto Fin de Carrera, se siguió un ciclo de vida por iteraciones cortas validadas por demos, por lo cual las fases mencionadas no fueron secuenciales sino más bien se complementaron una a otra, permitiendo a veces identificar problemas en los requisitos o en el diseñ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 grá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 concepción y realización de cualquier producto software, se identificaron los requisitos del sistema Ciclope Alarms. La mayor dificultad de esta fase quizás consistió en priorizar ciertos requisitos y elegir un conjunto de requisitos final que permitiera la implementación de una primera versión del sistema, consistente, funcional, y fácilmente extensible. Parte de los requisitos descartados durante este proceso se pueden encontrar en la sección 7.2. El producto de esta fase es una Especificación de Requisitos Software, o ERS, redactada según el estándar 830 del IEEE [35]. Se puede encontrar en el anexo C. Por comodidad, se incluye a continuación un resumen de la misma. 4.1.1. Propósito general El sistema Ciclope Alarms tiene como propósito general permitir la creación y la gestión de alarmas en un observatorio astronómico, utilizando las variables disponibles, en particular las condiciones meteorológicas. Además de dar soporte a la edición y gestión de alarmas, el sistema deberá de proporcionar funciones de administració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 genérico, se tendrá que integrar en el portal web existente Ciclope Astro. 4.1.2. Edición de Alarmas Un usuario del sistema debe poder crear alarmas, y una vez creadas, modificarlas o suprimirlas. Debe poder especificar las condiciones lógicas de activació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 electrónicos, mandar mensajes SMS, y hacer aparecer un mensaje de advertencia en la interfaz gráfica del sistema. Dicha lista de acciones se deberá poder ampliar fácilmente. Un usuario del sistema debe poder suscribirse a alarmas definidas por otros usuarios. En este caso, no puede cambiar las condiciones de activació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 deberá incluir un sistema de permisos, accesible a los administradores, que defina los lı́mites de utilización del sistema por parte de los usuarios. 4.1.3. Administració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 modificación sobre las mismas, incluyendo editarlas, suprimirlas, activarlas y desactivarlas. 44 Un administrador del sistema debe poder configurar los lı́mites de utilización del sistema por cada perfil de usuario existente. Ademá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 Además de los requisitos funcionales brevemente descritos en los apartados anteriores, se han incluido unos requisitos no funcionales: El diseño debe de ser lo suficientemente genérico como para facilitar las siguientes ampliaciones del sistema: nuevos tipos de acciones, nuevas variables de monitorización, nuevos observatorios a monitorizar. La solución debe utilizar exclusivamente software libre, compatible con la licencia GNU GPL [25]. 4.2. Diseño El diseñ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 fácilmente y de manera gráfica las grandes ideas de un diseño. En esta sección se incluyen los diagramas UML relevantes de la fase de educción de los requisitos i.e. los diagramas de Casos de Uso, que organizan los requisitos establecidos en el anexo C. Se incluye también el modelo conceptual que define los conceptos claves de la lógica de negocio del sistema. 4.2.1. Casos de Uso El diagrama de casos de uso de más alto nivel se encuentra en la figura 4.2. A continuación se hace una descripción de los actores involucrados antes de describir brevemente cada caso de uso, ası́ como sus correspondientes subcasos. 4.2.1.1. Descripción de los actores Usuario: Se trata de un usuario cualquiera del sistema. Puede o no ser un administrador, en cuyo caso tendrá acceso a más funcionalidades del sistema. Por la integración con el portal Ciclope Astro, se tratará de un usuario del mismo portal. Administrador: Se trata de un superusuario del sistema. Tiene, además de las funciones accesibles a cualquier usuario, acceso a las funciones de administració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 más bien abstracto. Representa el conjunto de condiciones externas que puede originar la activación de una alarma en el sistema. Condiciones meteorológicas: Se trata de un caso particular (un subconjunto por ası́ llamarlo) del actor Entorno previamente descrito. Representa el conjunto de variables meteorológicas colectadas por la estación meteorológica. En el ámbito de esta entrega, se tratará del único actor de tipo Entorno. 4.2.1.2. Descripció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. pú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 suscripción. Un caso particular de este subcaso de uso es Activar una suscripción o Desactivar una suscripción. • Suprimir una suscripción. Caso de Uso Activar Alarma: El actor principal de este caso de uso es el Entorno dado que es quien inicia la activación de una alarma cuando se dan las condiciones de activació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 inhibición de la alarma, nú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 suscripción). El usuario puede participar en este caso de uso si es receptor de una de las acciones (correo electró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 bú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 utilización del sistema aplicables a cada perfil de usuario. Puede también definir excepciones para usuarios en concreto siempre y cuando dicha excepción es más restrictiva que los permisos asociados al perfil correspondiente. 4.2.2. Modelo conceptual El modelo conceptual es ú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 activación de las mismas, ası́ como las acciones (cada una perteneciendo a un tipo de acció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 monitorización y nuevos tipos de acciones. El lector interesado en estos temas puede referirse a la sección 4.4. 49 Figura 4.6: Modelo conceptual 50 4.3. Implementació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 grá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 están interconectadas para llevar a cabo operaciones especı́ficas mediante el uso de Java RMI (Remote Method Invocation). Estas operaciones incluyen la comunicación necesaria para monitorizar y operar el motor de alarmas desde la GUI, ası́ como la notificación de alarmas de tipo popup desde el motor de alarmas hacia la GUI. La interfaz gráfica es un mó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 ámbito de este proyecto fin de carrera, este módulo se ha integrado en el portal Ciclope Astro. Los demás componentes implicados en el funcionamiento del sistema son el módem GSM, que el motor de alarmas utiliza para mandar SMS cuando se ejecutan alarmas de este tipo, un servidor de correo electrónico, que tanto la interfaz gráfica como el motor de alarmas utilizan, y el flujo RSS producido por la estación meteorológica. Todo el sistema Ciclope Alarms necesita acceder a la base de datos donde está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 también otros esquemas representando subconjuntos del modelo de datos. El modelo de permisos está en la figura 4.10, el modelo de alarmas está en la figura 4.8 y el modelo de suscripciones está en la figura 4.9. A continuación se incluye una descripció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 informació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 definió la alarma. Esta relación está 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 activación de una alarma tiene una estructura de árbol y sigue el patrón composite. Un registro de la tabla ALARMS está relacionado, a través de la clave ajena LOGICAL CONDITION ID, a la condición lógica raı́z guardada en la tabla COMPOUND CONDITIONS. COMPOUND CONDITIONS: Esta tabla guarda las condiciones lógicas compuestas de activación de una alarma. Cada condición compuesta tiene una serie de hijos (al mı́nimo uno) que pueden ser compuestos también o simples (SIMPLE CONDITIONS), siguiendo el patrón composite. Cada registro tiene los siguientes campos: • LOGICAL OPERATOR: Operador lógico (AND o OR) definiendo la relación lógica entre las condiciones hijas (compuestas y/o simples). • IS POSITIVE CONDITION: campo binario. Si toma el valor false, invierte el sentido lógico de la condición compuesta (NOT). • ID PARENT: clave enlazando a la condición compuesta padre en la misma tabla, si la hay. Puede ser NULL si la condición compuesta es la condición raı́z de una alarma. SIMPLE CONDITIONS: Esta tabla guarda las condiciones lógicas simples de una alarma. Cada registro tiene los siguientes campos: • THRESHOLD: umbral de la condició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 condición simple. • ID PARENT: clave ajena enlazando a la condición compuesta padre en COMPOUND CONDITIONS. • LOG ALARMS ACTIVATED: Esta tabla guarda el log de las activaciones de las alarmas del sistema. Cada registro está relacionado con una alarma en concreto a travé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 está relacionado con una alarma en concreto a través de la clave ajena ID ALARM hacia la tabla ALARMS. • TBL ASTRO OBSERVATORIES: Esta tabla almacena información básica acerca de los observatorios dados de alta en el sistema. El campo SHORT NAME es un código utilizado en el sistema para identificar el observatorio. • ACTIONS: Esta tabla almacena la información relativa a las acciones asociadas a una alarma o una suscripción. Los campos SUBJECT y TEXTUAL DESCRIPTION guardan la información de personalización de las acciones definida por los usuarios. Por ejemplo, SUBJECT puede guardar el asunto del correo electrónico que se tiene que mandar cuando se ejecute la alarma. Cada acció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 acció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 acción. • MTM USER ROLES ACTIONS: Esta tabla guarda los receptores de tipo perfil de una acción. • MTM UNREGISTERED USERS ACTIONS: Esta tabla sirve para guardar receptores anónimos, i.e. correspondiendo a personas no dadas de alta en el sistema como usuario. Se utiliza el campo genérico CONTACT INFORMATION para guardar según el caso direcciones de correo electrónico o números de teléfono. • TBL ASTRO USERS: Esta tabla guarda la información relativa a los usuarios del sistema. Es idéntica a la tabla de usuarios de Ciclope Astro. Sólo se modificó para añadirle el campo MOBILE PHONE, que permite almacenar un número de mó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 información relativa a las suscripciones definidas en el sistema. Un registro representa una suscripción. Una suscripción está relacionada con una alarma, a través de la clave ajena ID ALARM. Una suscripció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 sección 4.3.2.1. TB ASTRO USERS: explicada en la sección 4.3.2.1. ACTIONS: explicada en la sección 4.3.2.1. TYPES OF ACTION: explicada en la sección 4.3.2.1. MTM USERS ACTIONS: explicada en la sección 4.3.2.1. MTM USER ROLES ACTIONS: explicada en la sección 4.3.2.1. MTM UNREGISTERED USERS ACTIONS: explicada en la secció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 genérico i.e. no asociados a ningún tipo de acción en concreto para cada perfil de usuario. El campo TYPE OF GENERAL PRIVILEGE es el nombre del pará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 excepció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 acción en concreto para cada perfil de usuario. El campo TYPE OF ACTION SPECIFIC PRIVILEGE es el nombre del pará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 acció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: Configuración Por fin, las siguientes tablas constituyen el submodelo de configuració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 está 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. Sólo aplica si TYPE es PartialTime. • STOP: hora de cierre. Só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 sólo se pretende describir en el presente apartado la capa de lógica de negocio. La capa de acceso de base de datos (utilizando Ibatis), puramente té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 gráficos (widgets, panels, y otros componentes de GWT) tampoco se detallan aquı́. Sin embargo, se mencionarán brevemente en el apartado 4.3.4. La implementación de la parte central del modelo de ló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 implementación del patrón de diseño Composite con las clases LogicalExpression, MultipleCondition y SimpleCondition. LogicalExpression es una clase abstracta representando cualquier tipo de condición lógica. MultipleCondition y SimpleCondition heredan de este clase. Una instancia de la clase MultipleCondition tiene hijos de tipo LogicalExpression que son, conforme al patrón Composite, bien de tipo SimpleCondition o bien de tipo MultipleCondition. Este modelo Composite permite expresar cualquier anidación de condiciones lógicas que se pueda necesitar en la definició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 método toI18nString(), responsable de proporcionar una descripción del objeto, traducida al lenguaje deseado según las técnicas de internacionalizació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 activación. En efecto, el motor de alarmas necesitar actualizar la lista de alarmas que tiene que operar para incluirla. Cuando es el caso, é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 pasará a ser Descactivada por el administrador. Si el usuario modifica la alarma, ésta pasará a ser Pendiente de revisió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 esté activa (Operativa, Pendiente de activación o Pendiente de cambio). En este caso, el estado de la alarma pasa a ser Desactivada por el usuario. Puede reactivarla más tarde bajo ciertas condiciones, detalladas en la sección 5.1.2. 4.3.4. Integración de la GUI con Ciclope Astro A lo largo de la implementación de la GUI del sistema Ciclope Alarms, se intentó , en vista de una buena integración al portal existente Ciclope Astro, ceñirse a las normas de diseño y de nombrado en vigor en el proyecto Ciclope Astro. Como mencionado en la sección 4.3.1, la interfaz gráfica de Ciclope Alarms es un módulo GWT. Se puede utilizar en modo standalone, llamando al módulo descrito en el fichero AlarmConfiguratorStandAlone.xml o integrarlo dentro de otra aplicación web 62 Figura 4.14: Interfaz gráfica - modo standalone llamando al módulo descrito en el fichero AlarmConfigurator.xml. La única diferencia entre ambos módulos es la clase responsable de inicializar el módulo, conocida como entry-point en la terminologı́a GWT. La sección 6.4 proporciona más detalles sobre la utilización del sistema Ciclope Alarms en modo standalone. La figura 4.14 incluye una captura de pantalla de la interfaz gráfica de Ciclope Alarms en modo standalone. Los pasos seguidos para integrar el módulo en el portal web Ciclope Astro han sido los siguientes: Actualización/adición de librerı́as: Ibatis, Log4J, . . . Cambios de configuració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 módulo Ciclope Alarms. 63 Figura 4.15: Interfaz gráfica - integrado con Ciclope Astro Carga de la estructura de tablas necesarias mediante scripts sql (véase sección 6.2 para más detalles). Único cambio en el có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 gráfica de Ciclope Alarms, integrada en el portal Ciclope Astro. 4.3.5. Motor de Alarmas En este apartado, se detalla la implementación del motor de alarmas del sistema Ciclope Alarms. Dicho motor de alarmas incluye un motor de inferencia lógica Drools [40]. Tiene vocación a ejecutarse como un demonio del sistema. Para llevar a cabo tal propósito, utiliza la librerı́a de Apache Commmons-Daemon, basada para su versión ’Unix’ en jsvc (servicios Java en entornos tipo Unix)[2]. En una instalación tı́pica (véase secció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 periódicamente los valores de las variables monitorizadas (en el ámbito de este entrega, las variables de la estación meteorológicas, publicadas en un flujo RSS), comprobar si dichas condiciones cumplen con las condiciones de activació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 planificación periódica de hilos de ejecució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 implementación del motor de alarmas se encuentra en la figura 4.16. Destaca la definición de varias interfaces, que permite facilitar ciertas ampliaciones previstas del sistema, como se ha detallado en la sección 4.4. En efecto, cualquier clase responsable de ejecutar una acció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. También inicializa el servidor RMI que permite mantener comunicaciones y control remoto con la interfaz gráfica. 4.4. Notas para futuras extensiones En esta sección, se detallan los pasos a seguir para llevar a cabo las futuras extensiones del sistema previstas en la sección C.3.2. 4.4.1. Inclusión de una nueva variable de monitorización Para incluir una nueva variable se deben realizar los siguientes cambios: En base de datos: añadir los valores necesarios en el campo enum VARIABLE de la tabla SIMPLE CONDITIONS. En el módulo gwt: añadir los valores necesarios en la clase enum Variable. En el motor de alarmas: • Añ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. • Añadir una instancia ’Singleton’ en la lista de AbstractFactsFetcher manejada por el motor de inferencia Drools. 4.4.2. Inclusión de un nuevo tipo de acción Para incluir un nuevo tipo de acción se deben realizar los siguientes cambios: En base de datos: • Añadir un registro en la tabla TYPES OF ACTION. • Añadir en la tabla ACTION SPECIFIC PRIVILEGES los permisos asociados al nuevo tipo de acción. En el módulo gwt: añ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 patrón Singleton en la clase TriggerEngine. 4.4.3. Inclusión de un nuevo observatorio Para incluir un nuevo observatorio se deben realizar los siguientes cambios: En base de datos: • Añadir un registro en la tabla TBL ASTRO OBSERVATORIES. • Añadir en la tabla WORKING HOURS los horarios de apertura del nuevo observatorio. En el módulo gwt: añ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 sección 6.3. En el módulo gwt: añadir en la clase ServicesAdminAlarmsModuleImpl la configuració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 sección dedicada a las operaciones accesibles a los administradores. 5.1. Manual de Usuario Para utilizar cualquier funció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 creó 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 pestaña ’Nueva Alarma’. La definición de una alarma consta de tres etapas, una de configuración global de la alarma, otra de definición de las condiciones de activación de la alarma y por fin la definición de las acciones que el sistema tiene que realizar cuando se den las condiciones de ejecución de la alarma. 5.1.1.1. Configuración global El usuario tiene que definir los campos siguientes: Descripción: Es una descripción textual de la alarma. Tiene solo un valor indicativo, aún ası́ se recomienda elegir una descripción adecuada para poder encontrarla fácilmente una vez definida. Periodo de inhibició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 después de la ejecución de la alarma para que se ejecute otra vez (si las condiciones se siguen cumpliendo, se inhibirá la alarma). Número mı́nimo de activaciones / Intervalo de tiempo: Estos dos parámetros solo tienen sentido en conjunto. Se tiene que entender como el número mı́nimo de activaciones de la alarma en los últimos x minutos e.g. (3 ocurrencias mı́nimas durante 20 minutos) antes de la ejecución de las acciones. Siguiendo el ejemplo de configuración propuesto antes (3 activaciones mı́nimas durante 20 minutos), si la alarma se activa a las 14:00, 14:05, 14:20, se ejecutará la acción en el minuto 20. En cambio si la alarma se activa a las 14:00, 14:15, 14:25, 14:30, se ejecutará la acción en el minuto 30. Pública: Si la alarma es pública, los demás usuarios podrán suscribirse a la alarma. Por defecto, la alarma es pública, pero el usuario puede hacerla privada, si ası́ lo desea. Observatorio: se trata del observatorio de referencia, i.e. al cual aplicará la alarma. 5.1.1.2. Condiciones de activación Para crear una alarma, el usuario tiene que definir las condiciones de activación de dicha alarma. Para eso, el usuario puede definir condiciones lógicas sobre el valor de una variable conocida por el sistema e.g. velocidad del viento, humedad, . . . Puede combinar varias condiciones con operadores lógicos AND, NOT, y OR. La combinación de condiciones lógicas tiene una estructura de árbol, por la cual puede navegar, abriendo y cerrando ramas en la interfaz gráfica. Para añadir condiciones, tiene que utilizar los menús señalados por ’Añadir una condición’ en la rama donde quiere añadirla. Para quitar una condición, hace falta pulsar el botón ’Suprimir’ en el nivel de la rama que se quiere suprimir. El número de condiciones que el usuario puede definir en una determinada alarma es limitado. Cuando alcanza este lı́mite, se deshabilitan automáticamente los menús que permiten añadir condiciones. Vuelven a ser activos si se quita una condición. 5.1.1.3. Acciones Por fin, el usuario tiene que configurar las acciones que se realizarán cuando se ejecute la alarma. Esto implica que no estemos dentro del periodo de inhibición de la alarma y que las condiciones de activación se hayan cumplido al menos el número mı́nimo de veces especificado (dentro del intervalo de tiempo definido). Si la alarma está desactivada, bien sea por el usuario, o por un administrador, no se ejecutarán la acciones. Para configurar una acción, el usuario puede elegir el tipo de acción que desea, dentro de la lista de acciones accesibles (correo electrónico, SMS, popup, . . . ). Esta lista puede variar según los permisos otorgados por el administrador. Para cada acción, el usuario puede configurar algunos elementos textuales en el panel ’Texto configurable’, como el asunto y el cuerpo de un correo electrónico o el mensaje de un SMS. 70 Si el usuario elige la opción correo electrónico, cuando se ejecute la alarma el sistema mandará un correo electrónico a la dirección de correo configurada en su cuenta. Si el usuario elige la opción SMS, cuando se ejecute la alarma el sistema mandará un SMS al número de móvil configurado en su cuenta. Si el usuario elige la opción popup, cuando se ejecute la alarma el sistema abrirá un popup en el portal si el usuario está conectado en este momento. (Si no está conectado en este momento, la alarma se perderá). Puede añadir una acción pulsando el icono . De la misma manera, puede quitar . El número de acciones que el usuario puede definir en una acción pulsando el icono una determinada alarma es limitado. Cuando alcanza este lı́mite, desaparecen automáticamente los iconos que permiten añadir acciones. Vuelven a aparecer si se quita una acción. Más detalles acerca de los lı́mites de utilización de la aplicación se pueden encontrar en la sección 5.2.4. 5.1.1.4. Confirmación Cuando está bien configurada, se puede crear la alarma, pulsando el botón ’Crear’. El sistema notificará al usuario del éxito de la operación o, en caso de problema, le proporcionará un mensaje explicativo. Cabe destacar que el sistema necesita cierto tiempo antes de poder tener en cuenta la alarma. La alarma está entonces en el estado ’Pendiente de activación’ hasta que el sistema la incluya efectivamente. Cuando ocurra, el estado de la alarma pasará a ser ’Operativa’. Se incluye en la figura 5.1 una captura de pantalla del panel de creación de una alarma, incluyendo el mensaje de confirmación del sistema. El número de alarmas que el usuario puede definir es limitado. Cuando alcanza este lı́mite, se deshabilita automáticamente el panel de creación de alarmas. Vuelve a ser activo si se suprime una alarma. Más detalles acerca de los lı́mites de utilización de la aplicación se pueden encontrar en la sección 5.2.4. 5.1.2. Editar una alarma El usuario puede acceder a las alarmas que ha definido previamente abriendo la pestañ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 ningún problema. ’Inactiva’ significa que la alarma no se ejecutará. Este estado general se puede leer en la columna ’¿Activa?’ de la manera siguiente: si la alarma está activa se ve ası́: ası́: , y sino . Además de este estado general, que indica el estado de la alarma a grandes rasgos, cada alarma tiene en cada momento un estado más especı́fico, que informa de manera más precisa del estado real de la alarma. Estos estados son: 71 Figura 5.1: Crear una nueva alarma Operativa: La alarma está funcionando de manera correcta. Las acciones se ejecutan cuando se den las condiciones especificadas. Pendiente de activació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 periódicamente esta lista. Después de la actualizació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 está en este estado, la alarma se puede ejecutar en base a su antigua configuración. Desactivada por el usuario: La alarma ha sido desactivada por el usuario. Puede ser reactivada por el usuario bajo ciertas condiciones, explicadas a continuación. Desactivada por el administrador: En cualquier momento, un administrador puede tomar la decisión de desactivar una alarma. Solo un administrador puede reactivar la alarma. Pendiente de revisión: Una alarma en estado ’Desactivada por el administrador’ pasa a ’Pendiente de revisió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 paré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 pasará 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 número máximo de alarmas activas. En efecto, el número de alarmas activas de manera simultá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 automáticamente las ’checkbox’ correspondientes. Vuelven a ser activas si se desactivan más alarmas. Más detalles acerca de los lı́mites de utilización de la aplicación se pueden encontrar en la secció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 carácter público de la alarma marcando o desmarcando la ’checkbox’ correspondiente. El usuario puede suprimir una alarma pulsando el botón ’Suprimir’ correspondiente. El sistema le pedirá confirmación antes de seguir, en particular cuando la alarma tiene suscriptores. En este caso, si el usuario desea seguir con la supresión de la alarma, el sistema mandará automáticamente un correo electrónico a los suscriptores para avisarlos. Todos los cambios realizados en este panel, salvo la supresión de alarmas, se tienen que confirmar pulsando el botón ’Guardar’. Puede anular los cambios (salvo las alarmas suprimidas) pulsando el botón ’Cancelar’. Se incluye en la figura 5.2 una captura de pantalla del panel de gestión de las alarmas. 73 Figura 5.3: Editar una alarma Para editar una alarma más en detalle, tiene que pulsar el botón editar correspondiente. En el panel que aparece, puede editar toda la configuración de la alarma. La interfaz es muy parecida a la de creación de una alarma. La gran diferencia respecto a ésta consiste en la presencia de un botón ’Guardar’ en vez de ’Crear’ y otro botón ’Cancelar’ que permite volver al panel de gestión general de las alarmas. Hace falta confirmar los cambios pulsando el botón ’Guardar’. Si se quiere desechar los cambios, es suficiente pulsar el botón ’Cancelar’. Se incluye en la figura 5.3 una captura de pantalla del panel de edició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 está entonces en el estado ’Pendiente de cambio’ hasta que el sistema la incluya efectivamente. Cuando ocurra, el estado de la alarma pasará a ser ’Operativa’ otra vez. 5.1.3. Suscribirse a una alarma Además de poder definir y editar sus propias alarmas, tal y como se ha detallado previamente, el usuario tiene tambié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 suscripción. Para suscribirse a una alarma definida por otro usuario, el usuario tiene que abrir la pestañ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 públicas del sistema, especificando uno o varios de los criterios de búsqueda siguientes: usuario creador de la alarma, rol del usuario creador, variables monitorizadas, observatorio monitorizado, descripción de la alarma, periodo de inhibición, número máximo de activaciones durante intervalo de tiempo fijo antes de ejecución. Puede ordenar los resultados por fecha de creación y por fecha de última ejecución, pulsando el botón correspondiente. Se actualiza la lista de resultados dinámicamente (i.e. en cuanto el valor de un filtro es cambiado), aún ası́ el usuario dispone de un botón ’Buscar’ para forzar un refresco ası́ como de un botón ’Quitar Filtros’ para eliminar todos los filtros especificados. En caso de haber un número importante de resultados, se muestran los resultados en varias pá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 botón ’Suscribir’, lo cual le llevará a otro panel donde pueda especificar las acciones que quiere asociar a ella. El usuario puede configurar las acciones que quiere asociar a su suscripción del mismo modo que cuando define su propia alarma. Los pasos a seguir son similares a los descritos en la sección 5.1.1.3. Cuando está bien configurada, puede confirmar la suscripción pulsando el botón ’Suscribir’. En cualquier momento, puede pulsar el botón ’Cancelar’ en cuyo caso no se guardará la suscripción. Se incluye en la figura 5.4 una captura de pantalla del panel de creación de una suscripción, incluyendo el mensaje de confirmación del sistema. 5.1.4. Editar una suscripción El usuario puede acceder a las suscripciones que ha definido previamente abriendo la pestañ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 suscripción tiene un estado general que puede ser ’Activa’ o ’Inactiva’ y un estado más especı́fico. Estos estados son: ’Operativa’, ’Desactivada por 75 Figura 5.4: Crear una nueva suscripción el usuario’, ’Desactivada por el administrador’, y ’Pendiente de revisión’. Estos estados tienen el mismo sentido que para una alarma. El usuario puede suprimir una suscripción pulsando el botón ’Suprimir’ correspondiente. El sistema le pedirá confirmación antes de seguir. Los cambios realizados en este panel, salvo la supresión de suscripciones, se tienen que confirmar pulsando el botón ’Guardar’. Puede anular los cambios (salvo las suscripciones suprimidas) pulsando el botón ’Cancelar’. Se incluye en la figura 5.5 una captura de pantalla del panel de gestión de las suscripciones. Para editar una suscripción más en detalle, tiene que pulsar el botón ’Editar’ correspondiente. En el panel que aparece, puede editar toda la configuración de la suscripción. La interfaz es muy parecida a la de creación de una suscripción. La gran diferencia respecto a ésta consiste en la presencia de un botón ’Guardar’ en vez de ’Suscribir’ y otro botón ’Cancelar’ que permite volver al panel de gestión general de las suscripciones. Hace falta confirmar los cambios pulsando el botón ’Guardar’. Si se quiere desechar los cambios, es suficiente pulsar el botón ’Cancelar’. Se incluye en la figura 5.6 una captura de pantalla del panel de edición de una suscripción. 76 Figura 5.5: Gestionar sus suscripciones Figura 5.6: Editar una suscripción 77 5.2. Manual de Administrador Un administrador es un superusuario. Por eso, tiene acceso a todas las funcionalidades descritas en la sección 5.1. En algunos casos, dicha funcionalidad es más amplia para un administrador. Además de poder usar estas funcionalidades, tiene también la posibilidad de administrar las alarmas y suscripciones de cualquier usuario, definir los permisos de los mismos y administrar el sistema. En la sección 5.2.1, se detallan las extensiones de las funcionalidades descritas en la secció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 administración de alarmas y suscripciones definidas por cualquier usuario. La sección 5.2.4 está dedicada a la gestión de permisos de usuario. Por fin, la sección 5.2.5 describe las funciones de administración del sistema. 5.2.1. Extensiones de las funcionalidades de usuario Tal y como se explicó previamente, el administrador tiene acceso a todas las funcionalidades descritas en la sección 5.1. Puede definir alarmas, editarlas, o suscribirse a alarmas definidas por otros usuarios. Pero puede definir acciones de manera más amplia que un usuario. En concreto, puede escoger a los destinatarios de una alarma, i.e. tiene la posibilidad de hacer llegar una notificació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 electrónico y SMS únicamente) a personas no dadas de alta (proporcionando respectivamente la dirección de correo y el número de móvil de la persona correspondiente). Para eso, tiene que seleccionar la opción correspondiente en la lista de tipo ’radio’. La primera opción es ’usuario del sistema’. Para escoger el usuario destinatario, tiene que seleccionarlo en la lista. Por defecto, el usuario seleccionado será el propio administrador. La segunda opción es ’todos los usuarios de un perfil’. Para escoger el perfil, tiene que seleccionarlo en la lista. La última opción es ’usuario anónimo’, sólo es disponible para acciones de tipo correo electrónico o SMS. En este caso el administrador tiene que escribir los datos de contacto de la persona, i.e. respectivamente la dirección de correo o el número de móvil. Puede incluir los contactos de varias personas, separados por un ; Puede añ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 edición de una alarma, en el caso de un administrador. 5.2.2. Administrar las alarmas de otros usuarios El panel de administración de alarmas es accesible abriendo la pestaña ’Admin. Alarmas’. En este panel, el administrador puede editar, desactivar e incluso suprimir las alarmas de cualquier usuario. 78 Figura 5.7: Edición de una alarma - administrador Para llevar a cabo su labor de administración de una manera eficaz, puede buscar dentro de las alarmas del sistema, especificando uno o varios de los criterios de búsqueda siguientes: usuario creador de la alarma, rol del usuario creador, variables monitorizadas, tipos de acciones definidas, estado de la alarma observatorio monitorizado, carácter público o privado de la alarma, descripción de la alarma, periodo de inhibición, número máximo de activaciones durante intervalo de tiempo fijo antes de ejecución. Puede ordenar los resultados por fecha de creación y por fecha de última ejecución, pulsando el botón correspondiente. Se actualiza la lista de resultados dinámicamente (i.e. en cuanto el valor de un filtro es cambiado), aún ası́ el administrador dispone de un botón ’Buscar’ para forzar un refresco ası́ como de un botón ’Quitar Filtros’ para eliminar todos los filtros especificados. En caso de haber un número importante de resultados, se muestran los resultados en varias páginas. En este panel puede en concreto, suprimir alarmas (en este caso, el sistema pide confirmació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 botón ’Guardar’. Cabe destacar que, una vez guardados los cambios, una desactivación de alarma tiene un efecto inmediato en el sistema. Si quiere editar en detalle una alarma, el administrador puede pulsar el botó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 botón ’Guardar’. Se incluye en la figura 5.8 una captura de pantalla del panel de administració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 administración de suscripciones es accesible abriendo la pestañ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 administración de una manera eficaz, puede buscar dentro de las suscripciones del sistema, especificando uno o varios de los criterios de búsqueda siguientes: usuario creador de la alarma, rol del usuario creador, tipos de acciones definidas, estado de la suscripción. Puede ordenar los resultados por fecha de creación y por fecha de última ejecución, pulsando el botón correspondiente. Se actualiza la lista de resultados dinámicamente (i.e. en cuanto el valor de un filtro es cambiado), aún ası́ el administrador dispone de un botón ’Buscar’ para forzar un refresco ası́ como de un botón ’Quitar Filtros’ para eliminar todos los filtros especificados. En caso de haber un número importante de resultados, se muestran los resultados en varias páginas. En este panel puede en concreto, suprimir suscripciones o cambiar el estado de una suscripción. Puede, por ejemplo, desactivar una suscripción seleccionando en la lista desplegable el valor ’Desactivada por el administrador’ o reactivar una suscripción seleccionando en la lista el valor ’Operativa’. Todos los cambios de estado se tienen que confirmar pulsando el botón ’Guardar’. Cabe destacar que, una vez guardados los cambios, una desactivación de suscripción tiene un efecto inmediato en el sistema. Si quiere editar en detalle una suscripción, el administrador puede pulsar el botón ’Editar’. En el panel siguiente, puede editar todos los campos de la suscripción como si fuera la suya. Los cambios se tienen que confirmar pulsando el botó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 pestañ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 restricción siguientes: El número máximo de alarmas que un usuario del perfil seleccionado puede definir. El número máximo de alarmas que un usuario del perfil seleccionado puede activar al mismo tiempo. El número máximo de condiciones lógicas que un usuario del perfil seleccionado puede utilizar en la definición de una alarma. El número máximo de acciones que un usuario del perfil seleccionado puede configurar para cada alarma. El número máximo de suscriptores que puede tener una alarma definida por un usuario del perfil seleccionado. El número máximo de alarmas a las que un usuario del perfil seleccionado se puede suscribir. Para cada tipo de acción existente: • La posibilidad o no que tiene el usuario del perfil seleccionado para utilizar dicho tipo de acción. • El número máximo de alarmas/suscripciones utilizando dicho tipo de acción que un usuario del perfil seccionado puede definir. Para activar o desactivar un tipo de acción dado, hace falta marcar o desmarcar el botón tipo ’checkbox’ correspondiente. Los cambios se tienen que confirmar pulsando el botón ’Guardar’ situado bajo esta sección. Antes de hacer efectivo el cambio, el sistema propone al administrador enviar un correo electró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 electrónico auto-rellenado, pero que puede modificar como lo desea. El popup tiene un botón ’Enviar’ y otro ’Cancelar’. Pulsando ’Cancelar’, se cancela la operación i.e. no se guardan los cambios ni se mandan los correos electrónicos. Pulsando ’Enviar’, el sistema procede con la actualización de los cambios y a continuación envı́a el correo electró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 restricció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 según el perfil seleccionado en la otra lista i.e. solo contiene los usuarios del perfil seleccionado). Para añadir una excepción, tiene que pulsar el botón ’añadir excepción’, lo cual hace aparecer un campo donde especificar el valor que prevaldrá sobre el valor definido a nivel de perfil. Por razones de seguridad, este valor debe de ser más restrictivo que el valor definido a nivel de perfil. Los cambios se tienen que confirmar pulsando el botón ’Guardar’ situado bajo esta sección. Como en el caso del cambio de permisos a nivel de perfil, el administrador tiene la posibilidad de mandar un correo electrónico al usuario afectado. La tercera parte del panel (a la derecha) muestra la configuración de permisos resultante para el perfil y el usuario seleccionados. Permite tener una confirmación visual de las modificaciones aportadas a ambos. Su contenido se actualiza automáticamente segú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 gestión de los permisos, incluyendo el popup utilizado para mandar el correo electró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 número de alarmas que pueda definir un usuario de este perfil de 5 a 3). La solución escogida para solucionar este tipo de conflicto es la siguiente: en 82 caso de conflicto, el sistema deberá tomar las acciones necesarias para que se cumplan las nuevas polı́ticas de restricción. Dichas acciones podrán incluir desactivar o suprimir las alarmas de más baja prioridad hasta cumplir las nuevas reglas de restricción. 5.2.5. Administrar el sistema Para utilizar las funciones de administración del sistema, el administrador tiene que entrar en el panel correspondiente, abriendo la pestaña ’Administración Global’. Dichas funciones se pueden desglosar en dos categorı́as: monitorización del funcionamiento del sistema y configuración de horarios de funcionamiento del mismo. 5.2.5.1. Monitorización del sistema En este apartado se llamará ’motor de alarmas’ al componente del sistema dedicado a la monitorización de variables y ejecución de alarmas. Cabe destacar que dicho componente es totalmente independiente del portal Ciclope Astro. Aún ası́ existen canales de comunicación entre ambos componentes software para permitir una monitorizació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 está invitado a consultar las secciones 4.3.1 y 6. En el panel de administració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 está funcionando de manera correcta. Parado: el motor está parado i.e. no se ejecuta ninguna alarma. No disponible: no es posible establecer una comunicación remota con el motor. Arrancando: el motor está en proceso de inicialización. Parando: el motor está ejecutando una parada controlada. El estado del motor está actualizado periódicamente. En cualquier momento, el administrador puede forzar dicha actualización pulsando el botón ’Refrescar Estado’. El administrador puede actuar remotamente sobre el motor de las formas siguientes: si está parado, lo puede iniciar, pulsando el botón ’Arrancar Motor’, si está 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), tambié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 periódicamente las reglas para tener en cuenta las modificaciones de las alarmas definidas o la inserción de nuevas alarmas. Aún ası́, el administrador puede solicitar una actualización de las reglas pulsando el botó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. Configuración de horarios de funcionamiento del motor de alarmas El administrador tiene tambié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 inhibirán si la ejecución de la alarma ocurre durante uno de los dı́as festivos definidos o fuera de las horas de funcionamiento. Aún ası́, las alarmas definidas por administradores no se verán afectadas por la configuración de horas de funcionamiento o dı́as festivos, i.e. se ejecutarán siempre y cuando el motor de alarmas correspondiente esté 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. Ademá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 opción correspondiente en la lista. Para especificar horas de apertura y cierre, hace falta escoger la opción ’Tiempo parcial’ en la lista. Una vez la opció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 botó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 añ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 botón ’Guardar’. Se incluye en la figura 5.10 una captura de pantalla del panel de administración del sistema. 84 Figura 5.10: Administrar el sistema 85 86 Capı́tulo 6 Manual de Instalació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 módem GSM. Aunque el sistema podrı́a funcionar con un móvil estándar siempre y cuando éste ofrezca algún tipo de conexión a un ordenador (bluetooth, usb, infrarrojo), se recomienda el uso de un módem GSM dedicado, por razones de fiabilidad. El lector interesado puede consultar el anexo B para más detalles. El módem GSM es el único componente hardware especı́fico necesario en la instalación del sistema Ciclope Alarms. En la sección 6.1, se describe la instalación y configuración del módem GSM y de las librerı́as necesarias para comunicar con él. En la secció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 sección 6.3, se detallan los pasos a seguir para instalar y configurar el componente motor de alarmas del sistema. Por fin, en la sección 6.4, se describe la instalación y configuración de la interfaz gráfica (GUI) del sistema. 6.1. Instalación del módem GSM En el ámbito de este proyecto, se utilizó un módem Siemens TC35i [17]. Aún ası́, el sistema está diseñado para poder funcionar con cualquier tipo de módem GSM y las etapas para instalarlo y configurarlo deberı́an de ser muy parecidas a las expuestas a continuación. En caso de duda, el lector está invitado a consultar la documentación especı́fica del módem utilizado [62, 61]. 87 6.1.1. Cableado y puesta en funcionamiento El cableado exacto del módem depende fuertemente del modelo. Pero cualquier modelo dispone de un compartimento permitiendo albergar una tarjeta SIM. Es recomendable insertar ésta en el compartimento adecuado antes de alimentar el módem. Un módem GSM (o un móvil) se puede conectar a un ordenador de varias formas, según el modelo: conexión serie, usb, o hasta bluetooth o infrarrojos (para móviles). En el caso de una conexión serie o usb, es necesario conectar el cable correspondiente entre el módem y el ordenador. En el caso de que el mó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 esté conectado, y la tarjeta SIM correctamente colocada, se puede encender el módem y proceder a las primeras pruebas. 6.1.2. Primeras Pruebas Para hacer las primeras pruebas con el módem, se recomienda el uso del software minicom 1 , aunque cualquier otro método para comunicarse a un dispositivo serie (o usb) vale. La comunicación a bajo nivel con un módem GSM se hace mediante comandos AT. Los comandos AT, a veces denominados comandos Hayes (por la marca del primer modelo que le llegó a utilizar) es un está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 documentación del mó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 módem devuelve información del constructor y del modelo del módem. Si el comando no funciona o devuelve un error, se recomienda comprobar el cableado y referirse a la documentación especı́fica del módem. La segunda prueba serı́a mandar el comando AT+CMEE=2, que permite configurar el módem en modo verbose. Si no se configura de tal manera, cualquier error aparecerá como ’Error’, sin más detalles, lo que complica la resolución de cualquier problema. Para comprobar que el mó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 mó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 código. Cuidado, como con un móvil normal, solo se dispone de tres intentos antes de bloquear la tarjeta SIM. En este caso, se debe utilizar el código PUK (Personal Unblocking Key) de ocho dı́gitos, con el mando AT+CPIN=PUK1,new PIN1, para asignar newPIN1 como nuevo código PIN. Una vez introducido correctamente el PIN de la tarjeta, el módem deberı́a de conectarse automáticamente a la red del operador contratado (u otro operador en caso de 1 Página oficial del proyecto minicom: http://alioth.debian.org/projects/minicom/.. minicom está disponible en los repositorios Debian/Ubuntu. 88 roaming). Para comprobar si está o no asociado a una red, hace falta utilizar el comando AT+COPS?, que devuelve el estado de la conexión, y el operador de telecomunicaciones al cual está conectado el módem. Llegado a este punto, el módem deberı́a de estar listo para mandar su primer SMS. Hace falta mandar el comando AT+CMGF=1 para configurar el módem en modo texto. Después, hace falta mandar el comando AT+CMGS=*****, sustituyendo las estrellas por el número al cual se quiere mandar el mensaje. A continuació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 documentación especı́fica del módem utilizado hasta ser capaz de pasar la primera prueba i.e. mandar un mensaje SMS con el módem. 6.1.3. Instalación de las librerı́as java El motor de alarmas utiliza la librerı́a SMSLib [19] para poder mandar SMS. La página oficial del proyecto SMSLib se puede encontrar en la URL: http://code.google.com/p/ smslib/. El código está distribuido bajo los té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 versión binaria (smslib-v3.4.1-bin.zip) o las fuentes (smslib-v3.4.1-bin.zip) y compilarlas. La versión binaria tambié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 implementación comercial de Sun o la implementación libre rxtx. La implementació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 implementación es propietaria i.e. su código fuente no está disponible. Su utilización está sujeta a la licencia ’Binary Code License Agreement’ de Sun Microsystems [63]. Otra solución es utilizar la implementación libre rxtx, disponible en la página: http:// rxtx.qbang.org/wiki/index.php/Main Page. El código de la librerı́a está publicado bajo los términos de la licencia GNU LGPL, versión 2.1 [24]. Está disponible en los repositorios de Debian y Ubuntu. La librerı́a SMSLib también necesita la instalación de la librerı́a slf4j (simple logging facade for Java). Se puede encontrar en la página:http://www.slf4j.org/download.html. El código de la librerı́a está publicado bajo los términos de la licencia SLF4J License [58], copia verbatim de la licencia X11. 6.2. Instalación de la base de datos Tanto el componente motor como la interfaz gráfica de Ciclope Alarms guardan y leen informació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 creació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 sesión mysql con el servidor. Se necesita la contraseñ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 configuración inicial, para poder empezar a utilizar la aplicación. Crea un usuario ’admin’ con contraseña ’admin’. source [directorioDelScript]/CiclopeAlarms_configuration_data_standalone.sql 4. Cerrar la sesió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 sesió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 configuración inicial, para poder empezar a utilizar la aplicación. source [directorioDelScript]/CiclopeAlarms_configuration_data.sql 5. Cerrar la sesión mysql. exit 6.3. Instalació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 comunicación serie (bien sea rxtx bien sea la implementació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. Aún ası́, las librerı́as necesarias están disponibles en la carpeta lib/ de las fuentes, como explicado en la secció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 Versió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 https://cds.sun.com/is-bin/INTERSHOP.enfinity/ WFS/CDS-CDS Developer-Site/en US/-/USD/ 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 Instalació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 instalació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 configuración. 92 /usr/share/ciclope-alarms: Carpeta de instalació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 simbó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 máquina y se para cuando se apaga la máquina. 6.3.3. Configuración Para completar la instalación del motor, solo hace falta configurarlo. Toda la configuración se puede encontrar en la carpeta /etc/ciclope-alarms, en distintos ficheros de configuración. A continuación, se repasan los distintos ficheros de configuración, comentando partes de su contenido, y explicando los valores de las propiedades clave. drools.properties: pará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 configuración de log. SqlMapConfigAlarms.xml: fichero de configuració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 según el procedimiento de instalación detallado en este documento, el motor está instalado como un servicio i.e. arranca y se detiene automáticamente cuando se inicia o se detiene el sistema. 94 6.4. Instalación de la GUI En esta sección se detallan los pasos a seguir para instalar la interfaz gráfica de Ciclope Alarms en el contexto de una instalación en modo standalone, es decir en modo no integrado con Ciclope Astro. El lector interesado en la integración de la interfaz gŕafica con Ciclope Astro está invitado a consultar la sección 4.3.4. 6.4.1. Prerequisitos y librerı́as Antes de poder instalar la versión standalone de la interfaz grá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 está invitado a consultar la documentación especı́fica del contenedor elegido para configurar éste debidamente. Hace falta instalar la herramienta de compilación para Java, ant. apt-get install ant Para funcionar correctamente, la interfaz gráfica necesita un conjunto de librerı́as, que se detalla en la tabla 6.2. Aún ası́, las librerı́as necesarias están disponibles en la carpeta lib/ de las fuentes, como explicado en la sección 6.4.2, por lo cual no es imprescindible instalarlas por separado. Tabla 6.2: Librerı́as necesarias para la interfaz gráfica Librerı́a GWT Ibatis Junit Log4J JavaMail Versió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 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 95 activation 1.1.1 Driver MySQL 3.0.17 6.4.2. https://cds.sun.com/is-bin/INTERSHOP.enfinity/ WFS/CDS-CDS Developer-Site/en US/-/USD/ 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 Instalación Las fuentes de la interfaz grá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 configuración adecuado. gedit src/org/ciclope/db/alarms/SqlMapConfigAlarms.xml A continuación se enseña un ejemplo del fichero de configuración SqlMapConfigAlarms.xml, señ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 configuración adecuado. gedit src/org/ciclope/server/alarms/user/user.properties A continuación se enseña un ejemplo del fichero de configuració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 realizació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 gráfica. 97 98 Capı́tulo 7 Conclusión En este último capı́tulo, se exponen las conclusiones que se han sacado de la realizació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 estación meteorológica, publicando sus datos a través de Internet. Dotar al Observatorio de un gestor de alarmas que permita la monitorización del mismo a partir de los datos proporcionados por la estación. El segundo objetivo tenı́a relación con los objetivos adicionales siguientes: Configuración dinámica de alarmas vı́a el portal web Ciclope Astro. Carácter genérico de la solución: Ciclope Alarms tiene que permitir la monitorización simultánea de varios observatorios. Carácter extensible de la solución: el sistema se podrá ampliar fácilmente para incluir otras fuentes de de variables de monitorización (e.g. sensores) ası́ como otros tipos de acciones a realizar. Uso de software libre. En cuanto a la realización del primer objetivo, se dio de alta y configuró la estación meteorológica de la facultad en los servicios Awekas, CWOP, PWS y Wunderground, documentando los pasos seguidos en el capı́tulo 3. La realización del segundo objetivo fue más larga, necesitó, además del estudio del estado del arte, una fase de toma de requisitos, una fase de diseño, una de implementación y por fin una fase de integración. A nivel de gestión de proyecto, se intentó mantener un ciclo de vida por iteraciones cortas validadas por demos, por lo cual las fases de toma 99 de requisitos, diseño e implementación no fueron secuenciales sino más bien se complementaron una a otra, las demos permitieron a veces identificar problemas en los requisitos o en el diseñ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 genérico y fácilmente extensible se tomaron en cuenta desde la fase de diseño. Se han incluido en la sección 4.4 notas para realizar las extensiones futuras previstas i.e. inclusión de otros observatorios, de nuevos tipos de acciones o de otras fuentes de variables de monitorización. Se utilizó exclusivamente software libre: Drools (licencia Apache), Ibatis, Google Web Toolkit, Commons-Daemon (Apache), . . . , el software desarrollado está publicado bajo la licencia GNU GPL versión 3 [25] y el presente documento bajo la licencia GNU FDL versión 1.3 [26]. 7.2. Futuras Mejoras Como se ha explicado en la secció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 decidió excluir del á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 continuación se detallan algunos de estos requisitos, u otras áreas que podrán ser exploradas en el ámbito de futuros trabajos. 7.2.1. Soporte de lógica borrosa La lógica borrosa está extensivamente utilizada en todas las áreas de control industrial (control de plantas por ejemplo), con bastante éxito. Los conceptos de ló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 Astronómico, con sus sensores y actuadores asociados). Las condiciones de activación de alarmas se podrı́an definir con términos más entendibles como (si viento alto, entonces cerrar cúpula), delegando la tarea de definir los modelos borrosos a usuarios avanzados por ejemplo. La utilización de lógica borrosa se descartó del ámbito de esta entrega bastante rá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 configuración de una alarma utilizando lógica borrosa, se sugiere la posibilidad de tener un modo básico (permitiendo solo lógica booleana) y un modo avanzado con lógica borrosa. 7.2.2. Añadir de nuevos observatorios, tipos de acciones y fuentes de variables de monitorización Estas áreas no son exactamente mejoras al sistema sino extensiones previstas de antemano. Parte de la realizació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 sección 4.4 de este documento. 7.2.3. Mejoras a la parte de edición de alarmas Se podrı́an implementar las siguientes mejoras a la parte de edición de alarmas del sistema, en orden de prioridad decreciente: Permitir la definición de condiciones lógicas sobre la evolución histórica de una variable (meteorológica o no): • Media, min, max durante los ú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) según los casos(e.g. cúpula abierta) durante la creación de alarmas. Los casos exactos se tendrı́an que definir, lo que se podrá hacer probablemente basándose en la experiencia del uso real del sistema. Refinar el modelo Alarma/Suscripción añ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 carácter Público/Privado de una alarma, añ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 reutilización de alarmas ya definidas, impidiendo al usuario que creara una alarma idéntica a una ya definida en el sistema (bien sea por é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 técnicas (hace falta identificar condiciones lógicas equivalentes pero expresadas de formas distintas, problema no trivial y probablemente asociado a un coste computacional no despreciable). Añadir la posibilidad de activar/desactivar las acciones dentro de una alarma o suscripción además de poder activar/desactivar la alarma en su totalidad. 7.2.4. Mejoras a la parte de administración Se podrı́an implementar las siguientes mejoras a la parte administración del sistema, en orden de prioridad decreciente: Añadir la posibilidad de activar/desactivar un tipo de acción (e.g. SMS, correo electrónico) en vez de todo el sistema. 101 Cuando un administrador desactiva o reactiva una alarma, enviar un correo electrónico automáticamente a los usuarios afectados. Añadir la posibilidad de asociar un tipo de acción a los horarios de apertura del observatorio. De esta manera un tipo de acción sólo se realizarı́a dentro del horario definido. Añadir un módulo de gestión de las acciones: el administrador podrı́a crear diná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 definición de excepciones más permisivas en determinados casos pero se tendrı́a que diseñar una interfaz adecuada para que el administrador conserve siempre el control de la situación (en particular identificar rápidamente los casos de excepciones permisivas). Mejorar la usabilidad de la definición de receptores de una acción, convirtiendo las listas de selección de los mismos en listas de elección múltiple. 102 Apé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) (révision 152) +++ http/http.c (.../branches/non-Verbose) (ré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 if (radCfGetFirstEntry (configFileId, 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 if (radCfGetFirstEntry (configFileId, 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) (révision 152) +++ http/http.h (.../branches/non-Verbose) (ré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 Configuring frequency of + 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) (révision 152) +++ wviewconfig/wviewconfig.sh (.../branches/non-Verbose) (ré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 "" >> $WVIEW_CONF_DIR/http.conf echo "# WEATHERFORYOU Station ID:" >> $WVIEW_CONF_DIR/http.conf echo "YOUSTATIONID=$YOUSTATIONID" >> $WVIEW_CONF_DIR/http.conf echo "" >> $WVIEW_CONF_DIR/http.conf @@ -1628,6 +1671,10 @@ echo "YOUPASSWORD=$YOUPASSWORD" >> $WVIEW_CONF_DIR/http.conf echo "" >> $WVIEW_CONF_DIR/http.conf + + + + echo "# WEATHERFORYOU INTERVAL:" >> $WVIEW_CONF_DIR/http.conf echo "YOUINTERVAL=$YOUINTERVAL" >> $WVIEW_CONF_DIR/http.conf echo "" >> $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) (révision 152) +++ common/sysdefs.h (.../branches/non-Verbose) (ré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 Configuring frequency of + 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 propriétés sur . ___________________________________________________________________ Nom : svn:ignore + *.project 111 112 Apéndice B Informe: Soluciones para mandar SMS automáticamente Introducción El objetivo de este informe es estudiar las distintas soluciones disponibles para conseguir, en el ámbito de la monitorización de la estación meteorológica, los siguientes objetivos: Ser capaces de mandar SMS de manera automática (e.g. cuando se dispara una alarma). La solución debe ser 100 % compatible GNU/Linux. Hay básicamente tres maneras de enfocar el problema: 1. Mandar los SMS gracias a un módem GSM. 2. Mandar los SMS gracias a un móvil convencional. 3. Utilizar servicios on-line (SMS Gateways) para mandar los SMS. A continuación, se detallan, para cada tipo de solución, las soluciones concretas ası́ como los costes asociados para ayudar a tomar una decisión de compra. En la sección B.5, se hará un repaso de las distintas soluciones ası́ como las ventajas e inconvenientes de cada una. B.1. Módems GSM Hay tres tipos de módems GSM capaces de mandar SMS: Módem interno - o ’módulo’ (circuitos impresos). Módem externo - o ’terminal’ (conexión serie RS-232). 113 Módem externo (conexión USB). Cabe destacar, que para algunos modelos, es preciso adquirir, en complemento al propio módem, accesorios vendidos por separado tales como una antena GSM, un módulo de lectura de tarjeta SIM, una fuente de alimentación. . . Otros modelos si incluyen éstos (o no lo requieren). El estudio se centró en los modelos siguientes1 , algunos de los cuales está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 módems con conexión serie tienen más probabilidad de ser correctamente reconocidos por el kernel Linux. Los módems USB pueden dar más problemas, aún ası́ las versiones más recientes del kernel pueden llegar a reconocerlos. Tabla B.1: Compatibilidad GNU/Linux de los modelos de mó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 centró en modelos con mayor presencia en la web o con mayor número de testimonios de utilización en Linux. 2 Siemens Wireless pasó a ser una empresa independiente llamada Cinterion. Aú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 instalació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 mó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 España: Matrix Electrónica. Xacom. Anatronic. Wavecom tiene un único distribuidor en España [68]: Diode. Huawei por lo visto no tiene distribuidor oficial. Aún ası́, el modelo Huawei E220 es fácil de encontrar (se trata del estándar de facto actual de los módems 3G y existe tanto en versión liberada como sujetada a un contrato con Vodafone, Movistar, Orange, . . . ). A continuación, se presenta un resumen de los precios de cada modelo según las tiendas. En caso de haber dos precios, el precio más bajo corresponde al módem sin accesorios, el precio más alto al módem más los accesorios (fuente de alimentación, antena y cable de datos serie). Tabla B.2: Precios de distintos modelos de mó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 razón desconocida mantienen secretos sus precios y sólo los comunican por correo electrónico después de haber contactado por telé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 Móvil convencional Utilizar un móvil convencional en vez de un módem GSM dedicado puede ser una solución más barata. Sin embargo, conviene destacar los inconvenientes de tal elección: Fiabilidad más baja. Problemas con baterı́a. Problemas con cargador (algunos cortan la comunicación). Problemas varios debidos a la complejidad del sw embedido. Posibilidad de parada no ordenada del móvil (necesidad de un reboot manual). Menos velocidad para mandar SMS pudiendo ocasionar retrasos. Muchos modelos de móvil pueden, al menos teóricamente, servir para mandar SMS desde un ordenador (mediante conexión USB, Bluetooth, u otra). Ozenkisms recomienda los siguientes modelos:[56] Tabla B.3: Modelos de mó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 página http: //cihar.com/gammu/phonedb/[75], se reducen las opciones a la tabla siguiente. Tabla B.4: Mó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 (véase enlaces presentados a continuación) y el éxito del proyecto gnokii[28]. Para temas de configuració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 móvil puede ser una opción menos costosa que un módem GSM profesional. Sin embargo, dado que el móvil necesita permitir algún tipo de conexió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 más interesantes encontradas en Internet incluyen7 : 7 El lector atento se habrá percatado de que los móviles no están en la lista presentada antes. No están recomendados por ozekisms[56] pero está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 clásicas Tanto para la solución involucrando un módem GSM como para su variante con un móvil convencional, hace falta contratar los servicios de una operadora telefónica para mandar SMS. En el caso de los módems, un compartimento dedicado suele permitir la inserción de una tarjeta SIM. A continuación se presenta algunas de las ofertas actuales dignas de interés dados nuestros objetivos. Dicho estudio fue elaborado en parte gracias a la pá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 números favoritos (hasta 5),15 c/SMS IVA inc. para otros destinos nacionales, sin cuota. Opción ahorro Nacional : club SMS: 2 euros/mes, 50 % descuento hacia Movistar. Opción Mi favorito: alta 7 euros, sin cuota, 7 c/SMS IVA inc. B.3.2. Vodafone Tá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 solución para mandar SMS consiste en contratar servicios a empresas especializadas, delegándoles la tarea de enviar los SMS. Dicha solución tiene la ventaja de no necesitar ningún tipo de hardware adicional. Sin embargo, se pierde en flexibilidad y sobretodo, en caso de escoger esta solución, se creará una dependencia futura con la empresa escogida. También existen servicios en Internet totalmente gratuitos para mandar SMS (pero con limitaciones) y hasta software que automatiza el envı́o hacia éstos, pero proporciona muy poca fiabilidad por lo que se descartó esta solución. A continuación se presenta algunas de las ofertas comerciales serias para mandar SMS a travé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 más caro 11c/SMS, API SMPP/HTTP. http://www.clickatell.com/pricing/message cost.php, APIs diversas 9c/SMS. 120 B.5. Conclusión Las ventajas e inconvenientes de cada tipo de solución se pueden resumir en la tabla B.5. Tabla B.5: Ventajas e inconvenientes de cada tipo de solución SMS Solución Módem GSM Ventajas Gran fiabilidad Independencia Móvil Convencional Más barato que un mó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 económicas y tecnológicas, clasificarı́a las soluciones propuestas en el orden de preferencia siguiente: 1. Módem GSM - Más fiable, má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. Móvil convencional. 3. SMS Gateway. 8 No imprescindible, nos podemos conformar con los comandos AT. 121 122 Apéndice C ERS Ciclope Alarms C.1. Introducción Este documento es una Especificación de Requisitos Software (ERS) para el Sistema Ciclope Alarms. Esta especificación se ha estructurado basándose en las directrices dadas por el estándar IEEE 830, 1998 [35]. C.1.1. Propósito El objeto de la especificación es definir de manera clara y precisa todas las funcionalidades y restricciones del sistema Ciclope Alarms. C.1.2. Ámbito del Sistema El sistema Ciclope Alarms tiene como propósito permitir la monitorización del Observatorio Astronómico de Montegancedo a través de un gestor de alarmas altamente configurable. Los usuarios debidamente habilitados podrán definir alarmas, cuyas condiciones de activación involucrarán las variables accesibles en lectura al sistema. En el ámbito de esta entrega, se tratará de las variables meteorológicas colectadas por la estación meteorológica[14]. A más largo plazo, se prevé incluir otras variables tales como sensores fı́sicos asociados a la cúpula del observatorio. El sistema será capaz de llevar a cabo determinadas acciones tales como mandar un correo electrónico o un mensaje SMS. La GUI del sistema se tendrá que integrar en el portal web Ciclope Astro[12]. Aunque tenga que ser lo suficientemente genérico como para permitir la monitorización de varios observatorios astronómicos a la vez, en el ámbito de esta entrega, el sistema se integrará en el Observatorio Astronómico de Montegancedo. C.1.3. Definiciones, Acró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. Activación de alarma: Salvo mención explı́cita de lo contrario, por activación de una alarma, se referirá al momento cuando se cumplen las condiciones lógicas definidas para la alarma. Ejecución de alarma: Salvo mención explı́cita de lo contrario, por ejecución de una alarma, se referirá al momento cuando se ejecutan las acciones definidas para la alarma. Una ejecución necesita una activación previa pero la activación de una alarma no implica necesariamente su ejecución. C.1.3.2. Acrónimos ERS: Especificación de Requisitos Software (SRS en inglé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 Estándar IEEE 830[35] C.1.5. Visión general del Documento Este documento consta de tres secciones. La sección C.1 es la Introducción y proporciona una visión general de la ERS. En la sección C.2 se da una descripción general del sistema, con el fin de conectar las principales funciones que deberá realizar, los datos asociados y los factores, restricciones, supuestos y dependencias que afectan al desarrollo, sin entrar en excesivos detalles. En la sección C.3 se definen detalladamente los requisitos que deberá satisfacer el sistema. 124 C.2. Descripción General C.2.1. Perspectiva del producto El sistema Ciclope Alarms, en su primera versión, permitirá la edición de alarmas basadas en condiciones lógicas involucrando variables meteorológicas. Cuando se den las condiciones de activación de una alarma el sistema ejecutará la (o las) accione(s) asociada(s) dentro de los tres siguientes tipos: mandar un correo electrónico, mandar un mensaje SMS, o avisar a un usuario conectado al portal Ciclope Astro mediante la aparición de un popup en su navegador web (o pop-up). En siguientes versiones, se prevé la inclusión de otros tipos de variables (e.g. sensor de apertura de la cúpula) ası́ como de nuevas acciones (e.g. abrir/cerrar la cúpula) por lo que el diseño original deberá ser lo suficientemente genérico. Otra evolución probable es la inclusión de otros observatorios. Las GUI necesarias a la edición de alarmas ası́ como a la administración del sistema serán integradas al portal web Ciclope Astro. C.2.2. Funciones del sistema Las funciones del sistema se pueden clasificar según dos categorı́as: 1. Edición de alarmas. 2. Administración del sistema. C.2.2.1. Edición de alarmas El sistema deberá permitir al usuario crear, editar, o suprimir alarmas. Según el perfil del usuario, éste tendrá acceso a ciertas partes de la funcionalidad y verá su uso restringido según la configuración establecida por el administrador. El sistema deberá también permitir al usuario suscribirse a alarmas definidas por otros usuarios. Los requisitos completos relativos a esta parte se podrán encontrar en la sección C.3.1.1. C.2.2.2. Administración de Ciclope Alarms Las funciones de administración que tendrá que implementar el sistema se podrán agrupar según las tres siguientes categorı́as: Gestión de permisos de los usuarios. Control de las alarmas definidas por los usuarios. Configuración global del sistema. Los requisitos completos relativos a esta parte se podrán encontrar en la sección C.3.1.2 125 C.2.3. Caracterı́sticas de los Usuarios El modelo de usuarios será idéntico al modelo previamente utilizado en Ciclope Astro. Sólo los usuarios de perfil admin tendrán acceso a las funciones de administración del sistema. Las demás funciones del sistema (creación, edición de alarmas, . . . ) serán accesibles a todos los perfiles de usuario. Sin embargo, restricciones particulares se aplicarán a cada usuario segú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 será publicado bajo la licencia GNU GPL versión 3[25], y toda su documentació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 tendrá que integrar en él. En particular, se reutilizará en su totalidad el modelo de usuarios de Ciclope Astro. Existen dependencias con todos los sistemas externos con los cuales el sistema se tendrá que comunicar para llevar a cabo sus funciones: wview: para la lectura de datos meteorológicos (mediante flujo RSS). Servidor de correo: para mandar correos electrónicos. Módem GSM: para mandar mensajes SMS. C.3. Requisitos Especı́ficos C.3.1. Requisitos funcionales C.3.1.1. Edición de alarmas C.3.1.1.1. Definición de alarmas C.3.1.1.1.1. Requisito(1) El usuario podrá crear X alarmas, donde X será configurable por el administrador (vé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 tendrá que definir las condiciones de activación de dicha alarma. Para eso, el usuario podrá definir una condición lógica sobre el valor de una variable conocida por el sistema (i.e. que sea capaz de obtener). En concreto, podrá escoger dentro de las variables meteorológicas recolectadas por la estación meteorológica. Dado que se prevé que se pueda en un futuro vigilar el estado de sensores u otras variables ası́ que el diseño deberá ser genérico. Véase requisito C.3.2.1. C.3.1.1.1.3. Requisito(3) El formato de una condición lógica será: [variable][comparador][ref erencia] C.3.1.1.1.4. Requisito(4) Los comparadores admitidos serán: >, ≥, <, ≤, =, 6= C.3.1.1.1.5. OR, NOT. Requisito(5) El usuario podrá utilizar los operadores lógicos: AND, C.3.1.1.1.6. Requisito(6) El valor [referencia] podrá ser binario (true/false) o un valor numérico. C.3.1.1.1.7. Requisito(7) Para definir una alarma, el usuario podrá combinar condiciones lógicas mediante operadores lógicos. El número de condiciones que pueda definir en la misma alarma será limitado (dicho número será configurable por el administrador segú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 podrá anidar condiciones lógicas mediante el uso de paréntesis. C.3.1.1.1.9. Requisito(9) El usuario podrá añadir una descripción textual de la alarma definida. C.3.1.1.1.10. Requisito(10) Todas las alarmas creadas por un usuario serán públicas por defecto. Sin embargo, el usuario tendrá la posibilidad de hacerla privada. C.3.1.1.1.11. Requisito(11) Las alarmas creadas por un administrador serán privadas por defecto. El administrador tendrá la posibilidad de hacerla pública. C.3.1.1.1.12. Requisito(12) Para crear una alarma, el usuario deberá escoger una o varias acciones que el sistema deberá llevar a cabo cuando se cumplan las condiciones de activación de la alarma. 127 C.3.1.1.1.13. Requisito(13) Las acciones disponibles serán: mandar un correo electró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) Según su perfil, un usuario tendrá acceso a un subconjunto determinado de tipos de acciones, configurable por el administrador (vé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 opción correo electrónico, cuando se ejecute la alarma el sistema mandará un correo electrónico a la dirección de correo configurada en su cuenta. C.3.1.1.1.16. Requisito(16) Si el usuario elige la opción SMS, cuando se ejecute la alarma el sistema mandará un SMS al número de móvil configurado en su cuenta. C.3.1.1.1.17. Requisito(17) Si el usuario elige la opción pop-up, cuando se ejecute la alarma el sistema abrirá un pop-up en el portal si el usuario está conectado en ese momento. (Si no está conectado en ese momento, la alarma se perderá1 ). C.3.1.1.1.18. Requisito(18) Un usuario normal no podrá involucrar a otras personas en las acciones que elige (e.g. mandar un correo electrónico a otros usuarios). Para eso, existe el sistema de suscripciones (los usuarios interesados por una alarma podrán suscribirse). C.3.1.1.1.19. Requisito(19) Si el administrador elige la opción correo electrónico, podrá configurar las direcciones de correo a las cuales tiene que llegar la alarma: Direcciones de correo electrónico de usuarios. Direcciones de correo electrónico de todos los usuarios de un perfil. Introducir manualmente una o varias direcciones de correo electrónico. C.3.1.1.1.20. Requisito(20) Si el administrador elige la opción SMS, podrá elegir mandarlo al móvil de un usuario, o introducir manualmente dicho número. Podrá también, segú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 opción pop-up, podrá elegir la opción: a un usuario, a un tipo de perfil de usuarios destinatarios, o a todos los usuarios. 1 En concreto, si el usuario no está conectado, la alarma no le llegará nunca. 128 C.3.1.1.1.22. Requisito(22) Para cualquier aviso textual (correo electrónico, popup o SMS), el usuario podrá configurar el texto enviado (un modelo por defecto será propuesto). C.3.1.1.1.23. Requisito(23) Para limitar la frecuencia de ejecución de la misma alarma y ası́ reducir el ’spam’ generado por sucesivas activaciones, se podrá definir para cada alarma tres parámetros ’Periodo de inhibición de alarmas’, ’Número mı́nimo de activaciones’ y ’Intervalo de tiempo’ antes ejecución: Periodo de inhibición: numero mı́nimos de minutos que tiene que transcurrir entre dos ejecuciones de acción (las condiciones se siguen comprobando, sólo la acción se inhibe). Número mı́nimo de activaciones en Intervalo de tiempo: número mı́nimo de activaciones de la alarma en los últimos x minutos e.g. (3 ocurrencias mı́nimas durante 20 minutos). Siguiendo el ejemplo de configuración propuesto antes (3 activaciones mı́nimas durante 20 minutos), si la alarma se activa a las 14:00, 14:05, 14:20, se ejecutará la acción en el minuto 20. En cambio si la alarma se activa a las 14:00, 14:15, 14:25, 14:30, se ejecutará la acción en el minuto 30. C.3.1.1.2. Suscripciones C.3.1.1.2.1. Requisito(24) El usuario podrá suscribirse a Y alarmas (no suyas), donde Y será configurable por el administrador (vé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 deberá 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 más fácilmente las alarmas que le puede interesar, el usuario podrá buscar dentro de las alarmas públicas definidas por otros usuarios mediante filtros de búsqueda adaptados. En particular, tendrá la posibilidad de: Buscar por: • Usuario dueño de la alarma. • Rol de usuario del dueño de la alarma. • Descripción textual de la alarma. • Variables utilizadas en la condición lógica de la alarma. • Periodo de inhibición de la alarma. • Número mı́nimo de activaciones antes de ejecución. 129 • Intervalo de tiempo asociado al número mı́nimo de activaciones antes de ejecución. Ordenar los resultados por: • Fecha de creación de la alarma. • Fecha de última ejecución de la alarma. C.3.1.1.2.4. Requisito(27) El usuario podrá 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 aplicarán). C.3.1.1.2.5. Requisito(28) Una alarma dada podrá aceptar un número lı́mite de Z usuarios suscriptores, donde Z será configurable por el administrador (véase los requisitos C.3.1.2.3.1 y C.3.1.2.3.2). C.3.1.1.3. Otras tareas de gestión C.3.1.1.3.1. Requisito(29) El usuario podrá editar cualquier alarma o suscripción que haya creado previamente. Véase los requisitos C.3.1.1.3.5 y C.3.1.1.3.6 para detalles sobre la supresión de una alarma. C.3.1.1.3.2. Requisito(30) El usuario podrá consultar (pero no modificar) el estado de sus alarmas /suscripciones (e.g. un estado podrá ser ”Desactivado por el administrador”). C.3.1.1.3.3. Requisito(31) El usuario podrá consultar la fecha de última ejecución de cada una de sus alarmas / suscripciones. C.3.1.1.3.4. Requisito(32) El usuario podrá activar/desactivar una alarma / suscripción. Véase el requisito C.3.1.1.3.7 para detalles sobre las restricciones que pueden afectar la activación de una alarma. C.3.1.1.3.5. Requisito(33) En cualquier momento, el usuario podrá borrar una alarma / suscripción. Véase el requisito C.3.1.1.3.6 para detalles sobre la supresió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 preguntará al usuario si desea seguir con la supresión. En caso positivo, el sistema suprimirá la alarma y las suscripciones y avisará por correo electrónico a los usuarios suscritos. 130 C.3.1.1.3.7. Requisito(35) El usuario podrá ordenar sus alarmas por prioridad. Sólo podrá activar las N alarmas de mayor prioridad. En caso de reordenar una alarma activada en una prioridad más baja que N, la alarma será automáticamente desactivada, después de avisar al usuario. C.3.1.2. C.3.1.2.1. Administración de Ciclope Alarmas Configuración global del sistema C.3.1.2.1.1. ma. Requisito(36) El administrador podrá activar/desactivar todo el siste- C.3.1.2.1.2. Requisito(37) El administrador podrá definir franjas horarias de funcionamiento (i.e. activación) del módulo de alarmas. Fuera de éstas, el sistema funcionará 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 podrá definir dı́as festivos puntuales. Durante éstos, el sistema funcionará 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 podrá editar las alarmas/suscripciones definidas por cualquier usuario. C.3.1.2.2.2. Requisito(40) Para poder realizar esta labor eficazmente, el administrador podrá buscar dentro de las alarmas y suscripciones definidas mediante filtros de bú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 podrá desactivar cualquier alarma o suscripción. Cuando el administrador desactiva una alarma por este método, el estado de la alarma pasa a ser Desactivada por el administrador. Tiene el mismo efecto que si el usuario desactiva él mismo la alarma i.e. no se activará. C.3.1.2.3. Gestión de permisos de los usuarios C.3.1.2.3.1. Requisito(42) El administrador podrá definir para cada perfil cada uno de los siguientes elementos de restricción: El número máximo de alarmas que un usuario del perfil dado puede definir. 131 El número máximo de alarmas que un usuario del perfil dado puede activar al mismo tiempo. El número máximo de condiciones lógicas que un usuario del perfil dado puede utilizar en la definición de una alarma. El número máximo de acciones que un usuario del perfil dado puede configurar para cada alarma. El número máximo de suscriptores que puede tener una alarma definida por un usuario del perfil dado. El número máximo de alarmas a las que un usuario del perfil dado se puede suscribir. Para cada tipo de acción existente, el administrador podrá definir: • La posibilidad o no que tiene el usuario del perfil dado para utilizar dicho tipo de acción. • El número máximo de alarmas utilizando acciones de este tipo. C.3.1.2.3.2. Requisito(43) El administrador podrá redefinir para cada usuario cualquier restricción configurada a nivel de perfil. Dichas excepciones prevaldrán sobre las configuraciones a nivel de perfil. C.3.1.2.3.3. Requisito(44) Las excepciones sólo podrán tener un carácter restrictivo (no podrá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 número de alarmas que pueda definir un usuario de este perfil de 5 a 3). La solución escogida para solucionar este tipo de conflicto es la siguiente: en caso de conflicto, el sistema deberá tomar las acciones necesarias para que se cumplan las nuevas polı́ticas de restricción. Dichas acciones podrán incluir desactivar las alarmas de más baja prioridad hasta cumplir las nuevas reglas de restricción. El administrador tendrá la opción de mandar un correo electró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 diseño deberá ser lo suficientemente genérico para poder incluir fácilmente en el futuro nuevos tipos de variables (e.g. sensores). C.3.2.2 Requisito(47) El diseño deberá ser lo suficientemente genérico para poder incluir fácilmente en el futuro nuevos tipos de acciones. 132 C.3.2.3 Requisito(48) El diseño deberá prever la inclusión de otros observatorios en el sistema. C.3.3. Requisitos de interfaces externas C.3.3.1 Requisito(49) El sistema tendrá que ser capaz de comunicarse con los siguientes elementos externos: Flujo RSS conteniendo datos meteorológicos (wview). Servidor de correo electrónico. Módem GSM. C.3.4. Requisitos tecnológicos C.3.4.1 Requisito(50) Las interfaces gráficas necesarias se desarrollarán con Google Web Toolkit. C.3.4.2 Requisito(51) Los accesos a bases de datos se harán con Ibatis. 133 134 Bibliografı́a [1] Agencia Estatal de Meteorologı́a. Página oficial. http://www.aemet.es. [2] The Apache Software Foundation. Pá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. Documentación del observatorio robótico STELLA. http://www.aip.de/stella/index.php?id=docs. [5] Astrophysical Institute Potsdam. Observatorio robótico STELLA. http://www.aip. de/stella/. [6] Awekas. Página de configuración de datos de usuario. http://www.awekas.at/en/ benutzer.php. [7] Awekas. Página oficial. http://www.awekas.at. [8] José Alberto y Instituto Superior de Formación y Recursos en Red para el Profesorado Bermúdez. Grá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 automáticas de apertura y cierre en Calar Alto. http://www.caha.es/CAHA/visit.html#weather. [10] Canada France Hawaii Telescope. Pá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. Página web de la estación meteorológica del Observatorio Astronó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 España. http://www. cinterion.com/spain-andorra.html. [17] Cinterion Wireless Modules. cinterion.com/tc35it.html. Modelo de módem GSM TC35iT. http://www. [18] Davis Instrument. Modelo de estación meteoroló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. Documentación del proyecto ACS. http://www. eso.org/∼almamgr/AlmaAcs/. [21] Fabra-ROA telescope at Montsec. Pá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 Documentación Libre de GNU. http: //stuff.danexnow.org/gfdl es.html, November 2008. [28] Gnokii. Página oficial del proyecto gnokii - mó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. Comparación de tarifas GSM. http://www.gsmspain.com/tarifas/. [32] Enrique de Guindos. Estación meteorológica distribuida. Novática, (191):55–60, January 2008. 136 [33] Hammurapi Group. Página oficial. http://www.hammurapi.biz/hammurapi-biz/ef/ xmenu/hammurapi-group/products/hammurapi-rules/index.html. [34] Hamweather. Pá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 Geográfico Nacional. Glosario geográ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. Página oficial de Drools. http://www.jboss.org/drools/. [41] Jess. Página oficial. http://www.jessrules.com/. [42] Mandarax Project. Página oficial. http://mandarax.sourceforge.net/. [43] Meteohub. Pá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. Pá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. Página oficial del Telescopio Subaru. http://www.naoj.org/. [50] National Geospatial-Intelligence Agency. Artı́culos bá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. Página oficial. http:// weather.noaa.gov/. [54] National Oceanographic and Atmospheric Administration. Sección de FAQ de CWOP. http://www.wxqa.com/faq.html. [55] OpenRules, Inc. Página oficial. http://www.openrules.com/. [56] ozekisms. Lista de módems GSM recomendados. http://ozekisms.com/index.php? ow page number=148. [57] Personal Weather Stations. Página oficial. http://www.pwsweather.com. [58] QOS.ch. SLF4J License. http://www.slf4j.org/license.html. [59] Relación entre altitud y presión atmosférica. http://www.astrosurf.com/luxorion/ meteo-pression.htm. [60] Gary Riley. Página oficial de CLIPS. http://clipsrules.sourceforge.net/. [61] Siemens. TC35i AT Command Set. Siemens, September 2005. Versión 03.01. [62] Siemens. TC35i Terminal Hardware Interface Description. Siemens, December 2005. Versión 03.01. [63] Sun Microsystems, Inc. Binary Code License Agreement. https://cds.sun.com/is-bin/INTERSHOP.enfinity/ 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 - Configuració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 España. http://www.wavecom. com/modules/movie/scenes/locator/index.php?locator=distributors&country= ES&zone=ze europe. [69] Weather For You. Página oficial. http://weatherforyou.com/. [70] Weather Underground. Página oficial. http://www.wunderground.com. [71] WeatherBug. Pá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. Página oficial. http://www.wmo.int. [75] Michal Čihař. Lista de móviles compatibles con Gammu. http://cihar.com/gammu/ phonedb/. 139