1. Introducción
Si se considera que el clima es un sistema caótico, es imposible predecir las condiciones meteorológicas de una región con suficiente precisión y antelación. Este aspecto se vuelve todavía más crítico cuando se trata de reaccionar de forma inmediata ante eventos climatológicos extremos. Este hecho da lugar al objetivo principal de este trabajo, el cual está orientado al desarrollo de una arquitectura que permita recopilar información hidrometeorológica de forma automática, para usarla como base para reaccionar apropiadamente ante fenómenos hidrológicos y climatológicos extremos. Al tomar como referencia trabajos anteriores (Muñoz Guillén et al., 2016) y (Veintimilla-Reyes, Guillermo, Vanegas, & Estrella, 2017), se ha procedido a establecer una arquitectura basada en el estándar Sensor Web Enablement (SWE) para poder integrar y almacenar la información entregada por cada uno de los sensores de una red de monitoreo hidrometeorológico. Además de integrar información de dispositivos diversos, almacenarla y hacerla accesible, la arquitectura propuesta es capaz de controlar los equipos de la red de monitoreo de forma remota y, además, permite configurar, generar y difundir alertas ante la ocurrencia de eventos predeterminados en la región monitoreada. Al observar que la red de monitoreo normalmente va a estar conformada por estaciones y sensores de diferentes fabricantes y tipos, es lógico suponer que los datos generados por cada componente de la red van a ser distintos en cuanto a su representación y a su formato. Por tanto, es fundamental establecer mecanismos de homogenización para poder integrar estos datos de naturaleza diversa. La solución que se propone en este artículo es la aplicación de ontologías, de tal forma que los datos recibidos de cada sensor se puedan interpretar, organizar y almacenar de forma unificada, sin importar las características específicas de la fuente de información.
2. Revisión de Literatura
En el mundo actual, es necesario disponer de información inmediata sobre los eventos que se producen en una determinada zona y bajo ciertas condiciones. En este sentido, Veintimilla et al. (2014), desarrollaron un sistema capaz de trasmitir información de sensores hidrometeorológicos mediante una red de comunicación con la tecnología GSM (Veintimilla-Reyes Jaime & Capelo Patricio, 2014).
Adicionalmente, primeras aproximaciones para el desarrollo de una arquitectura para transmisión, integración y visualización de información, se han encontrado en (Muñoz Guillén et al., 2016; Veintimilla-Reyes & Avila, 2015); los mismos que han incluido diferentes estándares de acceso libre creados por OGC (Open Geospatial Consortium)(Botts, Percivall, Reed, & Davidson, 2008), ampliamente difundidos a nivel mundial.
En cuanto se refiere a los estándares de almacenamiento e integración de información, muchos estudios se han realizado con el objetivo de manejar uniformemente la información controlada por cada uno de los sensores remotos. En este sentido, una nueva versión de estándares de OCG fueron creados y adaptados para poder llegar a establecer esta interoperabilidad (Bröring et al., 2011). Además, y basándose en el criterio de la utilización de ontologías para generalizar la aplicación de estos estándares, Calbimonte et al. (2011) (Calbimonte, Jeung, Corcho, & Aberer, 2011) y Compton et al. (2012) (Compton et al., 2012), han reportado la exitosa aplicación de los SSN (Semantic Sensor Networks).
Además, muchas experiencias en la utilización de SWE se han encontrado a nivel mundial. En este sentido, Longueville et al. (2010) (De Longueville, Annoni, Schade, Ostlaender, & Whitmore, 2010), han implementado una red de sensores en tiempo real para la prevención de crisis a nivel mundial, la cual integra los estándares antes mencionados y las IDE (Infraestructuras de Datos Espaciales) con el fin de visualizar información directamente de los sensores.
Otros trabajos fundamentales para la presente investigación, se han encontrado en (Degrossi, Amaral, Vasconcelos, Albuquerque, & Ueyama, 2013; Jirka, Bröring, & Stasch, 2009; Quiñones-Cuenca, González-Jaramillo, Torres, & Jumbo, 2017; Rouached, Baccar, & Abid, 2012), los cuales se han centrado principalmente en la utilización de redes de sensores para obtener información en tiempo real y con esto prevenir desastres.
Diferentes trabajos de investigación se han enfocado en la homogenización de la información que generan y almacenan los sensores de diferente tipo. En este sentido, Sánchez Fleitas et al. (2016) y Machado-García et al. (2014) en sus trabajos han demostrado la factibilidad de la utilización de ontologías. El primero relacionado con el sector energético mientras el segundo con el campo de los sistemas de información geográfica. En este sentido, es necesario definir lo que es una ontología y cómo su utilización puede ser la solución al antes mencionado problema. Según Rodríguez et al. (2017), el crecimiento de la Internet y más precisamente la WEB 2.0 han hecho que se requiera la interpretación de diferentes atributos de los objetos tal como lo harían los seres humanos, esto, debido a que diferentes nombres o atributos de objetos pueden referirse a la misma característica únicamente con un nombre diferente. En este caso, la solución propuesta en Rodríguez et al. (2017) está orientada a que la búsqueda de los mencionados objetos se base en un criterio más semántico en lugar de buscar directamente de una manera sintáctica dentro de la Internet. A más, de la utilización de la semántica se requiere también que exista un enlace entre todos y cada uno de los posibles nombres que pueda tener un componente de un objeto. Esto, es posible mediante la utilización del paradigma de “Datos Enlazados” que permite identificar, describir, conectar y relacionar posibles componentes de un objeto.
En relación con los Datos Enlazados (Linked Data), permiten la interconexión entre diferentes componentes mediante la utilización de RDFs (Resource Description Frameworks) y de las llamadas URIs (Uniform Resource Identifiers) para intercambiar información y que esta sea accedida por diferentes computadores dentro de una misma red (Rodríguez et al., 2017).
Basados en la necesidad de interactuar con diferentes tipos de sensores, OGC ha desarrollado SSNO (Semantic Sensor Network Ontology). Esta ontología permite dar solución a los problemas señalados mediante la generalización de los componentes de un sensor para hacerlo disponible semánticamente a través de una red o directamente desde Internet (Compton et al., 2011, 2012; Cox, 2017).
3. Una arquitectura para el monitoreo hidrometeorólogico automático mediante servicios web estándar
La Figura 1 muestra el esquema de la arquitectura propuesta, la cual ensambla varios servicios web estándar contenidos en SWE con el objetivo de monitorear integralmente (recopilación de información, control remoto de equipos y generación de altertas) características hidrológicas y meteorológicas de la región de estudio. En esta constan 3 capas o módulos que incluyen: aplicación, servicios y de sensores propiamente dichos. Estos son detallados a continuación:
Capa de aplicación: en la capa de aplicación se dispone de una página web que permita recibir la información disponible de un sensor, además de tener una interfaz gráfica que permite controlar los sensores (Sensor Web Enablement y Simulation Lab Sensor). Además, la comunicación entre cada una de las capas se realiza mediante la utilización de XML (Extensible Markup Language).
Capa de servicios: esta capa incluye el control y acceso a cada uno de los estándares de SWE. Mediante la utilización de esta capa, el usuario descubre los servicios de SPS (Sensor Planing Service), SOS (Sensor Observation Service) y SES (Sensor Event Service) mediante series de registros codificados en XML.
Fig. 1:Arquitectura
basada en SWE para la integración de la información de sensores remotos
SPS (Sensor Planing Service): es el encargado de descubrir los sensores que se encuentran en la red y crear una colección. Con esta colección, se podrán determinar las tareas posibles a realizar (Figura 2). Además, se pueden establecer las tareas, revisar el estado de cada una, solicitar resultados o cancelarlas.
Fig. 2:Descripción
del funcionamiento del servicio SPS (52 North, n.d.-b)
Un ejemplo de funcionamiento podría ser: el usuario genera una llamada “GetFeasibility-Request”, entonces un documento XML es elaborado de acuerdo con las características y capacidades de que dispones el sensor y lo envía directamente al servicio SPS. El mencionado servicio recibe la petición y decodifica el XML, determina las características necesarias y genera una llamada “GetFeasibility-Response” y la envía al usuario. Un esquema decodificado es usado para la creación de los primeros prototipos. En este punto, el esquema desarrollado trabajará directamente con el servicio SPS para la implementación de la tarea asignada.
SOS (Sensor Observation Service): entre las tareas más importantes de este servicio, está la de identificar nuevos sensores y proveer datos. Permite además acceso al repositorio donde son almacenadas las observaciones medidas por los sensores. En este sentido, provee también acceso en tiempo real a la información que se encuentra almacenada en el sensor.
SES (Sensor Event Service): es una mejora al antes utilizado SAS (Sensor Alert Service), ambos son empleados para proveer información de alertas sobre un sensor. Hay que tener presente que estos servicios funcionan con un modelo publicación / suscripción.
Como se puede ver en la Figura 3, mediante la utilización de este tipo de servicios, se puede establecer condiciones en las cuales un sensor debe informar de su estado al servidor mediante diferentes tipos de alarmas. Adicionalmente, para obtener información sobre determinados eventos, el cliente debe suscribirse para recibir las notificaciones del caso, esto indica que un usuario que no esté suscrito no recibirá ninguna información. Además, las alertas se definen basadas en las características y capacidades propias del sensor.
Fig. 3:
Descripción del funcionamiento del servicio SES (52 North, n.d.-a)
La comunicación entre cada uno de los componentes de este servicio, se realiza mediante la utilización de EML (Event Pattern Markup Language) y además permite describir las características del sensor y también establecer los filtros necesarios.
WNS (Web Notification Service): este servicio permite el envío y recepción de alertas basadas en eventos establecidos por el servicio SES. La entrega de esta información permite a los usuarios determinar las acciones a tomar bajo determinadas condiciones.
En la Figura 4, se puede observar cada uno de los componentes que intervienen en el funcionamiento de este servicio. Cabe indicar que el mencionado servicio, se basa en una comunicación de tipo asíncrona para la notificación de eventos, tareas u observaciones de fenómenos como tales.
Como paso posterior a la configuración de este servicio, es necesario también la utilización de medios de comunicación con los clientes o receptores de la notificación, los medios posibles pueden ser: http, xmpp, email, sms, fax, pone, etc.
Fig. 4:Descripción
del funcionamiento del Servicio WNS (52 North, n.d.)
Capa de sensores: en esta capa, se puede controlar al sensor; como intermediario entre la capa de servicios y la capa de sensores existe un plug-in que permite registrar varios tipos de tareas y hacer que estas sean accesibles a través del framework de SPS, para nuestro caso este plugin está embebido de cierta manera en el dataLogger (dispositivo capaz de registrar los eventos) que se tiene desarrollado en el proyecto, es decir este plug-in permitirá la comunicación entre el servidor de SPS y el sensor, esta comunicación se realizará mediante un archivo de configuración con codifcaciones xml que contendrá los métodos más importantes como son: a) GetFeasibilityRequest, b) SubmitRequest, c) UpdateRequest, d) GetStatusRequest y e) CancelRequest.
Este documento de configuración contiene toda la información importante del sensor físico. Es necesario indicar que este documento es utilizado en el momento de inicio y registro de un nuevo sensor para finalmente almacenar toda la información en la base de datos del SPS.
Semantic Sensor Network Ontology (SSNO): la Figura 5 muestra un esquema de cómo se podría adaptar la ontología SSNO para los propósitos de la investigación descrita en este artículo. El esquema de la figura propone una generalización de cada uno de los componentes de los sensores que se debe considerar.
Fig. 5:Generalización
La ontología completa dispone de 41 conceptos y 39 propiedades de objetos. La misma que puede describir cualquier tipo de sensores, las características de los mismos tales como exactitud, capacidades, etc., además de la descripción completa de la metodología empleada por los mismos para realizar las mediciones.
El punto clave dentro de esta ontología es el patrón Stimulus-Sensor-Observation, este patrón vincula los sensores, lo que ellos miden y las observaciones resultantes del proceso de medición. Esta ontología ha sido diseñada como un mínimo componente que debe estar presente en las ontologías basadas en Semantic Sensor Web (SSW) y que se encuentran fundamentadas en datos enlazados.
Stimuli (Stimulus):
en otras palabras es el estímulo que detecta el sensor para cambiar de estado (dul:event), esto en un ambiente en el cual el sensor puede observar y usar para medir una propiedad.
Sensors:
en la presente ontología corresponden a los sensores físicos (ssn:Sensor) que observan y transforman el estímulo (Stimuli) recibido en otra señal comunmente conocida como salida (ssn:SensorOutput).
Observations:
las observaciones son el nexo del patrón SSO. Para un evento de registro, una observación puede enlazar el acto de anotar estímulo y sensor, para transformarlo en una salida (observación).
4. Resultados
Como parte de la creación de la arquitectura, se procedió a la validación de la misma mediante la creación de un prototipo funcional. El mencionado prototipo se desarrolló mediante información proporcionada por el Programa para el Manejo del Agua y el Suelo (PROMAS). En este caso particular, se hizo uso de una estación hidrometeorológica ubicada en la zona de Marianza, más precisamente en el sector denominado “El Cajas” a 20 km de la ciudad de Cuenca en la provincia del Azuay en Ecuador.
La mencionada estación, registra información sobre: temperatura, humedad, velocidad y dirección del viento, presión, radiación y precipitación.
Para la creación de la plataforma informática, se ha utilizado como base la herramienta creada por 52North (52°North, 2016). Esta herramienta ha sido ampliamente utilizada por varias empresas a nivel mundial y tiene constante mantenimiento y actualizaciones, cabe indicar que es de código abierto y libre distribución. Al tener esto como consideración, se configuró la plataforma para trabajar con los servicios de: SOS, SES, WNS y SPS.
Además, como base informática se ha creado un servidor que utiliza apache Tomcat como base y que está disponible para recibir la información y almacenarla en una base de datos postgreSql.
En la Figura 6, se puede apreciar una descripción de las lecturas registradas por el sensor, así como también los registros que se vinculan directamente con los servicios proporcionados por SWE y más precisamente el estándar SOS. Como resultado, el sensor envía los esquemas O&M con la información registrada y mediante el esquema SensorML, se pueden identificar las características del sensor que envía la información.
Fig. 6:Componentes
de una observación en el servidor para la estación Marianza
5. Discusión
Durante el desarrollo del presente proyecto de investigación, se ha podido observar que la arquitectura propuesta para la integración y control de la información de los sensores hidrometeorológicos, es promisoria debido a su alto nivel de acople en relación con la facilidad de la inclusión de nuevos sensores de diferentes marcas. Sin embargo, es necesaria la extensión de las pruebas a otras marcas diferentes a las que dispone actualmente el PROMAS de la Universidad de Cuenca.
Otro punto a tener en cuenta es el constante desarrollo que disponen los estándares creados por OGC, en este sentido, se podría pensar en llegar a tener un control total sobre todas las características y opciones que provee tal o cual equipo.
6. Conclusiones y Recomendaciones
El constante desarrollo de los estándares creados por OGC y el hecho que haya una implementación por parte de 52North (52°North, 2016), permite que se tenga un soporte de una comunidad grande de desarrolladores a nivel mundial. Además, cada uno de ellos pone a disposición un sinnúmero de adaptaciones y nuevas funcionalidades de SWE.
En cuanto hace referencia a la presente investigación, se ha logrado disponer de una arquitectura/plataforma capaz de controlar remotamente sensores hidrometeorológicos; esto es importante cuando existen sensores que no son accesibles fácilmente debido grandes distancias o simplemente por lo remoto de su ubicación.
Adicionalmente y con el crecimiento de las comunicaciones, el presente trabajo constituye una base para la creación de sistemas de alerta temprana y gestión de riesgos; permite con esto que usuarios o entidades puedan delinear procesos a realizar para evitar o solucionar problemas potencialmente catastróficos.
El presente trabajo se ha centrado en sensores hidrometeorológicos, como paso posterior se pretende la extensión de esta arquitectura hacia diferentes tipos de sensores: clima, tráfico, entre otros y con esto incrementar el número de redes de sensores existentes que se encuentran monitoreando diferentes eventos o sucesos.
Es recomendable también, continuar con el desarrollo de esta arquitectura mediante la validación en diferentes campos de los estándares SWE y más aún la ontología (SSNO) con el fin de asegurar que cualquier tipo de sensor pueda agregarse fácilmente a la red de sensores que actualmente dispone el PROMAS - Universidad de Cuenca.
