“Sistema De Monitoreo De Gases Para Prevención De Estados Peligrosos Utilizando Redes De Sensores: Módulos De Adquisición De Datos, Análisis E Interfaz De Usuario”

UNIVERSIDAD TÉCNICA FEDERICO SANTA MARÍA

DEPARTAMENTO DE ELECTRÓNICA

VALPARAÍSO-CHILE

“SISTEMA DE MONITOREO DE GASES PARA PREVENCIÓN DE ESTADOS PELIGROSOS UTILIZANDO REDES DE SENSORES: MÓDULOS DE ADQUISICIÓN DE DATOS, ANÁLISIS E INTERFAZ DE USUARIO”

DAVID ANDRÉS BERRÍOS VILCHES

JORGE EDUARDO ULLOA CONTRERAS

MEMORIA DE TITULACIÓN PARA OPTAR AL TÍTULO DE INGENIERO CIVIL TELEMÁTICO

PROFESORES GUÍA Y CORREFERENTES: AGUSTÍN GONZÁLEZ / TOMÁS ARREDONDO

Agosto de 2010

AGRADECIMIENTOS

A nuestros profesores, familiares y amigos.

INDICE GENERAL RESUMEN ...... 8 ABSTRACT ...... 9 CAPÍTULO 1 ...... 9 1 INTRODUCCIÓN ...... 10 CAPÍTULO 2 ...... 12 2 ESTUDIO DEL ARTE...... 12 2.1 SOLUCIONES EXISTENTES ...... 12 2.1.1 DATALOGGER DE CONCENTRACIÓN DE GASES ...... 12 2.1.2 SISTEMAS DE MONITOREO DE GASES EN TIEMPO REAL ...... 13 2.2 TOMA Y ADQUISICIÓN DE DATOS ...... 13 2.2.1 ZIGBEE ETHERNET GATEWAY MESHNETICS ...... 14 2.2.2 ZIGBEE/ETHERNET CONVERTER (HT-CVT-GANN-E) ...... 15 2.2.1 CONVERSOR ETHERNET/ZIGBEE – ETHERNETDIRECT ...... 15 2.2.2 USO DE COORDINADOR Y CONVERSOR RS232/ETHERNET ...... 16 2.2.3 PROTOCOLO DE COMUNICACIÓN ...... 16 2.3 POSTGRESQL VS MYSQL VS MICROSOFT SQL SERVER ...... 16 2.4 PREDICTOR ...... 17 2.5 INTERFAZ WEB ...... 18 CAPÍTULO 3 ...... 21 3 DEFINICIÓN DE REQUERIMIENTOS Y ANÁLISIS DEL PROBLEMA ...... 21 3.1 REQUERIMIENTOS ...... 21 3.2 ANÁLISIS DEL PROBLEMA ...... 21 3.2.1 INGENIERÍA DE SOFTWARE ...... 21 3.2.2 VISTAS Y DESCRIPCIÓN ...... 23 CAPÍTULO 4 ...... 30 4 DISEÑO E IMPLEMENTACIÓN SOLUCIÓN PROPUESTA ...... 30 4.1 ARQUITECTURA DEL SISTEMA ...... 30 4.1.1 MÓDULO RED DE SENSORES ...... 30 4.1.2 MÓDULO ADQUISICIÓN DE DATOS...... 31 4.1.3 MODULO INTERFAZ ...... 31 4.1.4 EMULADOR DE DATOS DE UNA RED DE SENSORES ...... 31 4.2 RESTRICCIONES Y LÍMITES DEL DESARROLLO ...... 32

4.3 MÓDULO DE ADQUISICIÓN Y ANÁLISIS DE DATOS ...... 32 4.3.1 GATEWAY ...... 32 4.3.2 ADQUISIDOR, SOCKETS Y PROTOCOLO DESARROLLADO ...... 34 4.3.3 PREDICTOR ...... 36 4.3.4 ALMACENAMIENTO Y AGENTE ALERTAS ...... 39 4.3.5 BASE DE DATOS Y SERVIDORES ...... 41 4.3.6 CANAL ENCRIPTADO INTERFAZ SERVIDOR ...... 42 4.4 MÓDULO INTERFAZ SIG ...... 43 4.4.1 FLEX ...... 43 4.4.2 GOOGLEMAPS EN FLEX ...... 44 4.4.3 EXPORTAR ARCHIVOS AUTOCAD A KML ...... 46 4.4.4 COMUNICACIÓN FLEX Y BASE DE DATOS A TRAVÉS DE AMF ...... 47 4.4.5 ALERTAS ...... 48 4.4.6 RESULTADOS DE LA INTERFAZ ...... 48 CAPITULO 5 ...... 50 5 RESULTADOS: VERIFICACIÓN, EVALUACIÓN Y VALIDACIÓN DE LA SOLUCIÓN...... 50 5.1 VERIFICACIÓN...... 50 5.2 EVALUACIÓN Y VALIDACIÓN ...... 50 5.2.1 TIEMPO DE SERVICIO PREDICTOR Y SOBRECARGA DEL GATEWAY ...... 50 5.2.2 PREDICTOR ...... 51 5.2.3 TAMAÑO Y TIEMPO DE CARGA DEL PLANO AUTOCAD EN GOOGLE MAPS ...... 57 5.2.4 COMPARACIÓN COMUNICACIÓN AMF V/S XML ...... 58 CAPITULO 6 ...... 60 6 CONCLUSIONES ...... 60 7 REFERENCIAS ...... 63 8 ANEXOS ...... 66 8.1 ANEXO CASOS DE USO ...... 66 8.2 TABLAS TIEMPO DE CARGA GOOGLEMAPS ...... 71

INDICE FIGURAS Figura 1: a) Dispositivo Jandei, b) Dispositivo Dräger ...... 12

Figura 2: Gateway Meshnetics ...... 15

Figura 3: Convert (HT CVT Gann E) ...... 15

Figura 4: Conversor RS232/Ethernet ...... 16

Figura 5: funciones principales del software ...... 22

Figura 6: Diagrama casos de uso ...... 23

Figura 7: Vista general interfaz de usuario ...... 24

Figura 8: Vista monitoreo de gases en tiempo real ...... 25

Figura 9: Vista Monitoreo del estado de gases histórico ...... 26

Figura 10: Vista zonas peligrosas ...... 27

Figura 11: Vista consulta de alertas históricas ...... 28

Figura 12: Vista administración de nodos ...... 29

Figura 13: Diagrama arquitectura del sistema ...... 30

Figura 14: Configuración parámetros principales WIZ110SR ...... 33

Figura 15: Configuración carácter de corte para formación del paquete TCP ...... 33

Figura 16: Formato de mensaje desde Gateway al servidor ...... 34

Figura 17: Diagrama funcionamiento del procedimiento de guardado de datos ...... 35

Figura 18: Método de aprendizaje del predictor ...... 39

Figura 19: Diagrama del sistema de detección de alertas ...... 41

Figura 20: Modelo de base de datos ...... 42

Figura 21: diagrama túnel VPN utilizado ...... 43

Figura 22: Entorno de desarrollo Flex ...... 44

Figura 23: Configuración API Google Maps ...... 45

Figura 24: Ejemplo Google Maps sobre Flex ...... 46

Figura 25: Ejemplo mapa Autocad sobre Google Maps ...... 46

Figura 26: Paquete AMF a través de WIreshark ...... 47

Figura 27: Pantalla de ingreso de usuario ...... 48

Figura 28: Pantalla inicial de la interfaz ...... 49

Figura 29: Curvas predicción y muestras reales primera evaluación ...... 52

Figura 30: Curva error de predicción para primera evaluación ...... 53

Figura 31: Curvas predicción y muestras reales primera evaluación ...... 54

Figura 32: Curva error de predicción para segunda evaluación ...... 55

Figura 33: Curvas predicción y muestras reales tercera evaluación ...... 56

Figura 34: Curva error de predicción para tercera evaluación ...... 56

Figura 35: Tiempo retardo para planos en Google Maps ...... 58

Figura 36: Caso de uso determinar reas peligrosas ...... 66

Figura 37: Caso de uso borrar zona peligrosa ...... 66

Figura 38: Caso de uso borrar e identificar alertas ...... 67

Figura 39: Caso de uso monitorear nivel...... 67

Figura 40: Caso de uso ver predicción ...... 68

Figura 41: Caso de uso obtener gráficos ...... 68

Figura 42: Caso de uso generar alertas ...... 69

Figura 43: Caso de uso agregar nodo ...... 69

Figura 44: Caso de uso borrar nodo ...... 70

Figura 45: Caso de uso actualizar nodo ...... 70

INDICE DE TABLAS Tabla 1: Variables utilizadas en el algoritmo propuesto ...... 38

Tabla 2: Variables utilizadas en el módulo alertas ...... 40

Tabla 3: Especificaciones técnicas del servidor ...... 41

Tabla 4: Parámetros del predictor ...... 51

Tabla 5: Resultados obtenidos ...... 52

Tabla 6: Resultados obtenidos ...... 54

Tabla 7: Resultados obtenidos ...... 56

Tabla 8: Tabla con errores cuadráticos medios para las siguientes 5 predicciones ...... 57

Tabla 9: Tablas de comparación tiempo de respuesta AMF v/s XML ...... 59

Tabla 10: Tabla tiempo de carga Google Maps normal y con archivo de 10Mb ...... 71

Tabla 11: Tabla tiempo de carga Google Maps con archivo de 700Kb y con archivo de 600Kb . 71

Tabla 12: Tabla tiempo de carga Google Maps ara archivo de 200Kb ...... 72

SISTEMA DE MONITOREO DE GASES PARA PREVENCIÓN DE ESTADOS PELIGROSOS UTILIZANDO REDES DE SENSORES: MÓDULOS DE ADQUISICIÓN DE DATOS, ANÁLISIS E INTERFAZ DE USUARIO

DAVID ANDRÉS BERRÍOS VILCHES

JORGE EDUARDO ULLOA CONTRERAS

MEMORIA DE TITULACIÓN PARA OPTAR AL TÍTULO DE INGENIERO CIVIL TELEMÁTICO

PROFESORES GUÍA Y CORREFERENTES: AGUSTÍN GONZÁLEZ / TOMÁS ARREDONDO RESUMEN

El siguiente trabajo de memoria es el desarrollo de la parte de adquisición, análisis de datos e interfaz de usuario de un sistema de monitoreo de gases para prevención de estados peligrosos utilizando una red de sensores. Las principales ventajas de este sistema son: el uso de pronósticos de los niveles de concentración de los gases tales como el monóxido de carbono (CO) y el dióxido de nitrógeno (NO2), que permiten prevenir un potencial accidente por intoxicación, el uso de un servidor dedicado para el análisis de datos, la generación de alertas en tiempo real, que permite al supervisor del sistema tomar decisiones inmediatas y el uso de una interfaz Web que entrega al supervisor mayor movilidad por medio de un software SIG (sistema de información georeferenciada) cromático que facilita la ubicación de los lugares en donde puede ocurrir algún evento peligroso de concentración de gases y permite gestionar otros peligros asociados a los lugares de monitoreo.

Las soluciones tanto en el servidor como en la interfaz fueron probadas independientemente para luego ser integradas y verificadas. Luego el sistema se probó con éxito en el laboratorio con datos obtenidos de un emulador implementado por los memoristas, donde se verificó el cumplimiento de los requerimientos previamente acordados, así como las diferentes funcionalidades del proyecto. Por último, se evaluó algunas características del sistema como el tiempo de carga de los mapas y la sobrecarga del Gateway, para validar la solución propuesta.

SISTEMA DE MONITOREO DE GASES PARA PREVENCIÓN DE ESTADOS PELIGROSOS UTILIZANDO REDES DE SENSORES: MÓDULOS DE ADQUISICIÓN DE DATOS, ANÁLISIS E INTERFAZ DE USUARIO

DAVID ANDRÉS BERRÍOS VILCHES

JORGE EDUARDO ULLOA CONTRERAS

MEMORIA DE TITULACIÓN PARA OPTAR AL TÍTULO DE INGENIERO CIVIL TELEMÁTICO

PROFESORES GUÍA Y CORREFERENTES: AGUSTÍN GONZÁLEZ / TOMÁS ARREDONDO ABSTRACT The following memory work is the development of the acquisition, data analysis and user interface modules of a gases monitoring system for dangerous states prevention using wireless sensors networks. The main advantages of this system are the use of forecasts of the gases concentration levels such as carbon monoxide (CO) and nitrogen dioxide (NO2), which may prevent a potential intoxication accident, the use of a dedicated server for data analysis, the generation of real time alerts, allowing to the supervisor of the system take a immediately decision and the use of a Web user interface that gives to the supervisor greater mobility throw a chromatic GIS (Geographic information system) software that facility the find of the places where can occur some dangerous concentration of gases event and allow manage other risk associated to monitoring locations.

The solutions in the server and the interface were tested independently and then be integrated and verified. Then the system was successfully tested in the laboratory with data obtained from an emulator implemented by memoirists. This verified compliance with the requirements previously agreed and the different features of the project.

Finally, was evaluated some features of the system and the loading time of maps and gateway to evaluated proposed solution.

CAPÍTULO 1

