JORGE ANTONIO BLANCO VELANDIA
Magister(c)
Universidad Distrital Francisco José de Caldas
Estudiante
Grupo Internacional de Investigación en
Informática, Comunicaciones y Gestión del
Conocimiento - GICOGE
jorgeblanco@uniboyaca.edu.co
COLOMBIA
JOSÉ NELSON PÉREZ CASTILLO
Doctor
Universidad Distrital Francisco José de Caldas
Docente Universitario e Investigador
Director del Grupo Internacional de
Investigación en Informática, Comunicaciones
y Gestión del Conocimiento - GICOGE
nelsonp@udistrital.edu.co
COLOMBIA
INFORMACIÓN DE LA INVESTIGACIÓN O DEL PROYECTO: El presente artículo de investigación científica y tecnológica surge como resultado de un estudio realizado en la Universidad Distrital Francisco José de Caldas al interior del Grupo Internacional de Investigación en Informática, Comunicaciones y Gestión del Conocimiento - GICOGE en el marco del proyecto general denominado: Modelo para el manejo de la información geográfica generada por una red inalámbrica de Geosensores, proyecto específico: Plataforma de computación grid para redes inalámbricas de Geosensores.
TEMÁTICA: Sistemas inalámbricos y móviles, Teleaplicaciones.
TIPO DE ARTÍCULO: Artículo de Investigación Científica y Tecnológica.
RECEPCIÓN: 4 de Junio de 2012
ACEPTACIÓN: 4 de Octubre de 2012
Este artículo presenta una visión general sobre el desarrollo de una plataforma de computación grid para redes inalámbricas de geosensores, se basa en los servicios establecidos por el Open Geospatial Consortium, OGC en su iniciativa Sensor Web Enablement, SWE. La plataforma permite el manejo de la información geográfica generada por este tipo de redes. Inicialmente se entrega una visión general del modelo de la plataforma describiendo las capas de Geosensores o capa física, Geosensor Web o capa de servicios y la capa de Aplicaciones. Se explican los servicios grid de Registro, Notificación, Observación, Planificación y Persistencia, y las capas de integración denominadas Portal Grid y Grid Sink que hacen parte de la arquitectura del modelo. Se establecen los requerimientos tecnológicos para la implementación de la plataforma, la descripción de los nodos que la conforman y la manera como estará desplegada en los diferentes nodos. Se entrega el proceso seguido para la evaluación y pruebas de la plataforma, análisis de casos de pruebas diseñados y empleados junto con entradas del proceso, criterios de evaluación y evaluación de resultados. Finalmente se establece una tabla de funcionalidad de la plataforma basada en la ejecución de análisis de casos de prueba.
PALABRAS CLAVES: Sensor Grid, Sensor Web Enablement, Redes Inalámbricas de Sensores, Redes Inalámbricas de Geosensores, Computación Grid
This article presents an overview of the development of a grid-computing platform for wireless geosensor networks, is based on services provided by the Open Geospatial Consortium, OGC in Sensor Web Enablement, SWE initiative. The platform allows the management of geographic information generated by these networks. Initially provides an overview of the platform model describing the layers of Geosensores or physical layer, GeoSensor Web or service layer and Application layer. Explains grid services Registration, Reporting, Monitoring, Planning and Persistence, and integration layer called Grid Portal and Grid Sink that are part of the architecture of the model. Establishing the technological requirements for implementation of the platform, the description of the nodes that form and manner as will be deployed on different nodes. Delivered the process for evaluation and testing of the platform, the test case designed and used along with process inputs, process, evaluation criteria and evaluation of results. Finally establishing a table platform functionality based on the execution of analysis of test cases.
Keywords: Sensor Grid, Sensor Web Enablement, Wireless Sensor Network, Wireless Geosensor Network, Grid, Computing
La tecnología de redes inalámbricas de geosensores, GSN (Wireless Geosensor Network) ha evolucionado permitiendo la construcción de dispositivos que se caracterizan por su reducido tamaño, su economía, inteligencia y el uso eficiente de energía. En consecuencia, diferentes campos de aplicación están haciendo uso de este tipo de redes; por ejemplo en la gestión de desastres, vigilancia del medio ambiente, agricultura de precisión, sistemas de alerta temprana, aplicaciones inteligentes para el hogar, entre otros campos. Las GSN utilizadas en estas aplicaciones pueden contener nodos estacionarios o nodos en movimiento que logran reunir gran cantidad de datos in situ o remotos [2]. Este auge tecnológico y la necesidad de un modelo de procesamiento avanzado de la información generada por este tipo de redes han sido la fuerza impulsora para que el Open Geospatial Consortium, OGC [7] haya dado luz verde a la iniciativa Sensor Web Enablement, SWE [8].
El OGC a través de la propuesta SWE define un conjunto de estándares como solución teórica para el habilitamiento de sensores en la web, mediante la inclusión de una serie de servicios que permiten realizar actividades tales como registro de usuarios, registro de sensores, procesos de observación y planificación, verificación de datos y notificación a usuarios.
En la Universidad Distrital Francisco José de Caldas de Colombia al interior del Grupo Internacional de Investigación en Informática Comunicaciones y Gestión del Conocimiento - GICOGE se han desarrollado diferentes proyectos de investigación que contienen las especificaciones necesarias para implementar los servicios de Notificación y Registro [1], Servicio de Observación [5], Servicio de Persistencia [10] y Servicio de Planificación [5] en GT4 [4]. Estos servicios grid construidos han sido insumo para la construcción de la plataforma de computación grid para GSN.
Para el desarrollo del proyecto se siguieron las siguientes fases:
Fase 1: Estudio exploratorio sobre los fundamentos teóricos involucrados en el estudio.
Fase 2: Diseño del modelo para la plataforma de computación grid.
Fase 3: Desarrollo del prototipo a partir de las especificaciones del modelo diseñado, empleando la metodología propuesta por Borja Sotomayor [3], que define cinco pasos básicos: definición de la interfaz del servicio grid, implementación del servicio grid, definición de los parámetros de despliegue, generación del archivo grid y despliegue del servicio en un contenedor de servicios.
Fase 4: Evaluación de la plataforma empleando casos de prueba prediseñados.
El modelo propuesto se ilustra en la Figura 1; presenta la vista arquitectónica general del modelo de la plataforma integrada por tres capas: GeoSensor o capa física, GeoSensor Web o capa de servicios grid y la capa de Aplicaciones. Establece dos capas de integración denominadas Grid Sink y Portal grid.
En los siguientes numerales se especifica la funcionalidad de cada uno de los componentes del modelo.
La capa GeoSensor o capa física genera observaciones que son enviadas al Grid Sink, este las convierte a formato XML y las almacena hasta cuando el servicio de Persistencia las requiera para realizar el almacenamiento en la base de datos grid bdGeoSensores.
En esta capa pueden darse dos situaciones para la GSN:
Para el primer caso el Grid Sink recibe los datos captados por la red física de sensores por medio del Gateway de la red; en el segundo caso genera el modelo para simular la red teniendo en cuenta los sensores registrados y las políticas establecidas desde el servicio de Planificación, luego envía la configuración a la herramienta de simulación para que se genere la GSN y el proceso de obtención o captado de datos.
Uno de los desafíos encontrados en el desarrollo de esta capa fue el diseño comunicacional con la capa de GeoSensor Web de manera que se pudiera establecer una alimentación transparente de las observaciones de la GSN. Luego de testear con varios simuladores de GSN y de procesos prueba - error finalmente se implementó la GSN por medio del simulador OMNeT ++ [9] y el marco de trabajo Castalia [12] como generador de observaciones. Cabe resaltar que la mayoría de paquetes que existen para simular GSN no permiten simular el fenómeno de observación, razón por la cual se empleó el marco de trabajo Castalia que ofrece la posibilidad de manejar tres fenómenos: temperatura, luz y humedad.
Servicio integrador que comunica la capa GeoSensor con la capa GeoSensor Web de manera transparente. Grid Sink establece cuatro funciones específicos:
Agrupa los servicios grid proporcionados por la plataforma que se implementaron en java sobre GT4. La funcionalidad de estos servicios se especifica en los siguientes numerales.
Ofrece al usuario tres funcionalidades las cuales son expuestas a través del WSDL del servicio: registro de usuarios, registro de sensores y proceso de notificación.
El servicio grid de notificación realiza las siguientes operaciones [1]:
Servicio grid que recibe las observaciones realizadas por la capa de GeoSensores mediante el archivo XML de observaciones. Este servicio conecta con la base de datos bdGeoSensores, abre el archivo XML, extrae las observaciones simuladas para cada sensor y las almacena para que puedan ser consultados por los servicios grid de Notificación, Planificación y Observación o por cualquier aplicación grid vía Portal Grid.
Servicio grid que permite determinar la disponibilidad de observaciones y planificaciones, teniendo en cuenta diferentes criterios: sensor, rango de valores, tipo de fenómeno y fecha de la observación planificada. Además permite la consulta de información técnica de los sensores: coordenadas de su ubicación física (longitud, latitud y altitud) y su estado (activo o inactivo) [5].
La construcción de Portal grid se realizó mediante el desarrollo de portlets que utilizan la especificación JSR 168. Los portlets efectúan una función específica dentro del portal, manejando un lenguaje común para desarrolladores que buscan desplegar contenido web [6]. Portal Grid establece la integración de los servicios de la capa GeoSensor Web con la capa de Aplicaciones mediante portlets.
Los servicios que Portal Grid ofrece se enuncian a continuación [6]:
Para acceder y hacer uso de los servicios grid de la plataforma el usuario:
Los servicios grid descritos anteriormente y todos sus componentes se distribuyen en un ambiente de implementación como se ilustra en la figura 2 de acuerdo también con los requerimientos tecnológicos.
Para el despliegue de la plataforma se emplean cinco nodos: Cliente, Contenedor GT4, GridSphere Server, MyProxy y Simulador.
El nodo Cliente aloja el navegador desde donde el usuario accede a la plataforma de computación por medio de Portal Grid; allí entrega sus credenciales y se ejecutan los procesos de verificación autenticación y autorización.
GridSphere Server es el nodo contenedor de GridSphere, aloja el Portal grid que comunica la plataforma con el usuario final; contiene además los portlets de cada uno de los servicios que cumplen tareas específicas como se describió en los numerales anteriores; cada portlet referencia a un archivo de visualización construido en jsp que se aloja en el servidor de aplicaciones Apache Tomcat.
GridSphere controla el acceso a los recursos y servicios que proveen los portlets, mediante la autenticación de los usuarios, gestionando la seguridad mediante la concesión de credenciales válidas, permitiendo de esta manera el consumo de servicios grid que se encuentran contenidos en GT4.
Contenedor Globus, en este nodo se encuentra instalado GT4. Allí se encuentran desplegados los servicios grid junto con sus archivos de descripción (Web Service Deployment Language, WSDL), los parámetros para despliegue del servicio contenidos en el Descriptor de Despliegue del Servicio Web (Web Service Deployment Descriptor, WSDD), las utilidades para publicación de servicios grid (Java Naming and Directory Interface, JNDI) útiles para que el cliente pueda descubrir y hacer uso del servicio.
Simulador, nodo encargado de recibir el archivo de configuración de la simulación este archivo ha sido previamente elaborado de acuerdo con los sensores registrados y a sus características; basado en ese archivo ejecuta la simulación sobre OMNeT ++, este proceso genera una serie de archivos los cuales son condensados en uno solo y enviados al nodo GridShere Server por medio del Grid.
En el nodo MyProxy, se encuentra la aplicación MyProxy encargada de gestionar claves públicas con certificados X.509 y credenciales de seguridad. La identidad del usuario está ligada a una clave de conocimiento público a través de un certificado expedido y firmado por una Entidad Certificadora (CA). En los sistemas grid, el proceso de movimiento de claves de usuario entre los diferentes recursos de computación puede llegar a ser un proceso vulnerable y peligroso; en este caso la firma del certificado se hace a través de una interfaz de usuario, cuando el certificado ya es firmado se coloca en un repositorio de credenciales MyProxy y de allí se recupera la credencial del usuario a través de portlets, es así que almacenar credenciales en un repositorio MyProxy permite a los usuarios obtener fácilmente credenciales RFC 3820 proxy, sin preocuparse de la gestión de clave privada y el certificado de archivos [6].
Un objetivo de las pruebas de software es descubrir defectos en el software en que el comportamiento de éste es incorrecto, no deseable o no cumple su especificación. La prueba de defectos está relacionada con la eliminación de todos los tipos de comportamientos del sistema no deseables, tales como caídas del sistema, interacciones no permitidas con otros sistemas, cálculos incorrectos y corrupción de datos [11].
La evaluación de la plataforma se realizó mediante análisis de casos de prueba para ello se establecieron los siguientes parámetros empleando Portal Grid:
La tabla 1 muestra los casos de prueba analizados en la evaluación funcional de la plataforma. Los resultados entregados corresponden a máximo cinco iteraciones por cada caso de prueba.
Entrada: listado de sensores con valores de longitud (x), latitud (y), y altitud (z).
Proceso: Ingreso a la plataforma mediante Portal Grid, autenticación e ingreso al jsp del portlet Registro de sensores, ingreso de cada uno de los sensores y sus características.
Evaluación de resultados: La tabla 2 muestra los criterios evaluados en este caso de prueba, el valor esperado del criterio evaluado y el valor obtenido del caso de prueba.
Entrada: Fecha y hora para planear la observación.
Proceso: Ingreso a la plataforma mediante Portal Grid, autenticación e ingreso al jsp del portlet Planificación, ingreso de fecha y hora planificada para la observación.
Evaluación de resultados: La tabla 3 muestra los criterios evaluados en este caso de prueba, el valor esperado del criterio evaluado y el valor obtenido del caso de prueba. Este es un caso de prueba muy sencillo que consiste en ingresar un registro con la programación de la observación, realmente los criterios de evaluación se reducen al almacenamiento de los datos en la base de datos bdGeoSensores.
Entrada: Sensores registrados en la entidad sensores de la bdGeosensores.
Proceso: Ingreso a la plataforma mediante Portal Grid, autenticación e ingreso al jsp del portlet Configuración de simulación, seleccionar la opción generar archivo de configuración.
Evaluación de resultados: La tabla 4 muestra los criterios evaluados en este caso de prueba. Inicialmente este caso de prueba generaba un rendimiento del 83% debido a que el algoritmo de asignación del nodo sink no se estaba teniendo en cuenta, al definir adecuadamente el nodo sink por el simulador la relación de rendimiento pasó al 100% y por consiguiente las advertencias y errores no volvieron a generarse.
Entrada: archivo de configuración generado y el registro de planificación de la observación.
Proceso: Ejecución de la simulación en la fecha y hora planeada.
Evaluación de resultados: La tabla 5 muestra los criterios evaluados en este caso de prueba, el valor esperado del criterio evaluado y el valor obtenido del caso de prueba. Inicialmente el porcentaje de rendimiento en este caso de prueba fue muy bajo debido a que el archivo de configuración no era generado correctamente, razón por la cual se generaban errores al ejecutar la simulación, este porcentaje fue subiendo a medida que el archivo de configuración se fue depurando en el caso de prueba anterior.
Entrada: archivo de observaciones.
Proceso: Ingreso a la plataforma mediante Portal Grid, autenticación e ingreso al jsp del portlet Visualización.
Evaluación de resultados: La tabla 6 muestra los criterios evaluados en este caso de prueba, el valor esperado del criterio evaluado y el valor obtenido del caso de prueba.
Entrada: archivo XML producto del proceso de simulación
Proceso: Ingreso a la plataforma mediante Portal Grid, autenticación e ingreso al jsp del portlet Persistencia.
Evaluación de resultados: La tabla 7 muestra los criterios evaluados en este caso de prueba, el valor esperado del criterio evaluado y el valor obtenido del caso de prueba.
Entrada: Registros de la entidad Sensor que fueron registrados para la presente prueba y las observaciones.
Proceso: Ingreso a la plataforma mediante Portal Grid, autenticación e ingreso al jsp del portlet Observación.
Evaluación de resultados: La tabla 8 muestra los criterios evaluados en este caso de prueba, el valor esperado del criterio evaluado y el valor obtenido del caso de prueba.
La tabla 9 muestra los resultados obtenidos de la evaluación realizada a la plataforma propuesta en esta investigación, los resultados entregados en este informe corresponden a la ejecución de cada caso de prueba iterativamente hasta conseguir resultados óptimos y constantes; cabe anotar que en las primeras iteraciones los resultados no fueron los esperados como se aprecia en la tabla 9 columna dos, debido a errores generados por semántica o sintaxis en el archivo de configuración de la simulación y por la configuración del nodo sink al momento de la ejecución de la simulación y de acuerdo con los criterios empleados en cada caso de prueba el rendimiento de los casos finales por consecuencia lógica era muy bajo.
La forma como se diseñaron casos de prueba y los criterios de evaluación propuestos en cada caso permitieron probar el funcionamiento y dar en forma de porcentaje el rendimiento de esta.
Se ha demostrado mediante análisis de casos de prueba que el modelo arquitectónico propuesto para la plataforma y conformado por las capas Geosensor o capa física, Geosensor Web o capa de servicios y la capa de Aplicaciones es 100% funcional.
La implementación de Grid Sink, como parte de la arquitectura del modelo, demostró ser una alternativa óptima y funcional para establecer comunicación transparente entre los procesos de simulación, la red inalámbrica de geosensores y los servicios grid de GT4, mediante la generación del archivo de configuración, construido a partir de los sensores registrados, sus características (latitud, longitud y altitud) y los requerimientos de OMNeT++.
Para el modelado del entorno de simulación se evaluaron diferentes simuladores logrando integrar un simulador actual, escalable y compatible con diversos marcos de trabajo que permiten diseñar redes inalámbricas de geosensores. Esto hace que la plataforma sea funcional y abierta a cualquier marco de trabajo compatible con el simulador, de manera que los cambios al método generador del archivo de configuración de la simulación sean en gran porcentaje nulos.
La arquitectura de la plataforma es flexible de manera que puede ser expandida para integrar la plataforma con redes inalámbricas de geosensores que implementen nodos móviles, servicios de geoVideo para facilitar la visualización de geosensores con una combinación de video y datos asociados; esto permitiría generar un servicio grid de observación más dinámico y útil al usuario final además de entregar acontecimientos en tiempo real del fenómeno observado o monitoreado.
[1] BÁEZ, Carmen. Planteamiento de un modelo para los servicios grid de Notificación y Registro de información Geográfica. Revista Gerencia Tecnológica Informática, Volumen 8 No. 20, p. 13- 22, 2009.
[2] BLANCO VELANDIA, Jorge Antonio. Redes Inalámbricas de Geosensores aplicadas en sistemas de observación y monitoreo ambiental. Revista Gerencia Tecnológica Informática, Volumen 11 No. 29, 2012.
[3] BORJA, Sotomayor. The Globus Toolkit 4 Programmer's Tutorial. (Online). 2005. (Citado 24 ene., 2011). http://gdp.globus.org/gt4-tutorial/multiplehtml/index.html
[4] GLOBUS ALLIANCE. Globus Toolkit. (Online). 2011. (Citado 12 ene., 2012). www.glous.org
[5] GÓMEZ ESTUPIÑÁN, Juan Federico. Habilitamiento de la web para manejo de información de geosensores: servicio de observación de sensores y servicio de planificación de sensores. una mirada hacia sensor grid. Revista Gerencia Tecnológica Informática Volumen 10 No. 26, p. 55 - 65, 2011.
[6] MONTAÑEZ, Sandra. Modelo de portal para el Laboratorio de Computación Grid. Revista Ingeniería y Universidad. Volumen 12 No. 1, p. 213-228, 2008.
[7] OGC. Web OGC. (Online). 2009. (Citado 2 febr., 2011). http://www.opengeospatial.org/
[8] OGC. Sensor Web Enablement. (Online). 2011. http://www.opengeospatial.org/projects/groups/sensorwebdwg
[9] OMNeT++. (Online). 2009. (Citado 12 dic., 2011). http://omnetpp.org/
[10] VARGAS BERMUDEZ, Francisco. Prototipo de modelo de persistencia para la variable temperatura irradiada, sensada por un geosensor para ser almacenada en ambiente grid. Revista colombiana de tecnologías de avanzada, No. 13, p. 117-124, 2008.
[11] SOMMERVILLE, Ian. Ingeniería del Software, 2004. Pearson Education 6 Edición
[12] NICTA. Castalia A simulator for WSNs. (Online). 2004. (Citado 12 ene., 2012). http://castalia.npc.nicta.com.au/