Embed Size (px)
Citation preview
1
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
2
AGRADECIMIENTOS
A nuestros profesores, familiares y amigos.
3
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
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
5
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
6
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
7
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
8
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.
9
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.
10
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
11
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 geo-
referenciada 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.
12
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
13
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
14
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.
15
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.
16
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
17
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
18
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 geo-
referenciada 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.
19
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
20
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].
21
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.
22
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.
23
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.
24
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.
1
2
3
5
4
25
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
2
3
4 4
1
26
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.
1
27
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.
2
1
28
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
1
29
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.
1
30
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]
31
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.
32
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
33
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
34
4.3.2 ADQUISIDOR, SOCKETS Y PROTOCOLO DESARROLLADO
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
:1:2000:3000:4000:5000:~
35
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
36
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 re-
aprendizaje (re-learn), que permite adaptarse a cambios de las condiciones de lo que se está
monitoreando.
37
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.
38
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
39
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
40
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
41
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 RAMTabla 3: Especificaciones técnicas del servidor
42
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.
43
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.
44
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.
45
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.
<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.2">
<Placemark>
<name>Oviedo</name>
<description>Ciudad de Oviedo, capital de Asturias</description>
<Point>
<coordinates>-5.843868,43.360758,0</coordinates>
</Point>
</Placemark>
</kml>
46
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
47
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
48
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
49
Figura 28: Pantalla inicial de la interfaz
50
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.
51
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
52
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
53
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.
54
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
55
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%
56
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
57
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-
learn
0,022984595 0,050155 0,084193 0,121264 0,160784
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
58
[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:
59
1
2
3
4
5
6
7
8
9
10
promedio 0,5235
AMF tiempo de respuesta
0,442
0,588
0,285
0,593
0,582
0,592
0,57
0,575
0,543
0,465
1
2
3
4
5
6
7
8
9
10
promedio
1,326
Tiempo respuesta XML
1,3817
1,442
1,417
1,462
1,379
1,375
1,362
1,347
1,354
1,353
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.
60
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
61
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
62
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.
63
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
64
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
65
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
66
8 ANEXOS
8.1 ANEXO CASOS DE USO
Caso de Uso
Actores
Propósito
Tipo
Referencias Cruzadas
Accion de actores Respuesta del sistema
Resumen
Curso Normal de los eventos
Determinar áreas peligrosas
Supervisor
Supervisor crea una zona peligrosa haciendo click sobre los
nodos asociados a esta.
Indicar una zona del nivel a la cual se restringe el acceso
1. El caso de uso empieza cuando el
supervisor ingresa al sistema ingresado su
usuario y contraseña
2. Sistema lo valida como usuario y lo envía a
la ventana de ingreso
3. El supervisor ingresa al sistema y va a la
sección Agregar zona peligrosa y Selecciona
nivel.
4. El sistema obtiene los datos de los nodos
del nivel y los muestra por pantalla.
5.- Usuario realiza click en aquellos nodos
que quiere que pertenescan a la zona
peligrosa. Luego valida su selección y
identifica con algun descriptor la zona
peligrosa
6. Sistema crea la zona peligrosa con los
respectivos nodos e informa al supervisor
de la operación exitosa.
Figura 36: Caso de uso determinar reas peligrosas
Caso de Uso
Actores
Propósito
Tipo
Referencias Cruzadas
Accion de actores Respuesta del sistema
Curso Normal de los eventos
Borrar zona peligrosa
Supervisor
borrar zona del nivel a la cual se había restringido el acceso
Resumen Supervisor borra una zona peligrosa creadda con anterioridad
5.- Usuario selecciona zona peligrosa y hace
la petición para borrarla
6. Sistema borra la zona peligrosa con los
respectivos nodos e informa al supervisor
de la operación exitosa.
1. El caso de uso empieza cuando el
supervisor ingresa al sistema ingresado su
usuario y contraseña
2. Sistema lo valida como usuario y lo envía a
la ventana de ingreso
3. El supervisor ingresa al sistema y va a la
sección eliminar zonas peligrosas y
Selecciona nivel.
4. El sistema obtiene las zonas peligrosas del
nivel y las muestra al supervisor
Figura 37: Caso de uso borrar zona peligrosa
67
Caso de Uso
Actores
Propósito
Tipo
Referencias Cruzadas
Accion de actores Respuesta del sistema
Borrar e identificar alertas
Supervisor
Curso Normal de los eventos
1. El caso de uso empieza cuando el
supervisor ingresa al sistema ingresado su
usuario y contraseña
2. Sistema lo valida como usuario y lo envía a
la ventana de ingreso
Identificar las alertas que han ocurrido
Resumen Supervisor busca las alertas para luego identificar la causa de
estas.
3. El supervisor ingresa al sistema y va a la
sección alertas donde puede seleccionar ver
las últimas alertas o buscarlas por fecha y por
nivel.
4. El sistema busca la alertas con los
parametros y las presenta al supervisor
5.- Usuario selecciona la alerta, e identifica el
motivo de esta, con tal de guardar un registro
6. Sistema actualiza motivo de la alerta e
informa al supervisor del éxito de la
operación. Figura 38: Caso de uso borrar e identificar alertas
Caso de Uso
Actores
Propósito
Tipo
Referencias Cruzadas
Accion de actores Respuesta del sistema
Monitorear nivel
Supervisor
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
1. El caso de uso empieza cuando el
supervisor ingresa al sistema ingresado su
usuario y contraseña
2. Sistema lo valida como usuario y lo envía a
la ventana de ingreso
3. El supervisor ingresa al sistema y se dirige
al monitoreo de estados de gases en la mina.
y selecciona nivel
4. El sistema devuelve datos de los
diferentes sensores.
Curso Normal de los eventos
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
68
Caso de Uso
Actores
Propósito
Tipo
Referencias Cruzadas
Accion de actores Respuesta del sistema
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
Ver predicción
Supervisor
3. El supervisor ingresa al sistema y accesa a
la sección predicción, donde elige nivel. Y la
predicción
4. El sistema obtiene predicciones y las
muestra al supervisor
5. Usa monitorear nivel
Curso Normal de los eventos
1. El caso de uso empieza cuando el
supervisor ingresa al sistema ingresado su
usuario y contraseña
2. Sistema lo valida como usuario y lo envía a
la ventana de ingreso
Figura 40: Caso de uso ver predicción
Caso de Uso
Actores
Propósito
Tipo
Referencias Cruzadas
Accion de actores Respuesta del sistema
Curso Normal de los eventos
Obtener gráficos
Supervisor
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.
5. Supervisor ve los gráficos, y si lo desea
puede imprimirlos o exportarlos a otro
documento
6.- Sistema imprime los gráficos o exporta
los datos a otros archivos como excel o pdf.
1. El caso de uso empieza cuando el
supervisor ingresa al sistema ingresado su
usuario y contraseña
2. Sistema lo valida como usuario y lo envía a
la ventana de ingreso
3. El supervisor ingresa al sistema y accesa a
la sección gráficos, donde elige fecha, tipo de
gráfico, dato a graficar, etc.
4. El sistema devuelve los datos y presenta
la información
Figura 41: Caso de uso obtener gráficos
69
Caso de Uso
Actores
Propósito
Tipo
Referencias Cruzadas
Accion de actores Respuesta del sistema
Generar alertas
WSN
Curso Normal de los eventos
1.- adquisidor envía muestras 2.-Sistema recibe los datos y los analiza. Si
existe muestra fuera de rango crea alerta y
la comunica
Generar las alertas para muestras WSN
Resumen Las muestras son analizadas para determinar si se encuentran
fuera de los rangos para generar alerta
3.- Supervisor ve alerta y realiza click sobre
ella para registrar su conocimiento de esta.
4.- Sistema valida que el supervisor ha sido
informado.
Figura 42: Caso de uso generar alertas
Caso de Uso
Actores
Propósito
Tipo
Referencias Cruzadas
Accion de actores Respuesta del sistema
5.- Administrador ingresa tipo de nodo, los
gases asociados al sensor y su posicion
geográfica y preciona en aceptar
6.- Sistema recibe los datos y crea nuevo
nodo. Para luego enviar mensaje de éxito al
administrador
Agregar nodo
Administrador
Agregar un nuevo nodo sensor en el sistema
Resumen Administrador agrega nuevo nodo sensor que tomará datos en
el sistema.
1.- Administrador inicia sesión con datos de
usuario
2.-Sistema valida al administrador y le
permite el acceso con ermisos de
administrador
3.- Adminsitrador ingresa en tarea de
administrador y hace click en agregar nodo y
selecciona el nivel que quiere.
4.- Sistema obtiene los datos de los nodos
existentes para el nivel.
Curso Normal de los eventos
Figura 43: Caso de uso agregar nodo
70
Caso de Uso
Actores
Propósito
Tipo
Referencias Cruzadas
Accion de actores Respuesta del sistema
5.- Administrador selecciona el nodo a
eliminar y preciona aceptar.
6.- Sistema borra el nodo. Y devuelve al
adminsitrador mensaje de que la operación
fue exitosa
4.- Sistema los nodos del nivel para
presentarlos
Curso Normal de los eventos
Borrar nodo
Administrador
Borrar un nodo ingresado en el sistema
Resumen Administrador Elimina un nodo sensor del sistema .
1.- Administrador inicia sesión con datos de
usuario
2.-Sistema valida al administrador y le
permite el acceso con ermisos de
administrador
3.- Adminsitrador ingresa en tarea de
administrador y hace click en borrar nodo y
selecciona el nivel que quiere.
Figura 44: Caso de uso borrar nodo
Caso de Uso
Actores
Propósito
Tipo
Referencias Cruzadas
Accion de actores Respuesta del sistema
5.- Administrador selecciona el nodo a
eliminar y preciona aceptar.
6.- Sistema borra el nodo. Y devuelve al
adminsitrador mensaje de que la operación
fue exitosa
7.- Administrador actualiza datos del nodo
como sensores asociados, posicion
geográfica, etc: y preciona aceptar
8.- Sistema actualiza nuevos datos y si fue
exitoso devuelve mensaje de éxito
1.- Administrador inicia sesión con datos de
usuario
2.-Sistema valida al administrador y le
permite el acceso con ermisos de
administrador
3.- Adminsitrador ingresa en tarea de
administrador y hace click en actualizar nodo
y selecciona el nivel que quiere.
4.- Sistema los nodos del nivel para
presentarlos
Curso Normal de los eventos
Actualizar nodo
Administrador
Actualiza datos de un nodo ingresado en el sistema
Resumen Administrador actualiza los datos asociados a un nodo sensor
del sistema .
Figura 45: Caso de uso actualizar nodo
71
8.2 TABLAS TIEMPO DE CARGA GOOGLEMAPS
muestra
1
2
3
4
5
6
7
8
9
10
promedio
Tiempo carga google normal
4,31
4,33
4,39
4,21
4,12
4,278
tiempo(s:ms)
4,26
4,18
4,15
4,18
4,65
muestra
1
2
3
4
5
6
7
8
9
10
promedio 13,76
13,66
13,99
13,66
13,62
13,97
Tiempo carga google 1Mb
tiempo(s:ms)
13,63
13,59
13,87
13,62
13,99
Tabla 10: Tabla tiempo de carga Google Maps normal y con archivo de 10Mb
muestra
1
2
3
4
5
6
7
8
9
10
promedio 10,261
10,98
9,98
10,29
10,17
10,01
10,02
10,13
Tiempo carga google 700Kb
tiempo(s:ms)
10,11
10,14
10,78
muestra
1
2
3
4
5
6
7
8
9
10
promedio 9,439
9,57
9,81
9,6
8,97
9,58
9,31
9,54
Tiempo carga google 600Kb
tiempo(s:ms)
9,17
9,05
9,79
Tabla 11: Tabla tiempo de carga Google Maps con archivo de 700Kb y con archivo de 600Kb
72
muestra
1
2
3
4
5
6
7
8
9
10
promedio
5,83
5,811
Tiempo carga google 200Kb
tiempo(s:ms)
5,65
5,63
5,5
5,83
5,7
6,29
6,09
6,04
5,55
Tabla 12: Tabla tiempo de carga Google Maps ara archivo de 200Kb