1 INTRODUCCIÓN La exposición de una persona a la inhalación de material particulado (PM10) y gases tóxicos tales como: el monóxido de carbono (CO) y el dióxido de nitrógeno (NO2).Al ser emitidos por vehículos, maquinarias y procesos industriales puede causar daños irreparables en la salud del individuo e incluso la muerte en situaciones de exposición prolongada. Por otro lado, es un peligro inminente que gases explosivos tales como el metano (CH4) se encuentren en el ambiente de trabajo, poniendo en riesgo al personal, toda la maquinaria y la producción de una faena.

En industrias productivas como la minería, la intoxicación o muerte de una persona por la inhalación de algún gas tóxico puede significar, además de un conflicto ético, problemas para la empresa tales como: la detención de la producción por tiempos prolongados, la generación de sumarios internos, sanciones económicas, indemnizaciones por daños a la salud, entre otros. Por esta razón, existe en el mercado una gama de productos para la ventilación y extracción de aire que permiten mantener su calidad renovando el ambiente susceptible a la contaminación de gases, con el fin de cuidar la salud de los trabajadores. Además existen mascarillas, trompas y equipos de respiración que evitan que el personal inhale estos gases dañinos para la salud. Sin embargo, estos equipos no aseguran ni monitorean el estado actual del aire, de manera distribuida y por lo tanto, no se conoce con certeza dónde, cuándo y cuánto tiempo utilizarlos. Es por este motivo que se debe monitorear la concentración de los gases en ambientes industriales, convirtiendo el tema en una arista importante en materia de prevención de riesgos, y seguridad

Existen diferentes productos en el mercado que realizan el monitoreo del nivel de concentración de gases y pueden ser clasificados en dos grandes grupos según la manera de entregar los datos: aquellos sistemas que entregan los datos en tiempo real y aquellos sistemas que entregan los datos tiempo después a la realización del muestreo. Los sistemas que entregan los datos en tiempo real son sistemas compuestos de una central y sensores comunicados de manera cableada a través de estándares como RS232, RS485, RS422 y Ethernet [60]. Las centrales están compuestas por una pantalla o display que despliega los datos obtenidos, sin utilizar un software especializado como en [5] y [6]. Por otro lado, se encuentran los sistemas que no transmiten los datos en tiempo real. Estos sistemas por lo general poseen una memoria en donde los datos son almacenados y posteriormente descargados en alguna base de datos, mucho tiempo después de ser adquiridos. Muchos de estos dispositivos son equipos portátiles que obtienen los datos y permiten a los trabajadores que los

10 llevan consigo, conocer las concentraciones de gases en cualquier momento y de manera continua por medio de un display [1] y [2]. Además poseen alarmas sonoras que previenen a los trabajadores de concentraciones peligrosas de gases como el dióxido de azufre (SO2), el monóxido de carbono

(CO), el dióxido de carbono (CO2), el ozono (O3), entre otros. Sin embargo, en el estudio realizado no se encontró ningún producto o servicio de monitoreo de gases que fuera una solución integral de hardware y software, que resolviera el problema de obtener los datos en tiempo real de manera inalámbrica, junto con la generación de predicciones utilizando sistemas de información georeferenciada y tecnologías Web.

El presente trabajo tuvo como finalidad, desarrollar el módulo de adquisición y análisis de datos (desarrollados por David Berrios), y el interfaz gráfico Web del usuario (desarrollado por Jorge Ulloa) de un sistema de monitoreo de gases en tiempo real para la prevención de estados peligrosos utilizando redes de sensores: Específicamente, se desarrolló el sistema de adquisición de datos desde una red de sensores capaz de analizarlos y generar alertas tempranas, en conjunto con un sistema de predicción del nivel futuro de gases con el fin de advertir con anterioridad posibles estados peligrosos. Además se creó un software WEB que entrega mayor movilidad al supervisor, quien puede conocer el estado de los gases en la faena desde cualquier explorador Web con conexión a una red IP con acceso al servidor, identificando de manera rápida y gráfica todos los dispositivos que se encuentren monitoreando el estado de concentración de gases a través de un mapa cromático referenciado geográficamente, advirtiendo y alertando sobre posibles zonas contaminadas. Y por último el sistema permite definir de manera manual sectores peligrosos asociados a los lugares de monitoreo. Todas estas cualidades permiten: mantener una mejor supervisión del estado de concentración de gases, otorgar mayor movilidad para funcionarios y supervisores, obtener datos en tiempo real que permiten actuar inmediatamente en caso de una alerta, desplegar información histórica útil para la gestión de riesgos y aumentar la seguridad en los procesos industriales ya sea en el cuidado de personal, como en el cuidado de la producción e infraestructura.

El escrito está compuesto de 6 capítulos. El capítulo 1 es una introducción al problema de los gases tóxicos en la industria. El capítulo 2 es el estudio del arte sobre las soluciones actuales y las posibles tecnologías aplicables al trabajo. El capítulo 3 contiene el análisis del problema y los requisitos del sistema. El capítulo 4 contiene el diseño e implementación de la solución y restricciones impuestas. En este capítulo se explican las tecnologías utilizadas, algoritmos implementados, y configuraciones. El capítulo 5 es la verificación y validación de la solución. Por último, el capítulo 6 contiene las conclusiones, las referencias y los anexos.

CAPÍTULO 2

2 ESTUDIO DEL ARTE

2.1 SOLUCIONES EXISTENTES Existen diversos sistemas que en la actualidad entregan una solución a la problemática del monitoreo de gases. Entre éstos se pueden hacer dos grandes distinciones: aquellos que no entregan los datos en tiempo real y aquellos que solo funcionan como un datalogger [8].

2.1.1 DATALOGGER DE CONCENTRACIÓN DE GASES Los datos obtenidos por estos dispositivos deben ser descargados a un servidor central, mucho tiempo después de ser capturados. Algunos de estos dispositivos son portátiles y permiten a los trabajadores que los llevan consigo, conocer las concentraciones de gases en cualquier momento y de manera continua por medio de un display. Esta cualidad previene a los trabajadores, por medio de alarmas sonoras. Ejemplo de estos sistemas son los productos de Dräger [1] y Gas Alarm Systems LTD [2]. En el caso de Dräger hay portátiles como el X-am 7000, como se aprecia en la figura 1 b) que pueden detectar hasta 5 tipos de gases diferentes y que además poseen alarmas para diferentes niveles. La gran desventaja de estos equipos es que no permiten que el supervisor conozca los estados peligrosos que ocurren en la faena en un instante dado para poder tomar acciones al respecto.

Figura 1: a) Dispositivo Jandei, b) Dispositivo Dräger

2.1.2 SISTEMAS DE MONITOREO DE GASES EN TIEMPO REAL Estos dispositivos envían continuamente los datos obtenidos de los diferentes sensores distribuidos a un servidor central, permitiendo que el encargado de supervisión de riesgos mantenga mayor información, agilizando la toma de decisiones y actividades preventivas al momento en que ocurre algún problema. En general, estos sistemas de monitoreo cuentan con un panel central al cual son anexados de manera cableada los diferentes sensores, los cuales transmiten todos los datos recolectados utilizando los protocolos de comunicación seriales RS232, RS485, RS422, Ethernet [60], entre otros; y por lo general son mostrados por medio de una pantalla básica que despliega los valores medidos sin el uso de un software especializado. En algunos de estos sistemas se integra una pequeña impresora la que permite imprimir los reportes de las muestras. Ejemplos de estos sistemas son los productos de las empresas Jandei [4], Pure Air Monitoring [5] y Net Safety [6].

En referencia al software, existen muchos trabajos académicos y empresas que han utilizado programas para sistemas del tipo PLC con aplicaciones basadas en software como LabView [7] y Matlab [8], [9] y [10], que a través de interfaces gráficas intuitivas permiten crear programas de medición. Por lo general estos lenguajes permiten obtener de manera fácil los datos a través de la comunicación analógica para ser interpretados por el software y mostrados con una gráfica que simula los elementos de la vida real. Sin embargo estos lenguajes son orientados al tipo de soluciones PLC y adquisición analógica de datos, y pueden ser utilizados para el monitoreo de gases en la industria, con la desventaja de que no son orientado a ser sistemas Web y son programas comerciales con costos elevados.

Por otro lado, también existen programas para el monitoreo creados en entornos como Visual Basic tales como los que desarrolló Parijat Controlware Inc [11] y Codel [12], con sistemas de reportes, y gráficas de datos en tiempo real. Muchos de estos programas permiten la exportación de los datos a plantillas Excel y formato PDF. Sin embargo, dependen del sistema operativo en el que funcionen, y no aprovechan las ventajas de la nueva generación de tecnologías de la información.

Ninguna de las soluciones antes mencionadas provee una solución integral de hardware y software que permita al cliente poder ver en tiempo real el conjunto de sensores distribuidos dentro de sus instalaciones de manera gráfica, con la posibilidad de referenciar geográficamente los datos y que además permita un acceso remoto desde cualquier sistema operativo que posea un navegador Web.

2.2 TOMA Y ADQUISICIÓN DE DATOS Actualmente, una alternativa para la adquisición de datos son las redes de sensores inalámbricas, las cuales están compuestas por un conjunto de nodos sensores con comunicación inalámbrica, que

13 permiten generar redes sin infraestructura física preestablecida ni administración central [35]. Estas redes poseen beneficios tales como: un bajo consumo energético, la posibilidad de formar topologías dinámicas y un bajo costo de producción. Esta materia y parte del sistema será abordada en la memoria de Ingeniería Civil Electrónica de Alejandro Rivera Astete, motivo por el cual no será ahondada en este estudio del arte, sin embargo es parte principal del funcionamiento del sistema en su totalidad.

Dado el uso de redes de sensores, se requiere de algún sistema que permita transmitir los datos obtenidos por los sensores a un servidor central a través de Internet. Para esto existen diversos dispositivos en el mercado que convierten los datos muestreados desde una red de sensores ZigBee a Ethernet. A continuación se presentan algunas alternativas y equipos que permiten tal funcionalidad.

2.2.1 ZIGBEE ETHERNET GATEWAY MESHNETICS MeshNetics lanzó durante el 2007 el ZigBit Gateway ZigBee-Ethernet [50]. Está basado en el módulo Atmel para ZigBee/802.15.4 el cual incluye un microcontrolador ATmega 128 y un transceptor Atmel AT86RF230 RF [49], funcionando como puente entre la red inalámbrica y una red IP.

Características:

 Banda de operación: 2.400 - 2.483 [GHz]  Antena: 2.4 [GHz] (external)  Ethernet: 10/100 [Mbps]  Link Budget: 104 [dB]  Consumo de corriente RF: RX: 19 [mA]; TX: 18 [mA]  Temperatura de operación: -40[°C] a +70[°C]  Dimensiones: 122 x 37 x 120 [mm]  Compatible con IEEE802.15.4/ZigBee  Alta sensibilidad RF (104 [dBm])  Soporte mediante comandos  IP65  Permite extender la red ZigBee mediante cable.

Figura 2: Gateway Meshnetics

2.2.2 ZIGBEE/ETHERNET CONVERTER (HT-CVT-GANN-E) Este producto propietario de Hornetone permite convertir los datos de la red Inalámbrica Zigbee a Ethernet utilizando un puerto con velocidad 10/100 autoadaptables, permitiendo comunicación bidireccional. Además el equipo es configurable mediante una interfaz HTTP. El voltaje de entrada es de 9[V] a 24[V]. Sus dimensiones son 80x66.2x30mm. En su página principal no entregan mayor información acerca del tipo de hardware interno usado. Sin embargo, Hornetone, utiliza en sus módulos y equipos el SoC EM250 de Ember [51] o CC2430 de Texas Instrument [52].

Figura 3: Convert (HT CVT Gann E)

2.2.1 CONVERSOR ETHERNET/ZIGBEE – ETHERNETDIRECT Ethernet Direct ha desarrollado soluciones ZigBee denominadas Zebra [36]. Por ejemplo los modelos ZUZ-110 y ZUZ-111 permiten convertir de ZigBee a RS232/285 y Ethernet. Algo destacable de esta línea de productos es la gran variedad de opciones que implementan Ethernet y ZigBee.

2.2.2 USO DE COORDINADOR Y CONVERSOR RS232/ETHERNET WIZ110SR [37] es un módulo Gateway que convierte el protocolo RS-232 a Ethernet. Este dispositivo se conecta a un servidor a través de un socket UDP o TCP, y envía los caracteres recibidos por un puerto serial. El software disponible facilita la tarea de configuración del equipo.

Para implementar este equipo se requiere configurar el coordinador Zigbee para reenviar a través de RS232 los datos recibidos de la red de sensores. Sin embargo este desarrollo es tarea del encargado de la red de sensores, lo cual no está incluido en este trabajo de memoria, por lo cual, los memoristas solo se dedicarán a configurar el conversor.

Figura 4: Conversor RS232/Ethernet

2.2.3 PROTOCOLO DE COMUNICACIÓN Una vez que los datos son enviados al servidor, éste debe poder recibirlos e interpretarlos. Para tal objetivo, se puede utilizar cualquier protocolo de mensajes de capa aplicación sobre el socket de comunicación UDP o TCP como por ejemplo el protocolo HTTP, el cual consta de cabeceras y tags especiales que en mutuo acuerdo entienden tanto cliente como servidor [61].

Se optó por programar un protocolo de comunicación simple con el objetivo de adecuarse a las condiciones mínimas necesarias, sin malgastar recursos innecesariamente.

2.3 POSTGRESQL VS MYSQL VS MICROSOFT SQL SERVER Existen distintas pruebas de rendimiento [53] [54] [55] donde se evalúa el comportamiento de estos motores de base de datos. Sin embargo, dado el sin número de escenarios posibles, el comportamiento de estos se torna variable [39].

Pese a ello, los expertos concuerdan en que MYSQL [40] es un motor veloz, gratuito, multiplataforma, que está fuertemente masificado y para el cual existe una amplia cantidad de aplicaciones de gestión. Sin embargo, sin prácticas que optimicen su funcionamiento, es lento y

16 poco robusto para aplicaciones con gran flujo de transacciones y con tablas con una gran cantidad de filas [63].

Por otro lado POSTGRESQL es considerado robusto, escalable, con una eficiencia lineal para grandes flujos de transacciones, que permite soportar una gran cantidad de consultas concurrentes, además de ser gratuito y multiplataforma. Sin embargo, es más lento que MYSQL y consume más recursos que MYSQL Y SQL SERVER, en escenarios con poca concurrencia [41] [56].

Finalmente MICROSOFT SQL SERVER es un motor considerado, incluso por los seguidores del GNU, la mejor creación de MICROSOFT. Tiene una gran cantidad de funcionalidades, soporta procedimientos almacenados (al igual POSTGRESS), cuenta con potentes herramientas de administración con una interfaz orientada a la facilidad de uso, es definitivamente más rápido que POSTGRESSQL [57]. Sin embargo, consume una gran cantidad de recursos, tiene la desventaja de ser comercial y solo puede ser instalado en sistemas operativos MICROSOFT WINDOWS. [42].

2.4 PREDICTOR Un modelo de predicción requiere obtener y analizar los datos ingresados durante la historia de muestreo, buscando una relación entre las muestras pasadas y las muestras futuras con el fin de predecir un estado peligroso. Un modelo de predicción puede estar basado en algoritmos matemáticos o heurísticos debiendo utilizar una ventana de muestras históricas. Puede ser implementado como un servicio independiente del software de adquisición de datos que analiza directamente la base de datos, o simplemente como un método de éste software adquisidor.

Un método utilizado es Logistic regression [43], técnica en la que se predicen valores desconocidos de una variable discreta basándose en los valores conocidos de una o más variables continuas o discretas. El objetivo es determinar la probabilidad de ocurrencia de un evento para predecirlo con mayor certeza.

También se pueden utilizar redes neuronales (ANN) [45], método que representa un paradigma de aprendizaje y procesamiento de los datos inspirado en la manera de funcionar del sistema nervioso. Las ANN consisten básicamente en un entramado de conexiones entre neuronas que conforman una red colaborando entre sí para producir un estímulo de salida, análogo a lo que sucede realmente en nuestro sistema nervioso.

También se puede genera un modelo predictivo utilizando series de tiempo [44], que consiste básicamente en coeficientes que ponderan las muestras históricas para predecir las siguientes

17 muestras. En la memoria se utiliza este modelo y en la sección 4.3.3.1 se explican las razones de la elección.

2.5 INTERFAZ WEB Para poder ver los datos previamente adquiridos existen los sistemas de información georeferenciada SIG [14], que permiten ubicar datos de manera espacial, sobre mapas y planos cartográficos digitales, y resolver problemas de localización, condición, tendencias, rutas y modelos (simulaciones), lo que hace a estos sistemas de amplio uso en diferentes áreas.

La representación de los datos en un SIG, puede ser realizada de dos maneras: de forma vectorial o de forma de raster o malla. La ventaja del primero radica en que la manera vectorial mantiene las características geométricas de las figuras, sin embargo es más complicado de manejar. Un cuadro comparativo puede obtenerse de estos dos métodos en [15]. Existe un abanico grande de software SIG disponible en la red, entre estos se puede encontrar algunas aplicaciones comerciales como ArcGIS [62] y Mapinfo y otros libres como gvSIG, GeoServer, Generic y Mapping Tools [14]. No todos ellos poseen las mismas cualidades ni pueden ser implementados en todos los sistemas operativos.

Una tendencia actual es el uso de SIG en la Web. Esto permite el acceso remoto a los datos y la portabilidad del sistema, ya que el software funciona sobre los exploradores Web independiente del sistema operativo. Casos famosos de los Web-SIG son los servicios ampliamente conocidos de Google Maps [16] y Google Earth [17] y otros softwares de versiones comerciales como Skyline Software [18] y la gratuita Worl Wind [19]. A diferencia de los dos últimos, las soluciones Google poseen grandes comunidades de desarrollo y en internet se puede encontrar muchos tutoriales, manuales y código al respecto. Es importante destacar que todos ellos funcionan bajo el paradigma cliente-servidor.

Para que estos sistemas funcionen se requiere de un estándar de comunicación adecuado que permita ver a través de imágenes los datos geo referenciados enviados por el servidor por medio de un explorador Web. Un lenguaje muy característico es el XML [20], lenguaje creado por el W3C que utiliza las etiquetas para crear diferentes estructuras para diferentes usos. De este lenguaje nacen otros como GML (Geographic Markup Language) [21] [22] [23] y KML (Keyhole Markup Language) [24], utilizados para la comunicación entre servidor y cliente para el intercambio de datos. La principal idea detrás de este desarrollo es poder transmitir por medio de etiquetas, características tales como: el relieve, las coordenadas, las características geométricas y en general cualquier dato de importancia para el despliegue gráfico.

Es importante destacar que por la forma de funcionar de la estructura cliente-servidor en los exploradores Web, se requiere de algún tipo de tecnología que permita solo recargar los datos de la página de navegación que corresponden al SIG y no todo el sitio que lo compone, dado que si no se hiciera de esta manera, la navegabilidad sería engorrosa cada vez que se actualizan los datos de mapas y planos. Para realizar esto existe la tecnología AJAX, (JavaScript asíncrono y XML) [25] [26]. AJAX es una técnica de desarrollo Web para crear aplicaciones interactivas o RIA (Rich Internet Applications). Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador de los usuarios mientras se mantiene la comunicación asíncrona con el servidor en segundo plano. De esta forma es posible realizar cambios sobre las páginas sin necesidad de recargarlas completamente, lo que significa aumentar la interactividad, velocidad y usabilidad en las aplicaciones.

Bajo el mismo concepto RIA se encuentra Flex [27]. Basado en la plataforma Flash, Flex es un framework de código abierto gratuito para la creación y el mantenimiento de aplicaciones Web expresivas. Su objetivo es permitir construir rápida y fácilmente aplicaciones Web en la capa de presentación. Flex tiene varios componentes y características que aportan funcionalidades tales como: Servicios Web, objetos remotos, arrastrar y soltar, columnas ordenables, gráficas, efectos de animación y otras interacciones simples. El cliente solo carga la aplicación una vez, mejorando así el flujo de datos frente a aplicaciones basadas en HTML las cuales requieren de ejecutar código en el servidor para cada acción. Google Maps ha desarrollado un API que permite utilizar sus funcionalidades sobre Flex [28]. Como opciones para Flex de Adobe, existen frameworks como Silverlight de Microsoft y JavaFX de Sun. En especial, la gran cantidad de tutoriales, manuales y ayuda para Flex, hace que éste sea una opción más rápida y fácil para crear aplicaciones.

Para poder desarrollar un sistema Web se requiere elegir un lenguaje de programación que maneje la capa lógica o de negocio. La base, en un comienzo, de las páginas Web fue HTML, sin embargo con el tiempo la tecnología fue evolucionando a lenguajes como PHP y Perl que permiten realizar funciones y consultas a base de datos creando sistemas más completos. El problema de estos sistemas es que mezclan las capas de presentación y de negocios en una sola lo que mezcla al mismo tiempo los trabajos de diseño y programación a la vez que se crean códigos más complejos, menos escalables, haciendo la labor de mantención más tediosa. Actualmente las aplicaciones Web se están desarrollando en los llamado modelos multi-capas (tres y cuatro capas) [29] [30] los que permiten separar la capa de presentación (encargada de la interfaz gráfica), con la capa lógica o de negocios (donde se ejecutan las funciones y programas) y la capa de datos (en donde residen todos los datos). La ventaja principal de este patrón es que el desarrollo se puede llevar a cabo en varios niveles y, en caso de que ocurra algún cambio, sólo se modifica el nivel requerido sin tener que

19 revisar todo el código mezclado. Además se crean grupos a cargo y acordes a cada capa trabajando en abstracción con los otros grupos y comunicándose por APIs en común acuerdo. Frameworks como .NET y J2EE permiten trabajar bajo el modelo de tres capas y poseen herramientas que facilitan la utilización de estos métodos. En especial por la cercanía y restricciones impuestas sobre el trabajo se utilizará .NET el cual facilita el desarrollo en conjunto con el entorno gráfico de programación Visual Studio 2008, el cual permite generar rápidamente soluciones que mezclan de manera intuitiva la base de datos Microsoft SQL 2008. Por último existe muchos manuales e información disponible en el sitio MSDN de Microsoft [58].

El uso de mapas y planos de la mina en la interfaz fue uno de los principales objetivo de esta memoria. En general, un programa muy utilizado para crear planos en edificaciones y construcciones es Autocad [31]. Como todos los programas de DAC (Diseño asistido por computadora o CAD en inglés), procesa imágenes de tipo vectorial, aunque admite incorporar archivos de tipo fotográfico o mapa de bits, donde se dibujan figuras básicas o primitivas (líneas, arcos, rectángulos, textos, etc.), y mediante herramientas de edición se crean gráficos más complejos. El programa permite organizar los objetos por medio de capas o estratos, ordenando el dibujo en partes independientes con diferente color y grafismo. La extensión DWG es el conocido formato de los archivos generados por AutoCAD. Está licenciado por Autodesk y se le considera casi un estándar, sin embargo incluye innumerables versiones que no son completamente compatibles entre sí, y cuyas especificaciones nunca se han publicado de forma oficial. Dado el popular uso de AutoCAD, para el desarrollo del trabajo se utilizó AutoCAD 2009.

El problema de las diferentes e incompatibles versiones de DWG tiene algunas alternativas de solución como EveryDWG File Converter [32] y A9Converter [33]. Por último, en el estudio realizado se encontró una extensión de AutoCAD para Google Earth que permite exportar a KML archivos de Autocad [34].

CAPÍTULO 3

3 DEFINICIÓN DE REQUERIMIENTOS Y ANÁLISIS DEL PROBLEMA

3.1 REQUERIMIENTOS Se estableció los requerimientos mínimos para que el sistema funcione en su totalidad

1. Conexión a red IP que permita el acceso a la plataforma Web y el envío de datos al servidor. 2. Hardware para recolección de datos (memoria de Alejandro Rivera Astete). 3. Conectividad de red entre Gateway y adquisidor. 4. Acceso a energía eléctrica para el Gateway. 5. Uso de servidor dedicado. 6. Planos DWG del lugar a monitorear. 7. Explorador Web (se recomienda Firefox). 8. Flash Player 10 o superior.

3.2 ANÁLISIS DEL PROBLEMA

3.2.1 INGENIERÍA DE SOFTWARE Se realizó una planificación general extrayendo las funciones principales e interacciones entre actores, ordenando los requerimientos del sistema.

3.2.1.1 CASOS DE USOS El caso de uso es un documento que describe los casos de utilización del sistema con tal de poder entender el funcionamiento que tendrá. En los anexos se encuentran los casos de uso realizados para el sistema.

3.2.1.2 ACTORES Supervisor: Persona encargada de ver el sistema y monitorear a través de la interfaz Administrador: Persona encargada de configurar el sistema.

3.2.1.3 DECLARACIÓN GENERAL El propósito de este proyecto es crear un sistema software para el monitoreo y supervisión del estado de gases peligrosos en tiempo real.

3.2.1.4 FUNCIONES DEL SISTEMA Función Categoría Ver las concentraciones de todos los gases tóxicos por nodo y sensor Evidente Obtener promedios por nivel(por sensores, por tiempo) Evidente Guardar los datos de cada registro Oculto Actualizar las concentraciones en cada muestra Oculto Obtener datos historicos Evidente Estadísticas: Nodos con mayores concen., promedios, tiempo, etc Evidente Ver la predicción de estados peligrosos para todos los sensores Evidente Encriptar datos entre cliente y servidor Oculto Insertar nuevos nodos sensores Evidente Actualizar y guardar el estado de la baterias de los sensores Oculto Configurar parametros de concentración peligrosas de gases Oculto Determinar zonas peligrosas Evidente Mostrar alertas en tiempo real Evidente Identificar alertas Evidente Exportar datos de alertas, con fecha, valor medición e id Evidente

Figura 5: funciones principales del software

El análisis fue hecho para el sistema completamente terminado. El alcance de esta memoria no incluyó el desarrollo de las funciones estadísticas, ni exportar los datos a otros formatos.

3.2.1.5 DIAGRAMA CASOS DE USO

Figura 6: Diagrama casos de uso

3.2.2 VISTAS Y DESCRIPCIÓN Para desarrollar la interfaz se definió inicialmente las funcionalidades más importantes que debía tener el programa. Se determinó que las funciones principales de la interfaz son el poder monitorear el nivel de concentración de los gases actuales, pasados y futuros, junto con alertar al usuario sobre estados peligrosos, gestionar áreas peligrosas y la administración de las tareas de mantenimientos de la red como insertar nuevos nodos.

Para la interfaz se creó las vistas iniciales del sistema con una breve descripción de las funciones más importantes como se describe a continuación.

3.2.2.1 VISTA GENERAL

Figura 7: Vista general interfaz de usuario

La vista general se puede separar en cinco secciones enumeradas en la figura 7:

1. Cabecera: En esta sección aparece el nombre del sistema, la opción de cerrar sesión y los datos principales del usuario que está utilizando el sistema. 2. Menú explorador: Esta sección permite navegar por todas las opciones del programa como: a. Estado de gases actual b. Estado de gases pasado c. Definir zona peligrosa d. Alertas e. Reportes y estadísticas f. Administrar nodos. 3. Mapa: Esta sección contiene el sistema SIG que permite referenciar geográficamente los nodos instalados. 4. Pie de página: Espacio para escribir enlaces a otras páginas e información general útil para el cliente. 5. PopUp Alerta: Este PopUp aparece cada vez que ocurre una alerta debido a un nivel alto de concentración de gas.

3.2.2.2 ESTADO DE GASES

Figura 8: Vista monitoreo de gases en tiempo real

En esta vista, se ve el estado del nivel de concentración de los diferentes gases en un nivel o sector, por medio de marcadores cromáticos y referenciados geográficamente en el mapa derecho de la vista. Para indicar el nivel de concentración de gas se utilizan tres diferentes colores:

 Verde: Nivel de concentración del gas no peligroso.  Amarillo: Advertencia nivel concentración de gases medio, preocupante.  Rojo: Nivel de concentración peligroso, riesgo alto.

Luego se puede explicar la vista por medio de los puntos indicados en la figura 8.

1. Menú selector de gas: Este es un menú compuesto por botones de radio que permite seleccionar el tipo de gas que está siendo monitoreado y que se quiere ver en el mapa. 2. Selector de nivel: Permite seleccionar el nivel que será mostrado en el mapa. 3. Indicador de posición: Para mostrar la posición del nodo seleccionado con el cursor del mouse. 4. Últimas muestras de gases: Permite ver las últimas muestras y sus respectivos pronósticos por medio de un gráfico para el nodo seleccionado con el cursor

3.2.2.3 ESTADO DE GASES PASADO

Figura 9: Vista Monitoreo del estado de gases histórico

Esta vista permite seleccionar el estado de concentración de gases para fechas pasadas para todos los niveles. A diferencia de la vista anterior, posee tres campos de selección de fecha señalizados en la figura 9:

1. Selector de fecha: Permite seleccionar una fecha con hora y minuto de las muestras específicas para un nivel.

El usuario ingresa fecha y hora del monitoreo y el sistema busca las muestras que coincidan con la fecha y hora más cercana.

3.2.2.4 DEFINIR ZONA PELIGROSA

Figura 10: Vista zonas peligrosas

Esta vista permite determinar y ver las zonas peligrosas anexadas a un nodo. En caso de que ocurra un accidente o exista algún peligro, éste puede ser asociado al nodo más cercano para que así el sistema advierta al supervisor si alguien se aproxima al sector en el caso de conocer la posición del trabajador. A continuación se explica la figura 10 que contiene la vista:

1. Ingreso zona peligrosa: Este recuadro aparece al hacer clic sobre un nodo en la zona del mapa. En este recuadro aparece el id del nodo, su latitud, longitud, una descripción del peligro, la fecha cuando fue activado el peligro y un botón de radio que indica si la alerta aún es válida. Por último posee el botón de guardar para grabar los datos en el sistema o cancelar en caso contrario. 2. El color rojizo alrededor del nodo indica que el nodo tiene asociado algún peligro.

3.2.2.5 ALERTAS

Figura 11: Vista consulta de alertas históricas

Esta vista permite consultar sobre alertas anteriores según las opciones seleccionadas. Al presionar el botón consultar se carga automáticamente un tabla con los datos solicitados. Importante es destacar que el mapa en este momento se encuentra monitoreando el estado actual de gases. A continuación se explica la figura 11 que contiene la vista:

1. Selección de nivel: las opciones para mostrar las alertas para niveles son: a. Todo los niveles: mostrar las alertas de todos los niveles b. Ultimas alertas: mostrar las últimas alertas independientes del nivel c. Por nivel: muestra las alertas del nivel seleccionado. 2. Tipo de alertas: Permite seleccionar el tipo de alerta a mostrar: a. Alertas por muestra: permite ver aquellas alertas producto del estado de gas peligroso. b. Por zona peligrosa: permite ver las alertas producto de zonas peligrosas. c. Por predicción: muestras las alertas provenientes de una predicción. 3. Selección de periodo: Permite seleccionar la ventana de tiempo para la cual se desea consultar las alertas.

3.2.2.6 ADMINISTRAR NODOS

Figura 12: Vista administración de nodos

En esta vista se reagrupa el orden general donde el mapa aparece al centro de la pantalla y un nuevo menú de administración se sitúa a la derecha de la vista como se puede ver en la figura 12.

1. Menú de administración de nodos: Este menú permite navegar a través de las diferentes opciones de configuración de un nodo: a. Seleccionar nivel: opción para seleccionar el nivel en el cual se realiza los cambios a los nodos. b. Ingresar nodo: En esta sección se activa el modo de ingreso de un nodo. Para insertar un nuevo nodo, se debe hacer clic en el lugar donde se quiere insertar en el mapa central. c. Ingresar sensor: Se selecciona un nodo para luego agregar un nuevo sensor. d. Modificar nodo: Opción para poder modificar la posición de un nodo en base de datos. Solo se debe hacer clic sobre el nodo y moverlo a la nueva posición. e. Eliminar nodo: de una lista de nodos se selecciona el que se desea borrar del sistema. Una vez obtenidos los requerimientos y planificado el desarrollo mediante técnicas de ingeniería de software se procedió a la programación de los distintos módulos.

CAPÍTULO 4

4 DISEÑO E IMPLEMENTACIÓN SOLUCIÓN PROPUESTA

4.1 ARQUITECTURA DEL SISTEMA El sistema implementado está constituido por tres módulos tal como se aprecia en la figura 13.

Figura 13: Diagrama arquitectura del sistema

4.1.1 MÓDULO RED DE SENSORES Este módulo se compone por la red de nodos sensores basados en el estándar 802.15.4 para redes WPAN (Wireless Personal Área Network).y en el estándar Zigbee de más alto nivel. Los dispositivos transceptores que utilizan estos estándares tienen las características de tener dos estados de funcionamiento: estado despierto cuando transmiten o reciben información y estado dormido en el caso que no se transmitan ni reciban datos

Las ventajas de utilizar estas tecnologías:

1. Bajo consumo Energético(CC2430 de Texas Instrument) [59] a. Consumo recepción: 27 [mA] b. Consumo transmisión: 25 [mA] c. Consumo en estado dormido: 0,9 [µA]

2. Posibilidad de utilizar topologías malla, estrella y árbol. 3. Gran movilidad al tratarse de dispositivos de tamaño pequeño. 4. Los nodos utilizan baterías por cual no requieren estar conectados a la red eléctrica.

A estos nodos pueden ser unidos diferentes tipos de sensores: humedad, temperatura, luminosidad, consumo de corriente, de acercamiento y de gases entre otros. En este trabajo los nodos son conectados a sensores pasivos de gases de CO y NO2.

Para este trabajo, la red de sensores se emuló a través de un software, con el fin de poder probar y realizar las pruebas del sistema.

4.1.2 MÓDULO ADQUISICIÓN DE DATOS Este módulo lo compone un servidor encargado de recibir los datos enviados por la red inalámbrica de sensores, procesarlos, guardarlos en base de datos y generar las alertas necesarias en el caso que los niveles de gases superen los umbrales máximos de concentración. Además este módulo implementa un sistema de pronóstico de los niveles de concentración de gases.

4.1.3 MODULO INTERFAZ Este módulo se encarga de desplegar los datos y mostrar la información procesada por el adquisidor. Su principal característica es el implementar un servicio de geo-referenciación Web, en el cual se puede observar los diferentes niveles de concentración de gases, las predicciones de los niveles, las alertas generadas y permite configurar parámetros de funcionamiento del sistema

4.1.4 EMULADOR DE DATOS DE UNA RED DE SENSORES Para realizar las pruebas del sistema, se elaboró un programa emulador de datos de una red WSN programado en el lenguaje C# de Microsoft sobre el entorno de programación Microsoft Visual Studio 2008.

Para generar una muestra emulada para un sensor, se utilizó una variable aleatoria Gaussiana con media cero la cual se suma a la muestra anterior como se representa en la ecuación (1), donde es la nueva muestra emulada, es la anterior y es la variable aleatoria.

(1)

Se puede configurar el número de nodos que envían datos y el tiempo de arribo entre paquetes. Además para cada sensor creado se utilizó una variable aleatoria con semillas distintas.

4.2 RESTRICCIONES Y LÍMITES DEL DESARROLLO Para mayor organización y orden en el desarrollo del trabajo se estableció las restricciones y límites de la memoria.

1. Utilización de tecnologías Microsoft en el servidor, adquisidor y base de datos, con excepción en casos justificados. 2. Sistema escalable para futuras mejoras: a. Protocolo de comunicación genérico para integrar diferentes sensores. b. Sistema de alertas dinámico e independiente del tipo de sensor. 3. El monitoreo de gases solo se consigue cuando los sensores se encuentran en base de datos. 4. El sistema de pronóstico depende de la cobertura de la red de sensores. 5. No se consideró ataques maliciosos en la comunicación de datos entre Gateway y adquisidor de datos. 6. No se consideró interpolación entre sensores, dado que requiere de modelos matemáticos y el uso de sensores de otras variables. 7. Dadas las características críticas del problema, el servidor Web y de base de datos solo atiende una red WSN.

4.3 MÓDULO DE ADQUISICIÓN Y ANÁLISIS DE DATOS

4.3.1 GATEWAY El Gateway es el dispositivo encargado de recibir los datos de la red de sensores y convertirlos de una red bajo el estándar Zigbee a una red bajo el estándar Ethernet, con el fin de almacenarlos y procesarlos en un servidor configurado especialmente para la recepción de estos datos. Este equipo está compuesto por el coordinador de red Zigbee, un módulo transceptor RS-232 y un conversor RS-232 /Ethernet.

Para esta memoria se utilizó un emulador de datos de la red de sensores, conectado mediante el puerto serial al conversor RS-232/Ethernet, reemplazando el coordinador por un PC.

4.3.1.1 CONFIGURACIÓN CONVERSOR/ETHERNET El coordinador entrega un mensaje con un formato predefinido y un carácter de término „~‟ que indica donde cortar el flujo de caracteres desde el puerto RS232 y formar el paquete TCP para enviarlo a Ethernet. Como se aprecia en la figura 14, se configuró los datos de red del conversor tales como: IP, mascara de subred, puerta de enlace, el servidor donde se envían los datos y el

32 puerto de comunicación a utilizar. Además, dada la configuración del sistema, se definió el modo de operación como cliente dado que solo se transmitió datos desde la red al servidor y no viceversa.

Figura 14: Configuración parámetros principales WIZ110SR

La configuración del puerto RS232 es restringida a las necesidades del coordinador, para el caso de la memoria se fijó la velocidad en 115.200 baudios, 8 Bits por dato, sin paridad, un bit de parada y sin control de flujo, configurando los campos que se aprecian en la figura 14.

Finalmente, como se aprecia en la figura 15, en el panel “Option” se especificó las condiciones de corte de datos para formar el paquete TCP que es enviado al servidor, fijando como corte el carácter de termino 7E, equivalente al carácter ‟~‟.

Figura 15: Configuración carácter de corte para formación del paquete TCP

4.3.2 ADQUISIDOR, SOCKETS Y PROTOCOLO DESARROLLADO

:1:2000:3000:4000:5000:~

Figura 16: Formato de mensaje desde Gateway al servidor

4.3.2.1 PROTOCOLO Cada nodo envía un único mensaje con las distintas muestras de los sensores que tiene instalado. El primer campo entre los caracteres „:‟, es el id único del nodo, los siguientes campos son las muestras de los distintos sensores anexados al nodo. A modo de ejemplo, el mensaje descrito en la figura 16 se interpreta de la siguiente forma: el nodo 0001, midió 2000, 3000, 4000, 5000 en el primer, segundo, tercer y cuarto sensor respectivamente. El tamaño entre „:‟ no es de largo fijo lo que permite mayor flexibilidad al momento de agregar nuevos sensores al sistema.

4.3.2.2 INTERPRETACIÓN EN BASE DE DATOS El primer campo es el id_nodo del nodo y equivale a la clave primaria del nodo en base de datos. Los siguientes datos de muestras 2000, 3000, 4000, y 5000 son interpretados utilizando el campo referencia en la tabla sensores, por ejemplo, el sensor con referencia identificador 0, equivale a la muestra 2000, el de referencia 1 a la muestra 3000 siguiendo el ejemplo anterior. Esto permite hacer genérica la plataforma de monitoreo, dándole mayor libertad al desarrollador de la red de sensores, pudiendo enviar cualquier tipo de dato de cualquier tipo de sensor en cualquier campo del protocolo.

Si el desarrollador o usuario quisiera conocer el tipo de sensor del nodo 1 que está en el último casillero, la sentencia SQL sería “Select tipo from sensores where referencia = 3 and id_nodo=1”.

4.3.2.3 ADQUIRIDOR, SOCKET Y PROGRAMACIÓN OBJETUAL En el desarrollo de la tesis, la clase principal del módulo de información está encargada de recibir los datos del Gateway para posteriormente coordinar el registro, realizar la predicción de datos y generar las alertas. Para estás funciones se crearon dos clases:

 Predictor.cs: encargado de generar predicciones y modelos de reaprendizaje.  BasedeDatos.cs: encargado de registrar/leer de la base de datos y generar alertas.

Inicialmente la clase principal establece los parámetros para el constructor de basedeDatos.cs y predictor.cs. Luego se abre un socket TCP en el puerto 1001 y cuando un cliente se conecta, inicia

34 el trabajo de adquisición, en este momento llama al método BasedeDatos.LeerBaseDeDatos() y por cada sensor en base de datos guardado se crea un predictor y se almacena en memoria RAM los números identificadores de sensores, de nodos y sus parámetros. Es importante destacar que dada las condiciones de riesgo y responsabilidad en materia de seguridad minera, se utiliza el protocolo TCP y no UDP.

Posteriormente, se comienzan a recibir los datos desde el Gateway. La clase principal realiza el método “Split („:‟) para distinguir los distintos campos del mensaje. En el primer campo, se extrae el identificador único del nodo y se compara con los datos cargados en RAM, Si no existe, llama al método BasedeDatos.LeerBaseDeDatos() ya que el usuario podría haber agregado un nuevo nodo. En caso de que no exista el nodo en base de datos, el paquete se guarda en un archivo registro (.log) para posteriores análisis. Es importante destacar que esta metodología está fundamentada en que si no se conoce el nodo, no se puede desplegar en la interfaz porque no existe en base de datos, y por lo tanto no se puede geo-referenciar el peligro, lo que no entrega valor y utilidad al sistema. Además no se podría conocer el tipo de dato ni umbrales asociados, por lo tanto no se puede hacer análisis de dato ni detección de eventos indeseados. La figura 17 contiene el diagrama de flujo del procedimiento realizado por la clase principal.

Figura 17: Diagrama funcionamiento del procedimiento de guardado de datos

Posteriormente, si el nodo existe, se genera la predicción mediante series de tiempo, se almacena junto con la muestra y en el caso de que éstas superen los umbrales permitidos, se genera una alerta que también es almacenada. Los detalles de estos módulos son explicados en los siguientes tópicos.

4.3.3 PREDICTOR

4.3.3.1 JUSTIFICACIÓN DEL MODELO UTILIZADO Para el desarrollo del modelo predictor se utilizó y adecuó un algoritmo del tipo AR (autoregression) con autoaprendizaje que utiliza series de tiempo [46]. El algoritmo está pensado para ser ejecutado tanto en los nodos como en el Gateway-coordinador de red, este último calcula las predicciones y los nodos se remiten solo a trasmitir cuando se deba corregir los parámetros del modelo predictivo o cuando exista un outlier, logrando disminuir la cantidad de paquetes transmitidos. Tanto el Gateway como los nodos predicen las muestras según los parámetros del modelo de predicción calculados en un comienzo, sin embargo solo los nodos estiman el error comparando la predicción con la muestra real. Si la cantidad de muestras con errores de predicción sobre un umbral aumenta considerablemente, significa que las condiciones de lo que se está monitoreando han cambiado, y por ende, los parámetros del modelo predictivo son erróneos y deben ser re-calculados ingresando a un estado de reaprendizaje donde el nodo sensor calcula los nuevos parámetros del modelo y los envía al nodo Gateway para corregir. Este proceso se denomina re-learn.

El método utilizado se denomina PAQ (Probabilistic Adaptable Query system) [46], este implementa un algoritmo que requiere poco procesamiento, adecuado a las especificaciones técnicas de un nodo inalámbrico y que permite disminuir el consumo de energía. En [46] el nodo Gateway contiene la base de datos y el procesamiento. En esta memoria, estas funciones son realizadas por un servidor externo a la red de sensores, cambiando la topología del sistema y adecuándose a la arquitectura de la solución propuesta en este trabajo. Sin embargo, este cambio no afecta la efectividad del algoritmo.

Con el objetivo de explicar el algoritmo, se dividirá en dos etapas: aprendizaje (learn) y reaprendizaje (re-learn), que permite adaptarse a cambios de las condiciones de lo que se está monitoreando.

4.3.3.2 APRENDIZAJE (CALCULO DE COEFICIENTES) Inicialmente, en un vector se almacenan N muestras enviadas periódicamente desde la WSN al servidor. Estos datos históricos son utilizados para calcular los parámetros de la serie de tiempo.

El objetivo es determinar los pesos que permitan minimizar el error cuadrático en (2) entre la predicción y la muestra real. La componente es la muestra real i y ( ) equivale a la predicción, donde , y son los coeficientes a calcular para la serie de tiempo y permiten ponderar las muestras reales anteriores ( ) para determinar la predicción.

( ) ∑ ( ( )) (2)

Para calcular los parámetros se determinan las derivadas parciales de , y [48], se igualan a cero y se obtiene las siguientes ecuaciones: La derivada parcial de α:

∑ ( ) (3)

∑ ( ) ∑ ∑ ∑ (4)

La derivada parcial de β:

∑ ( ) ∑ ∑ ∑ (5)

La derivada parcial de γ:

∑ ( ) ∑ ∑ ∑ (6)

De (4), (5) y (6) se obtiene un sistema de ecuaciones con tres variables y N ecuaciones.

[ ] (7)

[ ] [ ]

Dado que se utilizan más ecuaciones que incógnitas y cada ecuación es independiente, la solución del sistema es la que mejor se acerque a las N-3 ecuaciones, lo cual fue resuelto por métodos matematicos contenidos en la biblioteca de .NET llamada ILnumerics [47] y Matlab, dependiendo el caso. Luego de resolver el sistema, se puede comenzar a generar predicciones ponderando los valores históricos.

4.3.3.3 RE-APRENDIZAJE (RE-LEARN) El re-aprendizaje consiste en detectar cuando las condiciones de lo monitoreado están cambiando y ejecutar las correcciones del caso.

En la tabla 1, se describen las variables necesarias para entender el algoritmo. Para detectar los cambios, se utilizó dos contadores, el primero denominado up, contabiliza el número de veces que el error de predicción ( ) supera un umbral llamado umbral1. Si el error supera un segundo umbral llamado umbral2 la muestra se considera un outlier y se aumenta el segundo contador out. Cuando up es mayor que el umbral a o up+out es mayor que a+1 se recalculan los parámetros del modelo.

N Cantidad de muestras históricas utilizadas para calcular el modelo. a Cantidad de lecturas erróneas antes de iniciar un re-cálculo de los parámetros. umbral1 Umbral de error aceptable para el modelo (sobre este umbral se considera muestra errónea) umbral2 Umbral de error para detectar outliers. (sobre este umbral se considera muestra outlier) Tabla 1: Variables utilizadas en el algoritmo

4.3.3.4 IMPLEMENTACIÓN Y PROGRAMACIÓN

En [46] se consideró que los nodos envían solo cuando se detecta un outlier o cuando debe cambiar los parámetros de predicción, en la memoria se consideró que se envían todas las muestras tomadas, sin embargo se utilizó el mismo algoritmo para generar predicciones a 5, 10, 15, 20 y 25 minutos a partir de la muestra recibida. Con el objetivo de entender de mejor manera el algoritmo, a continuación se detallan los principales métodos de la clase predictor contenido en el archivo preditor.cs,:

 SolveSys

Este método se encarga de resolver un sistema de ecuaciones de tres variables, fue programado en C# y utiliza operaciones matemáticas de la biblioteca ILnumerics [47]. Retorna un arreglo de

doublé con los tres coeficientes de la serie de tiempo ( , y ) utilizando las últimas N muestras reales.

 SetParametros

Define parámetros necesarios para llamar a SolveSys con el objetivo de calcular los coeficientes de la serie de tiempo ( , y ). También corrobora que existe la cantidad mínima de muestras necesarias para resolver el sistema de ecuaciones.  Monitor

Corresponde al método encargado de evaluar y aplicar el método de learn y re-learn para cada sensor y reúne los pasos principales del algoritmo propuesto como se aprecia en la figura 18.

Figura 18: Método de aprendizaje del predictor

4.3.4 ALMACENAMIENTO Y AGENTE ALERTAS Esta etapa es la encargada de almacenar o registrar en base datos las muestras y predicciones, además de detectar y almacenar alertas basándose en los estándares nacionales de nivel de gases.

A continuación se detallan los principales métodos de la clase BasedeDatos contenido en el archivo BasedeDatos.cs.

 Estructuras Utilizadas

Sensor: tiene información de los umbrales, tipo, identificado único, referencia, last_sample, ultimaAlertaFinalizada, ContadorMuestrasSinAlertasGuardadas, ultimaAlertaFinalizadaP, ContadorMuestrasSinAlertasGuardadasP, divisor,

 LeerDeBaseDeDatos()

Este método está encargado de leer la base de datos para almacenar en memoria el modelo de nodos inalámbricos con sus respectivos sensores. Además para cada sensor, se inicializa las variables necesarias para el agente de alertas.

 GuardarMuestrasEnBaseDeDatos Este método se encarga de almacenar datos de muestras y predicciones, y detectar sus respectivas alertas cuando estas superen el umbral.

El agente de alertas fue programado para detectar y almacenar la primera muestra sobre el umbral como una alerta y activa una alarma sonora en el servidor, sin embargo, las siguientes no se reconocen como tal, ya que son propias del mismo suceso anterior, interpretando estas muestras como pertenecientes al mismo suceso crítico. Al llegar a un número predefinido de muestras bajo el umbral, se determina que el evento crítico terminó, entonces el agente finaliza la alerta, y almacena su fecha de término.

Existe dos tipo de alertas, la que ocurre por predicción o la que ocurre por muestra real, en ambos casos el procesamiento es el mismo, sin embargo, solo cambia el campo tipo al ingresar a base de datos.

La tabla 2 muestra las variables más importantes utilizadas para la detección de alertas.

ContadorMuestraSinAlertasGuardadas Contabiliza el número de muestras o predicciones sin alertas, desde la última alerta finalizada umbral_i Umbral inferior para detección de alertas umbral_s Umbral superior para detección de alertas UltimaAlertaFinalizada Responde con true o false la pregunta: ¿Está finalizada la última Alerta? Tabla 2: Variables utilizadas en el módulo alertas

Como se aprecia en el diagrama de la figura 19, luego de recibir los datos, se evalúa si han ocurrido al menos 2 muestras anteriores sin alertas, en caso contrario se aumenta

ContadorMuestraSinAlertasGuardadas y se termina el método. Esta acción sirve para disminuir el tiempo entre alertas bajo el supuesto que luego de un evento crítico detectado, existan varias acciones que disminuyan el nivel de gas y es muy probable que la mayoría de las muestras siguientes, mientras se ejecutan estas acciones, oscilen en torno al umbral generando alertas falsas e innecesarias. Si se desea menor o mayor frecuencia entre alertas, solo se debe aumentar esta condición, aumentando o disminuyendo el umbral.

Figura 19: Diagrama del sistema de detección de alertas

4.3.5 BASE DE DATOS Y SERVIDORES La base de datos se implementó en SQL Server 2008 y el servidor utilizó el sistema operativo Windows Server 2003 y tiene las especificaciones técnicas descritas en la tabla 3:

Tipo Computador de escritorio Sistema operativo Microsoft Windows Server 2003 R2 Enterprise Edition KN Service Pack 2 Procesador Intel Pentium® Dual CPU 1,60GHz Memoria RAM 1 GB RAM Tabla 3: Especificaciones técnicas del servidor

Para la programación se utilizó la herramienta Microsoft Visual Studio 2008 y para la administración de la base de dato se utilizó Microsoft SQL Server Management Studio.

El modelo relacional implementado está descrito en la figura 20 y se distinguen las claves primarias con una llave en el casillero izquierdo.

Figura 20: Modelo de base de datos

4.3.6 CANAL ENCRIPTADO INTERFAZ-SERVIDOR Para la implementación de una comunicación segura entre el interfaz web y el servidor, se implementó OPENVPN, el cual crea un canal encriptado utilizando SSL, como se aprecia en la figura 21. El motivo de esta elección es que habitualmente en minería subterránea, mercado donde se gestó esta memoria, los servidores están en intranet y el uso de VPN está ampliamente masificado. Este criterio fue definido en base a la experiencia y prácticas realizadas en empresas del rubro minero.

Este software encapsula el tráfico a nivel de capa de aplicación y es reconocido por ser una herramienta simple y segura. Se implementó una configuración de multicliente-servidor, lo que permite autentificar a varios usuarios a la vez, para ello el cliente debe utilizar un certificado otorgado previamente. Mediante una clave pública y una privada el cliente puede ser autentificado y posteriormente se puede encapsular/encriptar el mensaje enviado, esto se define como un cifrado asimétrico.

Figura 21: diagrama túnel VPN utilizado

4.4 MÓDULO INTERFAZ SIG Este módulo es el encargado de desplegar la información de las muestras guardadas en la base de datos, alertar por pantalla los estados de alta concentración de gases y facilitar la administración y configuración básica del sistema por medio de una interfaz WEB SIG.

4.4.1 FLEX El interfaz Web fue desarrollado usando el marco de desarrollo Flex 3. Para esto se utilizó el entorno de programación Adobe Flex Builder 3 como se aprecia en la figura 22. Este framework permite entre otras funciones probar directamente el código en el explorador de internet, realizar el debug del código, entrega sugerencias al programador, entre otras funciones.

Figura 22: Entorno de desarrollo Flex

4.4.2 GOOGLEMAPS EN FLEX La característica principal del interfaz es que permite ver los datos del monitoreo de nivel de concentración de gases de manera geo-referenciada. Para lograr esto se utilizó la API de Google Maps para Flash/Flex la cual permite utilizar los mapas de Google e insertar variada información y contenido.

Para utilizar Google Maps en el entorno Flex se debe descargar de Internet el archivo .zip desde la dirección Web: http://maps.googleapis.com/maps/flash/release/sdk.zip que contiene el archivo con extensión .swc. Luego se debe agregar este archivo en el library path.del proyecto a Flex donde se desea utilizar como se ve en la figura 23.

Figura 23: Configuración API Google Maps

Una característica del sistema es que posee una interfaz que puede interpretar los archivos de extensión .kml obtenidos de la transformación desde archivos .dwg de Autocad. La ventaja de esto es que al tener los planos de cualquier construcción en autocad, automáticamente pueden ser vistos en la interfaz WEB. Para que el API para Flex de Google Maps pueda interpretar los archivos kml, se debe descargar otra API llamada gmaps-utility-library-flash que se agregó de la misma forma anterior al library path del proyecto Flex.

Configuradas las dos bibliotecas anteriores ya se puede verificar el funcionamiento de los mapas en Flex y la interpretación de archivos kml. Esta prueba se ve en la figura 24 y se utilizó el archivo .kml siguiente que genera un marcador en las coordenadas indicadas.

Oviedo Ciudad de Oviedo, capital de Asturias -5.843868,43.360758,0

Figura 24: Ejemplo Google Maps sobre Flex

4.4.3 EXPORTAR ARCHIVOS AUTOCAD A KML Una parte importante del sistema es la posibilidad de exportar archivos desde el formato .dwg del cual Autocad es propietario, al formato kml. Para realizar esto, se instaló Autocad 2009 sobre un sistema operativo Windows XP y sobre este programa, se instaló el complemento de GoogleEarth de Autodesk Labs para Autocad. Este complemento agrega una caja de herramientas con las opciones de importar imágenes y datos de elevación desde Google Earth, además de exportar los desde Autocad a un archivo .kmz o .kml. Para probar el programa, se utilizó un archivo .dwg pertenecientes a un nivel de una mina. Luego, se exportó a un archivo .kml el cual fue probado en Google Earth como se ve en la figura 25.

Figura 25: Ejemplo mapa Autocad sobre Google Maps

4.4.4 COMUNICACIÓN FLEX Y BASE DE DATOS A TRAVÉS DE AMF Para la comunicación entre el interfaz y la capa de servicio en el servidor se utilizó el protocolo de comunicación AMF (Action Message Format) formato binario basando en SOAP (Simple Object Access Protocol) y fue creado para intercambiar datos entre aplicaciones adobe Flash y bases de datos, básicamente usando RPC (Remote Procedure Call). Gracias a esto es posible compartir objetos entre la capa lógica y la capa de presentación de manera remota y transparente para el desarrollador Flex, ahorrando tiempo de procesamiento y agregando mayor seguridad a la transmisión de los datos.

AMF es nativo en Flex/Flash por lo que no se debe instalar ninguna biblioteca en el cliente, sin embargo, si es necesaria una biblioteca para el lado del servidor .NET. En este caso se utilizó FluorineFX.

FlourineFX es una biblioteca para el framework .NET que provee la implementación de comunicación remota Flex/Flash.

Para utilizar FluorineFx es necesario descargar el instalador del sitio oficial http://www.fluorinefx.com/download.html. Al instalar la biblioteca automáticamente se anexará al framework de Visual estudio 2008 archivos guías para la configuración y trabajo con FluorineFX.

Una vez configurado Visual 2008 se debe configurar el servidor del servicio. Para el servidor se utilizó un computador Intel Dual CPU, cuyas características están descritas en la tabla 2.

Para probar la comunicación se utilizó el ejemplo por defecto de FluorineFX. En la figura 26 al utilizar Wireshark se pudo ver el tipo de mensaje intercambiado entre cliente Flex y el servidor .NET.

Figura 26: Paquete AMF a través de WIreshark

Una vez verificado el funcionamiento de FluorineFx se debió configurar el servicio de acceso Web, habilitando IIS (Internet Information Service) y configurando los servicios necesarios para que a través de la interfaz se pueda realizar una petición al servidor.

4.4.5 ALERTAS Como fue descrito anteriormente, la interfaz posee un módulo de alerta que permite avisar al usuario sobre posibles mediciones que se encuentran fuera de los rangos normales con el fin de que el supervisor realice alguna acción al respecto, como obligar a los trabajadores a salir del lugar afectado y no permitir el acceso al área.

Para poder captar las alertas, el interfaz pregunta periódicamente al servidor si existen nuevas alertas que no han sido identificadas por el usuario, si encuentra alguna, la muestra por medio de una ventana Popup y activa una alarma sonora. Posteriormente el cliente puede identificar la alerta.

4.4.6 RESULTADOS DE LA INTERFAZ En la figura 27 se puede ver la sección de ingreso al sistema y en la figura 28 la pantalla inicial del programa desarrollado donde destaca el mapa SIG de la interfaz al lado izquierdo de la figura.

Figura 27: Pantalla de ingreso de usuario

Figura 28: Pantalla inicial de la interfaz

CAPITULO 5

5 RESULTADOS: VERIFICACIÓN, EVALUACIÓN Y VALIDACIÓN DE LA SOLUCIÓN

5.1 VERIFICACIÓN Una vez terminada la configuración y programación, se verificó el funcionamiento del sistema. Basado en la arquitectura planteada en la figura 13, se verificó cada uno de los agentes para el módulo de información e interfaz usuaria.

5.2 EVALUACIÓN Y VALIDACIÓN

5.2.1 TIEMPO DE SERVICIO PREDICTOR Y SOBRECARGA DEL GATEWAY Suponiendo 300 segundos entre muestras por cada nodo sensor y 255 nodos inalámbricos, se determinó que el tiempo de servicio es mucho menor que el tiempo de arribo, basado en los siguientes argumentos:

1. Se determinó el tiempo de servicio teórico necesario para los 255 nodos trasmitiendo cada 300 segundos, lo que equivale a 1,18 [s]. Si el tiempo entre muestras cambia a 30 [s], el tiempo de servicio teórico necesario disminuye a 0,12 [s].

2. Se minimizó todos lo retardos entre muestras del simulador, forzándolo a trabajar a la máxima tasa de envió de paquetes. Posteriormente, observando las fechas de almacenamiento de las muestras, se determinó que el tiempo de servicio fue de 14 [ms], lo que teóricamente permitiría analizar hasta 18750 nodos con un único servidor y con un tiempo entre muestras de 300 segundos o analizar 255 nodos a una tasa de envió de 3,6 [s].

Es importante destacar que se trabajó con 300 [s] entre muestras, sin embargo, esta métrica solo es una referencia ya que dependiendo de la velocidad de acumulación de gases se puede adaptar fácilmente a otros requerimientos, ya que el funcionamiento del sistema considera medidas discretas independiente del tiempo entre muestras.

5.2.2 PREDICTOR

5.2.2.1 VALIDACIÓN PAQ El objetivo de la validación del predictor va más allá de la implementación realizada en esta memoria, sino que busca avanzar en la validación del método PAQ para futuras aplicaciones y mejoras del sistema, validando de paso la elección y comportamiento del predictor en la implementación presentada.

Inicialmente se evaluó el algoritmo utilizando una curva de temperatura real. Los datos fueron medidos inicialmente a temperatura ambiente, y luego el sensor fue ingresado a un refrigerador, variando bruscamente el intercambio calórico, pasando de 297 °K (24°C) a 265 °K (-8°C) contabilizando más de 630 muestras con un tiempo entre muestras de 10 segundos.

N Cantidad de muestras históricas utilizadas para calcular el modelo a Cantidad de lecturas erróneas antes de iniciar un re-cálculo de los parámetros umbral1 Umbral de error aceptable para el modelo (por sobre se considera muestra errónea) umbral2 Umbral de error para detectar outliers. (por sobre se considera muestra errónea) Tabla 4: Parámetros del predictor

5.2.2.1.1 RESULTADO PRIMERA EVALUACIÓN Se evaluó el algoritmo propuesto relearn [46] Para ello se programó el algoritmo en Matlab configurando sus parámetros en: N=20, a=10, umbral1=0.3 °K y umbral2=0.6 °K. En términos prácticos se consideró correcta una predicción con un error menor a 0.3°K y se considera outlier sobre los 0.6 °K de error, activando el re-cálculo de las muestras luego de una acumulación de 10 errores o si la suma entre errores y outliers es mayor o igual a 11.

Se consideró la retransmisión de outliers al servidor, por lo que el número de transmisiones equivale a la suma de outliers y re-aprendizajes.

Como se ve en la tabla 5, el ahorro en transmisiones es de 87%, lo que significa una gran mejora versus el envió de todos los paquetes, lo cual también se puede apreciar en las figura 29 y 30. El

51 error medio de predicción es de 0.27 [°K], sin embargo, el error máximo detectado es de 1.68 [°K], muy superior al error de medición de un sensor de temperatura promedio (0.6°K).

Número de re-aprendizajes 17 Outliers 65 Muestras sobre umbral1 130 Transmisiones 82 Número de mediciones 630 Ahorro (transmisiones) 87% Error medio 0.2674 °K Máximo error 1.6829 °K Tabla 5: Resultados obtenidos

Figura 29: Curvas predicción y muestras reales primera evaluación

Figura 30: Curva error de predicción para primera evaluación

5.2.2.1.2 RESULTADOS SEGUNDA EVALUACION: UTILIZANDO OUTLIERS PARA CORRECCION DE PREDICCIÓN Un outlier se considera como una mala medición o un cambio abrupto de las condiciones de lo monitoreado [65]. Para esta prueba de evaluación se interpretó el outlier como un cambio fenomenológico del sistema, que permite corregir el modelo utilizándolo como una muestra sobre la cual calcular la predicción, basado en el supuesto de que el outlier probablemente se debe a que la velocidad de cambio de la temperatura es mucho mayor a la que el modelo calculado permite predecir. Esta implementación no se aplica a sensores con muchas fallas en la medición o con mucho ruido. Se implementó una nueva manera de calcular los pronósticos utilizando los mismos parámetros del experimento anterior, y cambiando la corrección utilizando los outliers. Como se puede ver en la tabla 6 y en las figuras 31 y 32, en comparación a la primera evaluación la mejora es considerable, el ahorro aumento en un 8%, ascendiendo a 95% y mejorando el error medio un 23%, disminuyendo a 0.2058°K. El error máximo detectado disminuyó prácticamente a la mitad.

Número de re-aprendizajes 15 Outliers 18 Muestras sobre umbral1 153 Transmisiones 82 Número de mediciones 630 Ahorro (transmisiones) 95% Máximo error 0.8047 °K Error medio 0.2058 °K Tabla 6: Resultados obtenidos

Figura 31: Curvas predicción y muestras reales primera evaluación

Figura 32: Curva error de predicción para segunda evaluación

5.2.2.1.3 TERCERA EVALUACION: UTILIZANDO OUTLIERS PARA CORRECCION DE PREDICCIÓN CON DISMINUCIÓN DEL UMBRAL Finalmente se disminuyo el Umbral1 de 0,3 a 0.1 y Umbral2 de 0,6 a 0.2 con el fin de conocer el comportamiento del algoritmo. Es natural pensar que el número de transmisiones debería aumentar ya que la calidad requerida de la predicción aumentó, sin embargo, como se aprecia en la tabla 7, si bien es cierto el ahorro disminuye 6%, en comparación con la segundo evaluacion, este llegó a 89%, lo cual sigue siendo 2% mejor que la primera evaluación, la cual tiene umbrales mucho más permisivos.

Lo más destacable, es que el error medio disminuyó a un 58% en comparacion con la segunda evaluación y el máximo error disminuyó un 35% con respecto a la misma, y con respecto a la primera evaluación, el error medio disminuyó dramáticamente en un 95%.

Numero de re-aprendizajes 19 Outliers 52 Muestras sobre umbral1 165 Transmisiones 71 Numero de mediciones 630 Ahorro (transmisiones) 89%

Máximo error 0.5226 Error medio 0.0864 Tabla 7: Resultados obtenidos

Figura 33: Curvas predicción y muestras reales tercera evaluación

Figura 34: Curva error de predicción para tercera evaluación

5.2.2.2 VALIDACIÓN IMPLEMENTACIÓN UTILIZADA Como se explicó en la implementación de la solución, todas las muestras son enviadas al servidor desde el emulador, luego por cada muestra que va llegando se calculan las siguientes 5 predicciones para las 5 siguientes muestras. Se evaluó el comportamiento estableciendo parámetros estrictos de error, utilizando 0.03 [ppm] para el umbral1 y 0.05 [ppm] para el umbral2.

La curva analizada es la misma del punto anterior utilizando un orden de magnitud menos para adecuarse al comportamiento de un sensor de gas CO que habitualmente se encuentra entre 1 y 30 [ppm], y fue integrada al emulador.

Si solo se predice la muestra siguiente, esta tendría un error medio de 0,013[ppm], sin embargo, como se aprecia en la tabla 8, el error cuadrático medio (ECM) desde la 2da hasta la quinta predicción es considerablemente bajo, tomando en cuenta la magnitud del umbral de peligrosidad del gas CO (40ppm).

1ra 2da 3ra 4ta 5ta ECM antes del Re- 0,022984595 0,050155 0,084193 0,121264 0,160784 learn ECM final 0,013440549 0,02759 0,04545 0,065058 0,085949 Tabla 8: Tabla con errores cuadráticos medios para las siguientes 5 predicciones

En la curva de temperatura analizada se aprecian dos comportamientos distintos, el primero es una curva con pendiente negativa propia de la pérdida de calor, y el segundo es un movimiento ondulatorio. El predictor detectó esos comportamientos recalculando el modelo (re-learn), lo cual disminuyo el error cuadrático medio final. En la tabla 8 se presenta el ECM calculado antes de que se active el re-learn y el ECM al finalizar la evaluación, lo que nos indica que luego de re-learn el error cuadrático disminuyó, entregando un ECM final menor.

Como se aprecia en la tabla 8, el ECM antes del reaprendizaje bordeaba los 0,02 y 0,16 en la primera y quinta predicción respectivamente. Al realizar el re-learn el ECM fue disminuyendo gradualmente hasta llegar a 0,013 y 0,08. En conclusión el método es efectivo para este caso y se puede extrapolar al uso en sensores de gases, siempre y cuando se generen validaciones con muestras reales y bajo una tasa de muestreo mayor.

5.2.3 TAMAÑO Y TIEMPO DE CARGA DEL PLANO AUTOCAD EN GOOGLE MAPS Se realizó las pruebas del tiempo de despliegue de los planos exportados desde formato .dwg a .kml en la API de Google Maps para Flex. Para esto se utilizó 5 archivos .kml de planos de tamaños de 1

[MB], 700 [kB], 600 [kB], 500 [kB] y 200[kB] y se cronometró el tiempo desde que una persona realiza la petición a la página hasta que todo el mapa es mostrado en la interfaz. Para esto se utilizó el mismo computador como servidor de la página. El retardo con la página de mapas de Google Maps fue determinando mediante Ping con 40[ms] tiempo medio de ida y vuelta de un paquete, con el objetivo de tener una medida de comparación.

Las tablas en el anexo 9.2 muestran los resultados obtenidos.

En el gráfico de la figura 35 se puede observar la linealidad del tiempo de carga con el tamaño del archivo. El tiempo de carga solo de Google Maps es de 4[s]. Por lo cual es importante que el archivo de mapa KML sea menor o igual a 200[kB] para tener un tiempo de carga de 6 [s]. A futuro se espera implementar un servidor de mapas propios con tal de bajar este tiempo de carga.

Figura 35: Tiempo retardo para planos en Google Maps

5.2.4 COMPARACIÓN COMUNICACIÓN AMF V/S XML Para realizar una comparación entre la comunicación a través de XML y AMF se utilizó la misma información de las muestras emuladas grabadas en base de datos, se configuró ambos tipos de comunicación de datos sobre el mismo modelo de pregunta a la base de datos. Luego se cronometró el tiempo desde la petición de datos hasta el despliegue de los mismos en una interfaz programada en Flex. Lo que se obtuvo es lo mostrado en la tabla 9 para 10 peticiones:

AMF tiempo de respuesta Tiempo respuesta XML 1 0,592 1 1,362 2 0,57 2 1,347 3 0,575 3 1,354 4 0,543 4 1,353 5 0,465 5 1,442 6 0,442 6 1,417 7 0,588 7 1,462 8 0,285 8 1,379 9 0,593 9 1,375 10 0,582 10 1,326 promedio 0,5235 promedio 1,3817

Tabla 9: Tablas de comparación tiempo de respuesta AMF v/s XML en segundos

En la tabla 9 se logra observar que el tiempo promedio obtenido que toma AMF es menor al tiempo promedio que demora XML en transmitir los datos en 0.8582 [s]. Esto seguramente se debe a que XML es más ineficiente en el uso de etiquetas enviando mayor información inútil.

CAPITULO 6 6 CONCLUSIONES Al finalizar el trabajo de memoria, se obtuvo un sistema que permite recolectar, guardar, analizar, generar predicciones, detectar alertas y desplegar los datos del nivel de concentración de gases en el ambiente, obtenidos de una red de sensores inalámbricos distribuidos. Específicamente se finalizó el primer prototipo de un producto comercial el cual en conjunto con la memoria de Alejandro Rivera componen el sistema completo de monitoreo en tiempo real. Es importante destacar que en el resultado final se alcanzaron los objetivos propuestos y el sistema obtenido es de una alta calidad reflejada en las características del sistema final en donde resalta: un adquisidor de datos que genera alertas y también genera predicciones a través de un algoritmo de series de tiempo que permite al supervisor tener una idea de cómo variará el nivel de concentración de gases en un futuro próximo, permitiendo adelantarse a eventos peligrosos. Un dispositivo de comunicación de fácil configuración que permite exportar los datos obtenidos desde una red de sensores al servidor de análisis y de base de datos. Además se utilizó un software basado en el framework Flex el cual implementa un software SIG que permite referenciar geográficamente la ubicación de los puntos de muestras y administrar los datos del sistema. También se utilizó una herramienta que permite exportar mapas con extensión .DWG de Autocad a archivos con extensión .KML facilitando el trabajo de re-dibujo de un plano. Por otro lado destaca la utilización del protocolo AMF que agrega mayor robustez a la comunicación y permite disminuir el tiempo de transmisión y transformación de los datos. Y por último, la implementación de un canal encriptado para la transmisión de datos por medio del uso de OpenVPN con todas las ventajas de usar los túneles VPN.

En este trabajo fue una requisito, dentro de lo posible, el utilizar tecnologías de Microsoft. Estas tecnologías no eran dominadas por ambos memoristas acostumbrados a trabajar más con sistemas operativos como FreeBSD y en programas libre, por lo cual los dos memoristas tuvieron que aprender por cuenta propia cómo trabajar sobre tecnologías de Microsoft para el desarrollo del trabajo de memoria. Se tuvo que configurar un servidor Microsoft Server 2003 con servicios HTTP (IIS), ASP y Microsoft SQL 2005. Esto tarea no fue fácil, dado que la tecnología Microsoft utiliza otras formas de trabajo a la conocida en entornos como FreeBSD. Esto se hizo presente en problemas con la configuración de permisos y la configuración de los entornos de trabajo. Para aprender sobre estos temas se consultó los tutoriales facilitados por MSDN y muchos otros tutoriales encontrados en la Web. Por otro lado se debió desarrollar sobre el ambiente Microsoft

Visual Studio 2008 Toda la capa lógica y el módulo de análisis de datos fue programada sobre C#, resaltando la utilización de FluorineFX para la comunicación de AMF con la aplicación cliente y ILNUMERICS para cálculos matemáticos matricial. Otro punto importante y que no sale descrito a lo largo de la memoria es la utilización de Visual SVN, un servidor SVN para el control de versiones que en conjunto con el cliente SVN para el entorno Flex permitió desarrollar de manera más ordenada la interfaz de usuario.

Del trabajo realizado, fue fundamental la planificación inicial del proyecto. Sin esta planificación el trabajo no hubiese alcanzado los resultados obtenidos. Esto se concluye del hecho que aún con la planificación inicial, en donde se desarrolló los requerimientos, casos de uso, funciones y características específicas; hubo algunos detalles que no fueron previstos y que debieron ser solucionados a medida que se avanzó en el desarrollo. De este punto también se aprendió que para el desarrollo de software profesional es esencial aplicar modelos de desarrollo de software para generar procedimientos que permiten generar códigos más reutilizables, conformar un entendimiento común de las actividades, recursos y restricciones involucrados, reflejar las metas de desarrollo, disminuir el re trabajo, disminuir los tiempos de desarrollo y por último generar software de mejor calidad y escalable para desarrollos posteriores. Como futuros trabajos basados en la memoria, es interesante e importante la utilización de hebras para la comunicación entre servidor y la red WSN, especialmente en otras aplicaciones no tan críticas que permiten la utilización de un servidor para varias redes, lo cual optimiza el uso del servidor de datos. También es importante en un futuro, el desarrollo de un software para estadísticas y análisis de datos basado en Crystal Labs, programa utilizado en la minería, que permita al encargado obtener los informes y gráficos importantes uniéndolos a los sistemas estadísticos existentes. Otra futura mejora es la utilización de servidores replicados y sistemas robustos de disponibilidad y procesamiento de datos en caso de que el servidor tenga caídas de servicio o presente problemas, con el propósito de no perder los datos y tener un mayor tiempo de servicio, punto esencial en una aplicación de la cual depende la vida de una persona utilizando por ejemplo: sistemas de Servidores reflejos, Cloud computing, data centers, etc. Por último, la implementación y desarrollo de algoritmos de propagación de gases dentro de ambientes confinados es una buena herramienta que complementa el trabajo realizado dando mayor información al supervisor y permitiendo obtener mejores predicciones.

Los dos memoristas en conjunto con Alejandro Rivera crearon una empresa llamada Lem System Ltda. [64] en base a lo realizado en la memoria utilizando redes de sensores y los sistemas de

61 adquisición, análisis de datos e interfaz de usuario adquiriendo una experiencia enriquecedora al utilizar los conocimientos obtenidos en un proyecto propio.

Por último el trabajo de memoria fue una experiencia que permitió poner en práctica los conocimientos adquiridos a lo largo de los estudios en el tema de las tecnologías de la información, así como las habilidades para enfrentar nuevos problemas que comprenden nuevas tecnologías, coordinación, pro actividad y sobre todo trabajo en equipo. Este último muy importante dado que agrupa muchas otras habilidades que no son adquiridas de manera teórica y que pueden llegar a poner en riesgo un proyecto completo aun teniendo las capacidades técnicas para desarrollarlo.

7 REFERENCIAS 1. http://www.draeger.es/ST/internet/ES/es/index 2. http://www.gasalarmsystems.co.uk/Products/PortableProducts.aspx 3. http://es.wikipedia.org/wiki/Controlador_lógico_programable 4. http://www.jandei.com/ 5. http://www.pureairemonitoring.com/category/all-categories/gas-monitors/ 6. http://www.net-safety.com/products/controllers.html 7. http://www.ni.com/labview/ 8. http://en.wikipedia.org/wiki/Data_logger 9. Grega, W.; Kolek, K.; Simulation and real-time control: from Simulink to industrial applications Computer Aided Control System Design, 2002. Proceedings. 2002 IEEE International Symposium on 18-20 Sept. 2002 Page(s):104 – 109. 10. http://www.mathworks.com/. 11. http://www.parijat.com/special_applications/CEMS_Brochure.pdf 12. http://www.codel.co.uk/cems-emission-monitoring-products-fluegasanalyser-smartcem- software-integrated.htm 13. http://msdn.microsoft.com/es-cl/vcsharp/dd919145.aspx 14. http://es.wikipedia.org/wiki/Sistema_de_Información_Geográfica 15. Shannon L. Henshaw, Frank C. Curriero, Timothy M. Shields, Gregory E. Glass, Paul T. Strinckland, Patrick N. Breysse; Geostatics and GIS; Tools for Characterizing Envireonmental Contamination; Journal of Medical Systems, Vol. 28, No. 4, August 2004 16. http://maps.google.cl/ 17. http://earth.google.es/ 18. www.skylinesoft.com/ 19. http:// worldwind.arc.nasa.gov/ 20. http://es.wikipedia.org/wiki/XML 21. http://opengis.net/gml/ 22. Yi Shanzhen; Zhou Lizhu; Xing Chunxiao; Liu Qilun; Zhang Yong; Semantic and interoperable WebGIS; Web Information Systems Engineering, 2001. Proceedings of the Second International Conference on Volume 2, 3-6 Dec. 2001 Page(s):42 - 47 vol.2 23. Wu Qunyong; Wang Qinmin; Zhou Chenghu; Chen Chuanbin; Huang Ruiyin; Study on GML and SVG-based Open WebGIS and its application; Geoscience and Remote Sensing

Symposium, 2005. IGARSS '05. Proceedings. 2005 IEEE International Volume 2, 25-29 July 2005 Page(s):3 pp. 24. http://code.google.com/intl/es-ES/apis/kml/documentation/ 25. http://es.wikipedia.org/wiki/AJAX 26. Paulson, L.D.; Building rich Web applications with Ajax Computer Volume 38, Issue 10, Oct. 2005 Page(s):14 – 17 27. http://www.adobe.com/es/products/flex/overview/ 28. http://code.google.com/intl/es-ES/apis/maps/documentation/flash/ 29. http://java.sun.com/j2ee/reference/whitepapers/j2ee_guide.pdf; “Two-Tier vs. Multi-Tier Application Models” 30. http://en.wikipedia.org/wiki/Multitier_architecture/ 31. http://es.wikipedia.org/wiki/AutoCAD 32. http://www.opendesign.com/files/guestdownloads/EveryDWG.zip 33. http://www.a9tech.com/a9converter/ 34. http://labs.autodesk.com/utilities/google_earth_extension_beta/ 35. http://profesores.elo.utfsm.cl/~agv/talks/2008/WSN_Mobile_Devices.pdf 36. http://www.directindustry.es/prod/ethernet-direct/conversor-ethernet-zigbee-39231- 385293.html 37. http://www.wiznet.co.kr/Sub_Modules/en/product/Product_Detail.asp?cate1=&cate2=&cat e3=&pid=1040#tab 38. http://www.icpdas.pl/en/i-7570-p-4781.html 39. http://www.guatewireless.org/articulos/mysql-vs-postgresql/ 40. http://es.wikipedia.org/wiki/MySQL 41. http://en.wikipedia.org/wiki/PostgreSQL 42. http://es.wikipedia.org/wiki/Microsoft_SQL_Server 43. http://en.wikipedia.org/wiki/Predictive_modelling 44. P. Brockwell and R. Davis. Introduction to Time Series and Forecasting. Springer, 1994 45. http://www.inf.utfsm.cl/~rsalas/Pagina_Investigacion/docs/Apuntes/Redes Neuronales Artificiales.pdf 46. Daniela Tulone and Samuel Madden. PAQ: Time Series Forecasting For Approximate Query Answering In Sensor Networks 47. http://ilnumerics.net/ 48. G. Golub and C. Van Loan. Matrix Computations. Johns Hopkins, 1989 49. http://www.atmel.com/dyn/products/product_card.asp?part_id=3941

50. http://meshnetics.com/press_releases/MeshNetics_Ethernet_Gateway_PR_4Apr07.pdf 51. http://www.ember.com/ 52. http://focus.ti.com/docs/prod/folders/print/cc2430.html 53. http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL#Benchmarks 54. http://jamonation.com/node/734 55. http://2bits.com/articles/benchmarking-postgresql-vs-mysql-performance-using-drupal- 5x.html 56. http://www.odesk.com/blog/2009/06/postgresql-vs-mysql/ 57. http://www.scribd.com/doc/14897130/Rendimiento-de-MS-SQL-Server-ORACLE-y- PostgreSQL-para-Consultas-de-Diversa-Complejidad 58. http://msdn.microsoft.com 59. http://focus.ti.com/docs/prod/folders/print/cc2430.html 60. http://en.wikipedia.org/wiki/Serial_communication 61. http://www.w3.org/Protocols/ 62. http://www.esri.com/software/arcgis/index.html 63. http://www.tufuncion.com/optimizar_mysql 64. http://www.lemsystem.cl 65. http://es.wikipedia.org/wiki/Outlier

8 ANEXOS

8.1 ANEXO CASOS DE USO

Caso de Uso Determinar áreas peligrosas Actores Supervisor Propósito Indicar una zona del nivel a la cual se restringe el acceso Resumen Supervisor crea una zona peligrosa haciendo click sobre los nodos asociados a esta. Tipo Referencias Cruzadas Curso Normal de los eventos Accion de actores Respuesta del sistema 1. El caso de uso empieza cuando el 2. Sistema lo valida como usuario y lo envía a supervisor ingresa al sistema ingresado su la ventana de ingreso usuario y contraseña 3. El supervisor ingresa al sistema y va a la 4. El sistema obtiene los datos de los nodos sección Agregar zona peligrosa y Selecciona del nivel y los muestra por pantalla. nivel. 5.- Usuario realiza click en aquellos nodos 6. Sistema crea la zona peligrosa con los que quiere que pertenescan a la zona respectivos nodos e informa al supervisor peligrosa. Luego valida su selección y de la operación exitosa. identifica con algun descriptor la zona peligrosa Figura 36: Caso de uso determinar reas peligrosas

Caso de Uso Borrar zona peligrosa Actores Supervisor Propósito borrar zona del nivel a la cual se había restringido el acceso Resumen Supervisor borra una zona peligrosa creadda con anterioridad

Tipo Referencias Cruzadas Curso Normal de los eventos Accion de actores Respuesta del sistema 1. El caso de uso empieza cuando el 2. Sistema lo valida como usuario y lo envía a supervisor ingresa al sistema ingresado su la ventana de ingreso usuario y contraseña 3. El supervisor ingresa al sistema y va a la 4. El sistema obtiene las zonas peligrosas del sección eliminar zonas peligrosas y nivel y las muestra al supervisor Selecciona nivel. 5.- Usuario selecciona zona peligrosa y hace 6. Sistema borra la zona peligrosa con los la petición para borrarla respectivos nodos e informa al supervisor de la operación exitosa. Figura 37: Caso de uso borrar zona peligrosa

Caso de Uso Borrar e identificar alertas Actores Supervisor Propósito Identificar las alertas que han ocurrido Resumen Supervisor busca las alertas para luego identificar la causa de estas. Tipo Referencias Cruzadas Curso Normal de los eventos Accion de actores Respuesta del sistema 1. El caso de uso empieza cuando el 2. Sistema lo valida como usuario y lo envía a supervisor ingresa al sistema ingresado su la ventana de ingreso usuario y contraseña 3. El supervisor ingresa al sistema y va a la 4. El sistema busca la alertas con los sección alertas donde puede seleccionar ver parametros y las presenta al supervisor las últimas alertas o buscarlas por fecha y por nivel. 5.- Usuario selecciona la alerta, e identifica el 6. Sistema actualiza motivo de la alerta e motivo de esta, con tal de guardar un registro informa al supervisor del éxito de la operación. Figura 38: Caso de uso borrar e identificar alertas

Caso de Uso Monitorear nivel Actores Supervisor Propósito Ver el estado de gases de los diferentes niveles de la mina Resumen Supervisor monitorea el estado de los gases en los diferentes niveles de la mina Tipo Referencias Cruzadas Curso Normal de los eventos Accion de actores Respuesta del sistema 1. El caso de uso empieza cuando el 2. Sistema lo valida como usuario y lo envía a supervisor ingresa al sistema ingresado su la ventana de ingreso usuario y contraseña 3. El supervisor ingresa al sistema y se dirige 4. El sistema devuelve datos de los al monitoreo de estados de gases en la mina. diferentes sensores. y selecciona nivel 5.- Supervisor observa los datos realizando click sobre cada nodo y puede ver la concentración por un mapa cromatico

Figura 39: Caso de uso monitorear nivel

Caso de Uso Ver predicción Actores Supervisor Propósito Ver predicción del estado de gases de los diferentes niveles de la mina Resumen Supervisor ve las diferentes predicciones de gases para los niveles de la mina Tipo Referencias Cruzadas Curso Normal de los eventos Accion de actores Respuesta del sistema 1. El caso de uso empieza cuando el 2. Sistema lo valida como usuario y lo envía a supervisor ingresa al sistema ingresado su la ventana de ingreso usuario y contraseña 3. El supervisor ingresa al sistema y accesa a 4. El sistema obtiene predicciones y las la sección predicción, donde elige nivel. Y la muestra al supervisor predicción 5. Usa monitorear nivel

Figura 40: Caso de uso ver predicción

Caso de Uso Obtener gráficos Actores Supervisor Propósito Ver gráficos de las principales datos estadísticos del sistema Resumen Supervisor ve en gráficos los princiales datos estadisticos referentes al estado de los gases para los niveles de la mina. Tipo Referencias Cruzadas Curso Normal de los eventos Accion de actores Respuesta del sistema 1. El caso de uso empieza cuando el 2. Sistema lo valida como usuario y lo envía a supervisor ingresa al sistema ingresado su la ventana de ingreso usuario y contraseña 3. El supervisor ingresa al sistema y accesa a 4. El sistema devuelve los datos y presenta la sección gráficos, donde elige fecha, tipo de la información gráfico, dato a graficar, etc. 5. Supervisor ve los gráficos, y si lo desea 6.- Sistema imprime los gráficos o exporta puede imprimirlos o exportarlos a otro los datos a otros archivos como excel o pdf. documento Figura 41: Caso de uso obtener gráficos

Caso de Uso Generar alertas Actores WSN Propósito Generar las alertas para muestras WSN Resumen Las muestras son analizadas para determinar si se encuentran fuera de los rangos para generar alerta Tipo Referencias Cruzadas Curso Normal de los eventos Accion de actores Respuesta del sistema 1.- adquisidor envía muestras 2.-Sistema recibe los datos y los analiza. Si existe muestra fuera de rango crea alerta y la comunica 3.- Supervisor ve alerta y realiza click sobre 4.- Sistema valida que el supervisor ha sido ella para registrar su conocimiento de esta. informado.

Figura 42: Caso de uso generar alertas

Caso de Uso Agregar nodo Actores Administrador Propósito Agregar un nuevo nodo sensor en el sistema Resumen Administrador agrega nuevo nodo sensor que tomará datos en el sistema. Tipo Referencias Cruzadas Curso Normal de los eventos Accion de actores Respuesta del sistema 1.- Administrador inicia sesión con datos de 2.-Sistema valida al administrador y le usuario permite el acceso con ermisos de administrador 3.- Adminsitrador ingresa en tarea de 4.- Sistema obtiene los datos de los nodos administrador y hace click en agregar nodo y existentes para el nivel. selecciona el nivel que quiere. 5.- Administrador ingresa tipo de nodo, los 6.- Sistema recibe los datos y crea nuevo gases asociados al sensor y su posicion nodo. Para luego enviar mensaje de éxito al geográfica y preciona en aceptar administrador Figura 43: Caso de uso agregar nodo

Caso de Uso Borrar nodo Actores Administrador Propósito Borrar un nodo ingresado en el sistema Resumen Administrador Elimina un nodo sensor del sistema .

Tipo Referencias Cruzadas Curso Normal de los eventos Accion de actores Respuesta del sistema 1.- Administrador inicia sesión con datos de 2.-Sistema valida al administrador y le usuario permite el acceso con ermisos de administrador 3.- Adminsitrador ingresa en tarea de 4.- Sistema los nodos del nivel para administrador y hace click en borrar nodo y presentarlos selecciona el nivel que quiere. 5.- Administrador selecciona el nodo a 6.- Sistema borra el nodo. Y devuelve al eliminar y preciona aceptar. adminsitrador mensaje de que la operación fue exitosa Figura 44: Caso de uso borrar nodo

Caso de Uso Actualizar nodo Actores Administrador Propósito Actualiza datos de un nodo ingresado en el sistema Resumen Administrador actualiza los datos asociados a un nodo sensor del sistema . Tipo Referencias Cruzadas Curso Normal de los eventos Accion de actores Respuesta del sistema 1.- Administrador inicia sesión con datos de 2.-Sistema valida al administrador y le usuario permite el acceso con ermisos de administrador 3.- Adminsitrador ingresa en tarea de 4.- Sistema los nodos del nivel para administrador y hace click en actualizar nodo presentarlos y selecciona el nivel que quiere. 5.- Administrador selecciona el nodo a 6.- Sistema borra el nodo. Y devuelve al eliminar y preciona aceptar. adminsitrador mensaje de que la operación fue exitosa 7.- Administrador actualiza datos del nodo 8.- Sistema actualiza nuevos datos y si fue como sensores asociados, posicion exitoso devuelve mensaje de éxito geográfica, etc: y preciona aceptar

Figura 45: Caso de uso actualizar nodo

8.2 TABLAS TIEMPO DE CARGA GOOGLEMAPS

Tiempo carga google normal Tiempo carga google 1Mb muestra tiempo(s:ms) muestra tiempo(s:ms) 1 4,26 1 13,63 2 4,18 2 13,59 3 4,15 3 13,87 4 4,18 4 13,62 5 4,65 5 13,99 6 4,31 6 13,99 7 4,33 7 13,66 8 4,39 8 13,62 9 4,21 9 13,97 10 4,12 10 13,66 promedio 4,278 promedio 13,76

Tabla 10: Tabla tiempo de carga Google Maps normal y con archivo de 10Mb

Tiempo carga google 700Kb Tiempo carga google 600Kb muestra tiempo(s:ms) muestra tiempo(s:ms) 1 10,11 1 9,17 2 10,14 2 9,05 3 10,78 3 9,79 4 9,98 4 9,81 5 10,29 5 9,6 6 10,17 6 8,97 7 10,01 7 9,58 8 10,02 8 9,31 9 10,13 9 9,54 10 10,98 10 9,57 promedio 10,261 promedio 9,439

Tabla 11: Tabla tiempo de carga Google Maps con archivo de 700Kb y con archivo de 600Kb

Tiempo carga google 200Kb muestra tiempo(s:ms) 1 5,65 2 5,63 3 5,5 4 5,83 5 5,7 6 6,29 7 6,09 8 6,04 9 5,55 10 5,83 promedio 5,811

Tabla 12: Tabla tiempo de carga Google Maps ara archivo de 200Kb