Embed Size (px)
Citation preview
UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA
La Universidad Católica de Loja
TITULACIÓN DE INGENIERO EN ELECTRÓNICA Y TELECOMUNICACIONES
Sistema de evacuación a través de dispositivos móviles
Android de adquisición y respuesta de etiquetas RFID para
asistencia en situaciones de emergencia
Trabajo de �n de titulación
AUTORES:
Palacios Arias César Augusto
Rohoden Jaramillo Max Napoleón
DIRECTOR:
Ludeña González Patricia Jeanneth, Ing.
LOJA - ECUADOR
2013
CERTIFICACIÓN
Ing. Patricia Ludeña González,
DIRECTOR DEL PROYECTO DE FIN DE TITULACIÓN
CERTIFICA:
Que el proyecto: Sistema de evacuación a través de dispositivos mó-
viles Android de adquisición y respuesta de etiquetas RFID para asisten-
cia en situaciones de emergencia, realizado por César Augusto Palacios
Arias y Max Napoleón Rohoden Jaramillo; de la titulación de ELEC-
TRÓNICA Y TELECOMUNICACIONES, ha sido dirigido y revisado
en todas sus partes; por lo mismo, cumple con las exigencias y requisi-
tos legales establecidos por la Universidad Técnica Particular de Loja,
quedando autorizada su presentación.
Loja, Enero de 2013
F.�������������
Ing. Patricia Ludeña González
Visto Bueno del Coordinador de Titulación
F.�������������Ing. Jorge Luis Jaramillo Pacheco
COORDINADOR DE LA TITULACIÓN DEELECTRÓNICA Y TELECOMUNICACIONES
Enero, 2013
i
CESIÓN DE DERECHOS
Nosotros, César Augusto Palacios Arias y Max Napoleón Rohoden
Jaramillo; declaramos ser autores del presente trabajo y eximimos ex-
presamente a la Universidad Técnica Particular de Loja y a sus repre-
sentantes legales de posibles reclamos o acciones legales.
Adicionalmente declaramos conocer y aceptar la disposición del Art.
67 del Estatuto Orgánico de la Universidad Técnica Particular de Loja,
que en su parte pertinente textualmente dice: �Forman parte del pa-
trimonio de la Universidad la propiedad intelectual de investigaciones,
trabajos cientí�cos o técnicos y tesis de grado que se realicen a través,
o con el apoyo �nanciero, académico o institucional (operativo) de la
Universidad�.
F.����������� F.�����������
César Augusto Palacios Arias Max Napoleón Rohoden Jaramillo
C.I.: 1104444730 C.I.: 1104868391
ii
AUTORÍA
Las ideas, opiniones, conclusiones, recomendaciones y demás contenido
expuesto en el presente informe de tesis; son de absoluta responsabilidad
de los autores.
Queda expresamente señalado que la información de otros autores in-
cluida en el presente, se encuentra debidamente citada en las fuentes de
referencia y bibliografía.
F.����������� F.�����������
César Augusto Palacios Arias Max Napoleón Rohoden Jaramillo
C.I.: 1104444730 C.I.: 1104868391
iii
DEDICATORIA
Dedico este trabajo a mi familia por el apoyo brindado para culminar
esta titulación, y también a aquellos estudiantes que encuentren en este
trabajo ayuda y motivación para mejorarlo.
Max
A mis padres y hermanos
Por el apoyo que me brindaron durante la realización de este tra-
bajo, por los consejos y motivación durante toda mi educación tanto,
académica, como de la vida. Porque gracias a ellos ha sido posible este
trabajo.
A mis amigos
Por ser parte de mi vida y manifestar su apoyo, por estar en todos
los momentos. Por ser los compañeros durante todos estos años y porque
seguimos siendo amigos.
César Augusto
iv
AGRADECIMIENTO
Mi agradecimiento a aquellos profesores que dentro como fuera del
aula, durante estos cinco años, fortalecieron el deseo de aprendizaje. En
especial, a nuestra directora de tesis por facilitarnos la infraestructura y
elementos para desarrollar este trabajo.
Al in�nito laberinto de las causas y de los efectos
Max
A quienes me inculcaron los valores para mantener la constancia en
el estudio, por motivarme a conseguir los objetivos y por ser compañeros
cada día.
A los profesores que estuvieron detrás de todo lo aprendido, y la di-
rectora del proyecto quien guió nuestro trabajo durante todo este tiempo.
Gracias de corazón.
César Augusto
v
Índice general
CERTIFICACIÓN i
CESIÓN DE DERECHOS ii
AUTORÍA iii
DEDICATORIA iv
AGRADECIMIENTO v
Índice de �guras x
Índice de tablas xiii
Resumen xiv
1. ALCANCE DE LA INVESTIGACIÓN 1
1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2. Objetivos Especí�cos . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Justi�cación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. MARCO REFERENCIAL 3
2.1. Sistema de comunicación de campo cercano por radiofrecuencia . . . 3
2.1.1. Comunicación de campo cercano . . . . . . . . . . . . . . . . . 3
2.1.2. Identi�cación por radiofrecuencia . . . . . . . . . . . . . . . . 4
2.1.2.1. Elementos de un sistema RFID . . . . . . . . . . . . 4
2.1.2.2. Frecuencias de funcionamiento . . . . . . . . . . . . 5
2.1.2.3. Estandarización para sistemas RFID . . . . . . . . . 6
2.2. Tecnología RFID en dispositivos móviles . . . . . . . . . . . . . . . . 7
2.3. Desarrollo de aplicaciones para dispositivos móviles . . . . . . . . . . 7
2.3.1. Desarrollo de aplicaciones para dispositivos móviles Apple . . 8
vi
ÍNDICE GENERAL
2.3.1.1. Funcionamiento de una aplicación nativa Apple . . . 8
2.3.2. Desarrollo de aplicaciones Android . . . . . . . . . . . . . . . 9
2.4. Estado del Arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.2. Estudio de una situación de emergencia . . . . . . . . . . . . . 12
2.4.3. Aplicaciones con RFID en dispositivos móviles . . . . . . . . . 13
2.4.4. Desarrollo de aplicaciones para situaciones de emergencia . . . 16
2.4.4.1. Aplicación desarrollada en la Universidad de Udine . 17
2.4.4.2. Aplicación RescueMe . . . . . . . . . . . . . . . . . . 18
2.4.4.3. Desarrollos de la Universidad de Karabuk . . . . . . 19
2.4.5. Situación de aplicaciones en dispositivos móviles para locali-
zación en interiores . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.5.1. Aplicación móvil para localización en interiores ba-
sada en sistemas de localización geográ�ca . . . . . . 22
2.4.5.2. LANDMARC: Localización en interiores utilizando
RFID Activas . . . . . . . . . . . . . . . . . . . . . . 23
2.4.5.3. Sistema de rastreo móvil RFID . . . . . . . . . . . . 23
3. MATERIALES Y MÉTODOS 25
3.1. Metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2. Selección de materiales . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.1. Materiales para la red de sensores . . . . . . . . . . . . . . . . 27
3.2.2. Montaje del servidor Web . . . . . . . . . . . . . . . . . . . . 28
3.2.2.1. Software para la Base de Datos . . . . . . . . . . . . 28
3.2.2.2. Preparación de la Base de Datos MySQL . . . . . . . 29
3.2.2.3. Software para la Aplicación Web . . . . . . . . . . . 29
3.2.2.4. Preparación del software para la Aplicación Web . . 30
3.2.2.5. Generación del servicio web en Netbeans . . . . . . . 30
3.2.3. Desarrollo de Aplicación móvil Android . . . . . . . . . . . . . 32
3.2.3.1. Software para desarrollo aplicaciones Android . . . . 32
3.2.3.2. Entornos de desarrollo de aplicaciones Android . . . 32
3.2.3.3. Selección del programa para desarrollo de aplicacio-
nes Android . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.3.4. Preparación del IDE Eclipse . . . . . . . . . . . . . . 34
3.2.3.5. Consumo del servicio web desde el dispositivo móvil . 35
3.2.3.6. Retrasos en aplicaciones Android . . . . . . . . . . . 36
3.2.3.7. Tiempos de retraso de la aplicación de evacuación
Android/RFID . . . . . . . . . . . . . . . . . . . . . 36
vii
ÍNDICE GENERAL
3.2.3.8. Tiempo de puesta en marcha de la aplicación . . . . 37
3.2.3.9. Tiempo de reconocimiento del módulo de lectura RFID 37
3.2.3.10. Tiempo de lectura de una tarjeta . . . . . . . . . . . 38
3.2.3.11. Tiempo de actualización de la posición en el plano
según la etiqueta RFID . . . . . . . . . . . . . . . . 38
3.2.3.12. Tiempo de actualización del ícono de orientación . . 38
3.2.3.13. Tiempo de recepción de alarmas de fuego y sugeren-
cias de evacuación . . . . . . . . . . . . . . . . . . . 38
3.2.3.14. Tiempo de ejecución de una llamada de emergencia . 39
3.2.4. Prototipo de lectura de etiquetas RFID y dispositivo móvil . . 39
3.2.4.1. Características Lógicas . . . . . . . . . . . . . . . . . 39
3.2.4.2. Características Físicas . . . . . . . . . . . . . . . . . 40
3.2.5. Montaje del sistema de evacuación . . . . . . . . . . . . . . . 40
3.2.5.1. Características, alcances y limitaciones . . . . . . . . 40
3.2.6. Modelado de la infraestructura . . . . . . . . . . . . . . . . . 43
3.2.6.1. Ubicación de sensores . . . . . . . . . . . . . . . . . 44
3.2.6.2. Ubicación de tarjetas RFID . . . . . . . . . . . . . . 44
3.3. Pruebas y optimización del sistema de evacuación . . . . . . . . . . . 45
3.3.1. Prueba al desempeño de la aplicación . . . . . . . . . . . . . . 45
3.3.1.1. Aplicación simple . . . . . . . . . . . . . . . . . . . . 47
3.3.1.2. Aplicación Framework . . . . . . . . . . . . . . . . . 48
3.3.1.3. Aplicación Compleja . . . . . . . . . . . . . . . . . . 48
3.3.1.4. Clasi�cación UTC de la aplicación . . . . . . . . . . 50
3.3.2. Procedimientos para las pruebas al sistema . . . . . . . . . . . 50
3.3.2.1. Procedimiento para la evaluación a la red de sensores 51
3.3.2.2. Procedimiento para evaluación de Servidor Web . . . 52
3.3.2.3. Procedimientos para evaluación de la Aplicación An-
droid . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3.2.4. Procedimiento para evaluación del sistema de loca-
lización RFID . . . . . . . . . . . . . . . . . . . . . . 53
3.3.2.5. Análisis al Sistema de Evacuación RFID . . . . . . . 53
4. ANÁLISIS DE RESULTADOS 54
4.1. Red de sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2. Servidor Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.3. Aplicación Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.4. Evaluación al sistema de localización RFID . . . . . . . . . . . . . . . 56
4.5. Análisis al sistema de evacuación . . . . . . . . . . . . . . . . . . . . 57
viii
ÍNDICE GENERAL
4.5.1. Tiempo máximo de actualización de las alarmas . . . . . . . . 57
4.5.2. Etiquetas RFID en la localización . . . . . . . . . . . . . . . . 58
4.5.3. Alarmas mostradas en el teléfono . . . . . . . . . . . . . . . . 59
4.5.3.1. Resultados al activar alertas simultáneamente . . . . 59
4.5.3.2. Comportamiento del sistema de evacuación al acti-
varse todas las alarmas . . . . . . . . . . . . . . . . . 60
4.5.4. Comportamiento del sistema de evacuación con alarmas en
diferentes pisos del edi�cio . . . . . . . . . . . . . . . . . . . . 60
4.6. Selección de tecnologías para el sistema de evacuación en un edi�cio 61
5. CONCLUSIONES Y TRABAJO FUTURO 67
5.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.2. Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.3. Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
BIBLIOGRAFÍA 72
ANEXOS 75
A. Acondicionamiento del dispositivo móvil para funcionamiento con
el módulo de lectura RFID 76
A.1. Conexión física de los dispositivos . . . . . . . . . . . . . . . . . . . . 76
A.2. Conexión lógica de los dispositivos . . . . . . . . . . . . . . . . . . . 77
A.2.1. Instalación de librerías D2XX JNI . . . . . . . . . . . . . . . . 78
A.2.2. Cambiar permisos para el funcionamiento de Usb Host . . . . 78
A.3. Funcionamiento del módulo RFID conectado al móvil . . . . . . . . . 78
B. Código de programación del microcontrolador 80
C. Paper 82
ix
Índice de �guras
2.1. Sistema RFID básico . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Frecuencias de funcionamiento de RFID . . . . . . . . . . . . . . . . 5
2.3. Capas del sistema operativo móvil de Apple[11] . . . . . . . . . . . . 8
2.4. Bloques básicos de una aplicación para Android [12] . . . . . . . . . . 9
2.5. Línea temporal del desarrollo de evacuación de una emergencia . . . . 13
2.6. Ejemplo de aplicación RFID-reader-equipped mobile phone [17] . . . 14
2.7. Modelo de comunicación de datos RFID [16] . . . . . . . . . . . . . . 14
2.8. Adaptador iCarte para iPhone de la empresa Wireless Dynamics[19] . 15
2.9. Adaptador MINI ME RFID Reader para Android de la empresa MTI
[20] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.10. Modelo de realidad aumentada del edi�cio [2] . . . . . . . . . . . . . 17
2.11. Aplicación RescueMe en uso: mapa 3D y 2D [3] . . . . . . . . . . . . 19
2.12. Simulación en Software de la aplicación RescueMe: casos de distribu-
ción de personal [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.13. Sistema de evacuación óptimo [4] . . . . . . . . . . . . . . . . . . . . 21
2.14. PDA Display [22] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.15. Lector y etiquetas RFID utilizadas en el prototipo LANDMARC[23] . 23
2.16. Arquitectura de sistema de rastreo por RFID [24] . . . . . . . . . . . 24
3.1. Fase experimental del sistema de evacuación . . . . . . . . . . . . . . 26
3.2. Sensor de temperatura LM35 . . . . . . . . . . . . . . . . . . . . . . 27
3.3. Módulo de acondicionamiento de señales de los sensores . . . . . . . . 28
3.4. Sistema de Gestión de Base de Datos MySQL . . . . . . . . . . . . . 29
3.5. Base de datos MySQL y conexión JDBC . . . . . . . . . . . . . . . . 30
3.6. Primefaces: librería para la aplicación web . . . . . . . . . . . . . . . 30
3.7. Extensiones añadidas a la Aplicación web . . . . . . . . . . . . . . . . 31
3.8. Generación del servicio web . . . . . . . . . . . . . . . . . . . . . . . 31
3.9. Selección de la base de datos para generar el servicio web . . . . . . . 32
3.10. Eclipse Indigo: IDE seleccionado para desarrollo de la aplicación An-
droid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
x
ÍNDICE DE FIGURAS
3.11. Paquete ADT para Windows . . . . . . . . . . . . . . . . . . . . . . . 34
3.12. Paquetes importados a la aplicación Android/RFID . . . . . . . . . . 35
3.13. Paquetes importados para consultar el servicio web . . . . . . . . . . 35
3.14. Código para consumir el servicio web . . . . . . . . . . . . . . . . . . 36
3.15. Mensaje Android ANR . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.16. Pantalla de inicio de la Aplicación . . . . . . . . . . . . . . . . . . . . 37
3.17. Trama de envío de datos de la tarjeta RFID . . . . . . . . . . . . . . 40
3.18. Montaje del prototipo: captura lateral . . . . . . . . . . . . . . . . . 41
3.19. Respaldo de las lecturas de los sensores . . . . . . . . . . . . . . . . . 42
3.20. Página de ingreso y autenticación . . . . . . . . . . . . . . . . . . . . 42
3.21. Lectura en tiempo real de los sensores . . . . . . . . . . . . . . . . . . 43
3.22. Grá�co Temperatura vs Tiempo de los sensores . . . . . . . . . . . . 43
3.23. Planos de los pisos del edi�cio con detalle de las zonas de peligro . . . 44
3.24. Maqueta para probar el sistema de evacuación . . . . . . . . . . . . . 45
3.25. Sensores piso superior de la maqueta . . . . . . . . . . . . . . . . . . 46
3.26. Sensores piso inferior de la maqueta . . . . . . . . . . . . . . . . . . . 47
3.27. Ubicación de tarjetas RFID en la parte posterior de la maquetas . . . 48
4.1. Formato de datos enviados desde el microcontrolador . . . . . . . . . 54
4.2. Trama en notación JSON generada de una alerta . . . . . . . . . . . 55
4.3. Lectura de etiquetas RFID para localización . . . . . . . . . . . . . . 58
4.4. Alerta generada en el servidor . . . . . . . . . . . . . . . . . . . . . . 59
4.5. Alerta vista desde la aplicación Android . . . . . . . . . . . . . . . . 59
4.6. Aplicación móvil, situación de dos alertas activadas . . . . . . . . . . 60
4.7. Captura de pantalla de la aplicación, todas las alertas activadas . . . 61
4.8. Aplicación móvil, alerta en el piso inferior . . . . . . . . . . . . . . . 62
4.9. Aplicación móvil, alerta en escaleras del piso inferior . . . . . . . . . 63
4.10. Botón de emergencia SS075Q de la empresa SECOALARM . . . . . . 63
4.11. Botón de pánico YA-01 de la empresa VSTAR . . . . . . . . . . . . . 64
4.12. Sensor de humo con salidas analógicas de la empresa ISOLSE . . . . 64
4.13. Sensor de humo con salidas digitales de la empresa ISOLSE . . . . . 65
4.14. Sensor detector de fuego . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.15. Etiqueta pasiva RFID de largo alcance CF-TU9101 . . . . . . . . . . 66
4.16. Etiqueta RFID activa modelo YL-702 . . . . . . . . . . . . . . . . . . 66
4.17. Módulo de lectura/escritura RFID de largo alcance . . . . . . . . . . 66
A.1. Cableado para conectores tipo USB normal y USB modo OTG . . . . 77
A.2. a) módulo de lectura ID-20. b)Placa de montaje RFID USB con in-
terfaz mini USB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
xi
ÍNDICE DE FIGURAS
A.3. Captura de pantalla de la aplicación Android para el módulo de lec-
tura RFID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
xii
Índice de tablas
3.1. Bloques de la fase experimental . . . . . . . . . . . . . . . . . . . . . 26
3.2. IDE's para desarrollo de aplicaciones Android . . . . . . . . . . . . . 33
3.3. Características del módulo de lectura RFID . . . . . . . . . . . . . . 40
3.4. Cantidad tarjetas, etiquetas RFID y sensores por piso . . . . . . . . . 45
3.5. Test para aplicaciones Simples y Framework . . . . . . . . . . . . . . 49
3.6. Test aplicables a la aplicación Android/RFID . . . . . . . . . . . . . 51
4.1. Resultado de tests UTI a la aplicación Android RFID . . . . . . . . . 56
xiii
Resumen
En el presente proyecto se desarrolla un sistema de evacuación a través de dispo-
sitivos móviles Android para asistencia personalizada en situaciones de emergencia.
Se accede al sistema por medio de una aplicación móvil, la cual indica al usuario su
ubicación dentro del edi�cio y la ruta más corta y segura de evacuación. El usuario
recibe las indicaciones a través de planos 2D con rutas de evacuación actualizables
y por medio de mensajes indicándole qué lugares evitar y cuál salida tomar.
El sistema integra varias tecnologías y lenguajes de programación para que la
evacuación sea e�ciente. Para la ubicación del usuario dentro del edi�cio se usa la
tecnología RFID ubicando etiquetas en pasillos, escaleras y salidas de emergencia
y acoplando un módulo de lectura RFID al dispositivo móvil. Para la actualización
periódica de las rutas y mensajes de evacuación se instalaron sensores en pasillos
y o�cinas, y se conectaron a un servidor, por medio de un módulo de adquisición,
para que éste inalámbricamente actualice los datos del dispositivo móvil.
xiv
1
ALCANCE DE LA
INVESTIGACIÓN
1.1. Objetivos
1.1.1. Objetivo General
Desarrollar un sistema de evacuación a través de dispositivos móviles Android
de adquisición y respuesta de tarjetas RFID para asistencia en situaciones de emer-
gencia.
1.1.2. Objetivos Especí�cos
1. Redactar el estado del arte relacionado con los sistemas de evacuación en
dispositivos móviles.
2. Desarrollar la interfaz dispositivo móvil-lector RFID (hardware-software).
3. Determinar las características del prototipo y los escenarios de prueba para la
aplicación.
4. Desarrollar el sistema de evacuación en base a módulos para localización en
interiores, direccionamiento, actualización de rutas y mensajes de evacuación.
5. Demostrar el funcionamiento del sistema de evacuación en un modelo a escala
del edi�cio.
6. Realizar pruebas y optimizar el prototipo, de�niendo tiempos de actualización
y respuesta.
7. Analizar los resultados obtenidos.
1
1.2 Justi�cación
1.2. Justi�cación
La evacuación de un determinado lugar (edi�cios, fábricas, supermercados) en
caso de emergencia (un incendio, terremotos, o inundaciones) ha constituido des-
de tiempo atrás una preocupación continua para el sector la seguridad ciudadana.
Existen varios análisis académicos de situaciones de evacuación desde los más bási-
cos, como el de metodología estática, hasta los que han arrojado mejores resultados,
como el de metodología de modelado [1].
Este interés por los sistemas de evacuación se ha visto re�ejado en varios pro-
yectos de desarrollo de aplicaciones móviles para los ocupantes dentro de un edi�cio
[2] [3] [4] [5]. Estos proyectos estudian una falencia de los procesos de evacuación
e incluso de la infraestructura, y en base a ésta desarrollan una aplicación móvil
que facilite la salida de los ocupantes hacía una zona segura, en una situación de
emergencia. Algunas de estas aplicaciones requieren de montaje de infraestructura
costosa en el edi�cio, mientras que, otras sólo hacen uso de los sensores propios del
teléfono móvil.
La mayoría de estos proyectos de evacuación citados se desarrollan en países del
primer mundo, en donde, el índice de penetración del Internet es alto. En la Unión
Europea (UE) la media de este índice es del 68%1. En Ecuador, según estadísticas
del INEC (Instituto Nacional de Estadísticas y Censos) a Diciembre del 2011, el
31.4% de la población utilizó Internet. De este grupo un 62.5% lo hizo fuera de sus
hogares, es decir, en centros de acceso público, en instituciones educativas y en el
trabajo; lugares adecuados para la aplicación de un sistema de evacuación basado
en dispositivos móviles[6]. Por otro lado, sólo un 8,4% de los ecuatorianos, que
tienen un teléfono celular activo (46.6%), poseen un smartphone, es decir, menos
de la media de Latinoamérica (17%)2 y muy por debajo de la media comunitaria de
banda ancha móvil en la UE (43.1%). Sin embargo, la tendencia en Latinoamérica
es reducir la brecha digital con los países del primer mundo y subsecuentemente la
implementación de los sistemas tecnológicos más avanzados, como son los sistemas
de evacuación basados en dispositivos móviles.
Se propone un sistema de evacuación que incorpore varias tecnologías, logrando
un balance entre precisión de ubicación y costo de montaje. El sistema integra
la plataforma de desarrollo Android, tecnología RFID para la localización, red de
sensores para la actualización de las rutas de evacuación e interfaz grá�ca en base a
planos del edi�cio.
1http://www.rtve.es/noticias/20120618/espana-entre-paises-mas-caros- mayor-penetracion-internet-movil-ue/537595.shtml
2http://www.coberturadigital.com/2012/02/16/internet-en-ecuador-smartphones-ganan-terreno/
2
2
MARCO REFERENCIAL
2.1. Sistema de comunicación de campo cercano por
radiofrecuencia
2.1.1. Comunicación de campo cercano
Los sistemas de comunicación de campo cercano conocidos por sus siglas en In-
glés como NFC (Near Field Communications), son una forma de comunicación sin
contacto entre dispositivos como smartphones o tablets. Permiten el intercambio de
información a través de ondas de radio frecuencia (RF) facilitando las transacciones
electrónicas, intercambio de contenido digital, y la conexión entre dispositivos. Es
una evolución de las tecnologías originalmente usadas para identi�cación por radio
frecuencia o RFID (Radio Frecuency IDenti�cation) y los sistemas de pago elec-
trónico. Las especi�caciones para las tarjetas de identi�cación, de proximidad y de
circuitos integrados RFID las dicta el estándar ISO/IEC 144431.
NFC conserva la interoperabilidad entre diferentes métodos de comunicación
inalámbrica, tales como Bluetooth u otros estándares NFC como FeliCa2. El NFC
Forum3, fundado en 2004 por Sony, Nokia y Philips, es el organismo internacional que
hace cumplir estrictamente los estándares de NFC con el �n de obtener dispositivos
completamente compatibles [7].
Los sistemas de comunicación NFC constan de dos elementos: un dispositivo
maestro y otro esclavo. El dispositivo maestro es un módulo de lectura, y el esclavo,
etiquetas NFC que almacenan la información codi�cada.
1http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?
csnumber=396932FeliCa es el sistema NFC desarrollado por Sony para Japón http://www.felicanetworks.
co.jp/en/3http://www.nfc-forum.org
3
2.1 Sistema de comunicación de campo cercano por radiofrecuencia
El lector es capaz de identi�car las etiquetas cercanas por ondas de radio y
además de diferenciar el tipo de comunicación de campo cercano de la que se trate. La
etiqueta se activa con la presencia del campo RF, el lector establece la comunicación
usando el esquema de modulación, codi�cación a nivel de bit, velocidad de bit, y
otros parámetros asociados con los métodos de señalización [8].
La comunicación entre sistemas NFC es activa o pasiva. Activa, en donde ambos
generan sus propios campos electromagnéticos, o de manera pasiva, en donde un
dispositivo genera el campo RF y el otro elemento se activa por inducción.
2.1.2. Identi�cación por radiofrecuencia
La tecnología RFID es una aplicación especí�ca de los sistemas NFC, usada en
sistemas de identi�cación de personas, animales, vehículos o accesorios. Se aplica
también en sistemas de localización y rastreo de mercancía. Los sistemas RFID
permiten la identi�cación de manera inalambríca y sin necesidad de línea de vista
directa [9]. Esta identi�cación se logra al incorporar un transpondedor al objeto, el
cual transmite los datos que contiene al ser interrogada por un lector RFID.
Aunque la aplicación natural de la tecnología es dentro de la cadena de pro-
ducción y distribución, aparecen, cada día, nuevas aplicaciones y oportunidades de
negocio alrededor de las variantes de uso de esta tecnología y su incorporación dentro
de sistemas.
2.1.2.1. Elementos de un sistema RFID
Un sistema RFID básico se forma, cómo se ve en la �gura 2.1, por un lector con
una o más antenas, etiquetas de identi�cación y software que realice el procesamiento
de la información recogida por los lectores [10].
Figura 2.1: Sistema RFID básico
4
2.1 Sistema de comunicación de campo cercano por radiofrecuencia
Las etiquetas RFID mantienen la unicidad de código identi�cador, es decir un
número único, registrado en el EPC (Electronic Product Code), que identi�ca de
manera inequívoca cualquier objeto, garantizando la interoperabilidad de sistemas.
2.1.2.2. Frecuencias de funcionamiento
La frecuencia de trabajo de las etiquetas está estrechamente relacionado con sus
características físicas, es decir, que al aumentar la frecuencia de operación se hace
uso de antenas y circuitos integrados más pequeñas, posibilitando así, la reducción
de costos de producción. Además, condiciona la propagación del campo electro-
magnético, afectando a la distancia máxima de lectura, velocidad de transmisión,
sensibilidad de los materiales, incluso limitando las aplicaciones comerciales para las
que se puede utilizar la tecnología RFID. Esto se lo puede apreciar en la �gura 2.2:
Figura 2.2: Frecuencias de funcionamiento de RFID
Dependiendo de la frecuencia, la comunicación entre el lector y la antena de la
etiqueta, puede darse por, acoplamiento inductivo o acoplamiento capacitivo [10]. El
acoplamiento inductivo se usa en las bajas (LF) y altas frecuencias (HF). El campo
magnético que genera la corriente en la antena del lector, induce una corriente en la
antena de la etiqueta, que alimenta el circuito y conmuta la impedancia de carga de
su antena para crear una modulación y poder transmitir los datos. El acoplamiento
capacitivo se usa para frecuencias UHF y microondas. El lector envía una señal RF
que la etiqueta recibe, modula y re�eja hacía el lector. Dependiendo si las etiquetas
son pasivas o activas, tomarán de la señal su alimentación o no.
5
2.1 Sistema de comunicación de campo cercano por radiofrecuencia
2.1.2.3. Estandarización para sistemas RFID
Numerosos organismos regulatorios in�uyen en la estandarización de la tecnolo-
gía RFID. La ISO (International Organization for Standardization1) de�ne algunos
estándares, a nivel comercial e industrial, para las aplicaciones y rangos de frecuen-
cia de la tecnología RFID. La IEC (International Electrotechnical Commission), en
cambio, impulsa la cooperación internacional para la estandarización en los campos
de la electrónica y tecnología. Entre algunas de las normas de ambas organizaciones,
tenemos:
ISO 11784 e ISO 11785: Identi�cación animal por radiofrecuencia. Estructuras
de código y conceptos técnicos
ISO/IEC 14443: Tarjetas de identi�cación, tarjetas con circuitos integrados y
tarjetas de proximidad.
ISO/IEC 18000: RFID para gestión de artículos. Contiene la descripción de
los diferentes rangos de frecuencia y las aplicaciones.
ISO/IEC TR 18046: Métodos para pruebas de rendimiento para dispositivos
RFID.
El estándar en que se basa el sistemas de evacuación RFID es el ISO/IEC 14443.
Una organización que apoya la industria RFID, es EPCGlobal, la cual establece
y mantiene la red EPCGlobal (EPCGlobal Network) como estándar mundial para
identi�cación automática de objetos.
Entre los estándares para RFID podemos mencionar:
Formato lógico de los datos en una etiqueta EPC.
Protocolo de comunicación:
• Clase 0 a 900 MHz.
• Clase 1 a 13,56 MHz.
• Clase 1 para el rango de 860 MHz a 930 MHz.
La especi�cación ONS (Object Name Service), para la red global, que retiene
la información sobre cualquier objeto etiquetado con EPC en el mundo.
1http://www.iso.org/iso/home.html
6
2.2 Tecnología RFID en dispositivos móviles
2.2. Tecnología RFID en dispositivos móviles
Los avances en cuanto a diseño de microchips da lugar a completos circuitos
en dispositivos muy pequeños permitiendo incorporar sensores en smartphones y
tablets. Esta tendencia representa un avance signi�cativo en cuanto a obtención de
información directamente digitalizada, es así que, se puede estar al tanto del clima
de cualquier parte del mundo en cuestión de segundos. Esta idea se amplía más aún
con la incorporación de la tecnología RFID en smartphones y tablets, que permitiría
saber no únicamente información del clima sino, la identi�cación de personas, la
ubicación, rastreo de objetos, manejo de inventarios, etc.
Samsung1 la principal compañía de venta de dispositivos de última generación
bajo la plataforma Android, ha lanzado a la venta algunos smartphones con la
tecnología NFC incorporada; por mencionar algunos están los Nexus 4 y Nexus 7,
Galaxy S III2 y Galaxy Note. Otras empresas como LG tienen en el mercado los de
la versión Optimus L5 y Optimus L7, por su parte Sony también a lanzado los de
la gama Xperia con la tecnología NFC.
Algunas de las aplicaciones móviles desarrolladas para interacción con NFC son
NFC TagInfo y NFC TagWriter. La primera permite visualizar en la pantalla del
teléfono, el código de cualquier etiqueta NFC y la segunda permite la lectura y
escritura de etiquetas NFC activas.
Para los dispositivos que no traen incorporada la tecnología NFC o RFID, se han
desarrollado librerías especí�cas las cuales pueden incorporarse a las aplicaciones,
mientras que la conexión con los dispositivos se logra por el puerto USB.
2.3. Desarrollo de aplicaciones para dispositivos mó-
viles
Dada la importante demanda y buena acogida que han tenido los teléfonos inteli-
gentes, muchas compañías han desarrollado sus propias plataformas sobre las cuales
montan sus aplicaciones, así es el caso de Nokia con su plataforma Symbian, Google
con Android, Apple con IOS. La plataforma Android, no requiere que el desarrolla-
dor tenga un alto nivel de conocimiento de programación para realizar una aplicación
básica. Se han lanzado al mercado opciones como App Inventor3 desarrollado por
programadores del MIT4, tan fácil de usar como arrastrar bloques para diseñar una
1http://www.samsung.com/latin/aboutsamsung/2http://www.samsung.com/latin/consumer/mobile-phones/mobile-phones/smartphone/
GT-I9300MBLTTT3http://appinventor.mit.edu/4Massachusetts Institute of Technologyhttp://www.mit.edu/
7
2.3 Desarrollo de aplicaciones para dispositivos móviles
aplicación Android básica. Para aplicaciones especializadas o de mayor complejidad
comúnmente se utiliza algún IDE (Integrated Development Environment) de Java,
como puede ser Eclipse Indigo o Netbeans.
2.3.1. Desarrollo de aplicaciones para dispositivos móviles
Apple
Las aplicaciones para Iphone o Ipad funcionan en el sistema operativo móvil de
Apple, conocido como iOS (iPhone Operating System). Pueden desarrollarse de dos
maneras: mediante aplicación web o como aplicación nativa. Mediante aplicación
web, consiste en una aplicación desarrollada en HTML, CSS, JavaScript, que fun-
ciona en un servidor al cual el smartphone puede tener acceso y visualizar mediante
el código HTML generado por PHP, NET o Java. Las aplicaciones nativas en cambio
son aquellas que vienen con los dispositivos electrónicos o que pueden ser compra-
das o descargadas libremente desde el AppStore. Son desarrolladas con el SDK de
Iphone, denominado xCode en Objetive C [11].
2.3.1.1. Funcionamiento de una aplicación nativa Apple
Apple proporciona la imagen de la �gura 2.3 para entender más fácilmente el
funcionamiento de una aplicación para IOS.
Figura 2.3: Capas del sistema operativo móvil de Apple[11]
Cada capa corresponde a los elementos con los que trabajan iPhone y iPad:
Cocoa Touch.- corresponde al Framework de desarrollo, es la capa en la que
se realiza la aplicación en sí.
Media.- Contiene todos los archivos que la aplicación tendrá, es decir, audio,
video, imágenes, soporte para grá�cos 3D OPENGL ES, etc.
8
2.3 Desarrollo de aplicaciones para dispositivos móviles
Core Services.- Provee los servicios fundamentales para la aplicación, por ejem-
plo acceso a contactos, o base de datos SQLITE, etc.
Core OS.- Es el núcleo del sistema operativo, gestiona archivos, memoria,
seguridad y comunicación.
2.3.2. Desarrollo de aplicaciones Android
Android utiliza de base el Kernel de Linux , debido a su robustez y la implementa-
ción de funciones básicas para otros sistemas operativos, tales funciones pueden ser:
seguridad, administración de memoria y procesos, implementación de conectividad
de red y varios controladores para comunicación con dispositivos físicos [12].
El desarrollo de aplicaciones para Android se resume en bloques básicos que se
muestran en la �gura 2.4. Los componentes básicos de una aplicación son activida-
des, intentos, vistas, servicios, proveedores de contenido y receptores de broadcast;
convencionalmente se utiliza la traducción al inglés de los términos por la compa-
tibilidad con los lenguajes de programación, es decir que se pre�ere los términos:
activities, intents, views, services, content providers y broadcast receivers.
Figura 2.4: Bloques básicos de una aplicación para Android [12]
A continuación se describe cada bloque constituyente de la aplicación 1.
1http://developer.android.com/guide/components/fundamentals.html
9
2.3 Desarrollo de aplicaciones para dispositivos móviles
Activities: Es una ventana que representa cada una de las pantallas de la
aplicación. Por ejemplo, una pantalla de bienvenida al iniciar la aplicación,
sería una activity.
Intents: son mensajes utilizados para lanzar operaciones a mitad de procesos,
pueden ser noti�caciones, sonidos, etc.
Views: son los componentes de la interfaz de usuario. Dependiendo del IDE
de Java se puede utilizar directamente archivos XML para elaborar las vistas
de la aplicación.
Services: son las operaciones que pueden desarrollarse en segundo plano sin
la necesidad de tener una interfaz de usuario. Un ejemplo son las aplicaciones
que consumen recursos de Internet.
Content Providers: corresponde al acceso que se puede tener a información
en el teléfono como son los archivos de audio, video, contactos, etc.
Manifest: es el archivo que contiene la con�guración de la aplicación, en ella
se agrega las activities y sus propiedades, además se puede asignar permisos
a la aplicación para acceder a información de contactos, de Internet, a datos
del usuario, etc.
10
2.4 Estado del Arte
2.4. Estado del Arte
2.4.1. Introducción
Desde la aparición de los PDA (Personal Digital Assistant) y de los teléfonos
inteligentes en la década de los 90 y en el año 2000, respectivamente, su popularidad
ha crecido vertiginosamente a la par que su precio es algo más razonable y la aproba-
ción del público en general cada vez es más favorable. Se suma a esto las numerosas
aplicaciones y servicios a los cuales se puede acceder desde estos dispositivos: GPS,
banca electrónica, correo electrónico, redes sociales, pago de servicios básicos (elec-
tricidad agua potable), consulta del estado meteorológico, aviso de desastres, etc.
Una proyección en el futuro nos deja claro como muchas compañías, hospitales, nego-
cios y centros comerciales con�arán en los teléfonos inteligentes y, subsecuentemente,
dependerán de éstos para su mejor funcionamiento.
Un factor clave en el desarrollo de estos sistemas es la posibilidad de que el usua-
rio o un grupo de desarrolladores de software puedan crear sus propias aplicaciones.
De esta manera, el tiempo que demora una aplicación en salir al mercado es me-
nor y su utilidad más especí�ca, porque se crea para una necesidad determinada.
Más aún, cuando se integran estos sistemas con etiquetas RFID, el resultado es un
conjunto de aplicaciones que permiten controlar y monitorear tareas en tiempo real.
La tendencia es convertir los dispositivos móviles en sensores disponibles todo el
tiempo, interactuando entre sí y con el ambiente, realizando recolección de datos los
cuales permitirán acciones con o sin la intervención humana a ciertos eventos. Dicha
tendencia incluye también la reducción de tiempo de obtención de información y de
procesos.
Lo mencionado se agrupa en un concepto conocido como el Internet de las Cosas
(IoT, Internet of Things); el cual consiste en que los objetos etiquetados tengan
conexión a Internet en cualquier momento y lugar. Técnicamente, es la integración
de sensores y dispositivos en objetos cotidianos de modo que puedan estar conectados
a Internet a través de redes �jas o móviles. De este modo se podrá pensar en sistemas
de actualización de información, mediante sensores, cualquier momento del día.
Siguiendo estos conceptos, se ha desarrollado un sistema de localización dentro de
un edi�cio, capaz de dar a conocer al usuario las rutas de evacuación e información
adicional para situaciones de emergencia. El objetivo del sistema es que las personas
que laboran en el edi�cio, como las que no, se entrenen y afronten una situación de
emergencia únicamente haciendo uso de la aplicación en su celular y basándose en
información verídica y en tiempo real.
11
2.4 Estado del Arte
2.4.2. Estudio de una situación de emergencia
En esta sección del estado del arte realizamos un recuento breve de algunos
estudios e investigaciones que se han realizado sobre las situaciones de emergencia
dentro de un edi�cio, especí�camente incendios, y los factores que afectan a los
ocupantes en la evacuación del mismo.
La principal prioridad en un edi�cio ante una situación de emergencia es que la
totalidad de los ocupantes puedan desplazarse hasta un lugar seguro en el mínimo
tiempo con las mínimas garantías de seguridad. Este tiempo de evacuación (Tevac)
se de�ne en [13] según la siguiente fórmula:
Tevac = (Tdet + Tresp + Tdesp)
Donde:
Tevac : tiempo de evacuación.
Tdet : tiempo de detección.
Tresp : tiempo de pre-movimiento (respuesta de los usuarios).
Tdesp : tiempo de desplazamiento.
Cada una de éstas variables se de�nen como:
Tiempo de detección: tiempo que tarda el sistema de detección en activar e ini-
ciar la secuencia de noti�cación de alarma.
Tiempo de respuesta: tiempo que tardan los ocupantes en empezar a moverse
hacia las rutas de evacuación.
Tiempo de desplazamiento: tiempo que tardan los ocupantes en evacuar la zona
y llegar a un lugar seguro
Estos valores de tiempo y algunos conceptos relacionados en [14] se detallan en
la �gura 2.5.
Existen otros factores que pueden aumentar signi�cativamente estos valores. La
forma en que el ocupante elige la ruta de escape se considera un aspecto complejo
del comportamiento humano. Según [15], dos factores de�nen esta elección:
Conocimiento del entorno en base a factores internos, por ejemplo, un mapa
cognitivo de la geometría del edi�cio,
Conocimiento del entorno en base a factores externos, es decir, la interacción
con el entorno y con otros ocupantes, por ejemplo, grandes aglomeraciones de
personas o manifestaciones de incendio en las salidas.
12
2.4 Estado del Arte
Figura 2.5: Línea temporal del desarrollo de evacuación de una emergencia
Un factor más a tomar en cuenta es la velocidad de evacuación en los diferentes
lugares del edi�cio. Éste depende de aptitudes físicas propias de los ocupantes, la
densidad de personas en una región del edi�cio, y la interacción social entre indivi-
duos.
Por otro lado, los factores que ayudan a disminuir el tiempo de evacuación son
la señalización adecuada de las salidas, un sistema e�ciente de comunicación y un
entrenamiento apropiado del personal. Estos factores son decisivos ya que si el usua-
rio recibe información incompleta el ocupante podría no percibir la amenaza y por
ende ignorar las señales, buscar más información o seguir con sus actividades, como
se menciona en [15].
2.4.3. Aplicaciones con RFID en dispositivos móviles
Los dispositivos de lectura RFID pueden ser estacionarios o móviles. Esta última
cualidad de movilidad permite una mayor gama de aplicaciones. RFID Móvil es una
tecnología emergente que usa el teléfono móvil como un dispositivo de lectura RFID
que integra la tecnología wireless, las comunicaciones móviles y una infraestructu-
ra de red de sensores (USN, Ubiquitous Sensor Networks) para proveer al usuario
nuevos servicios [16].
Las aplicaciones comunes de RFID no utilizaban una red de sensores distribuida
en una determinada área. Los datos RFID eran consumidos por una sola aplicación,
es decir, la relación entre el módulo de lectura RFID y la aplicación era uno-a-uno.
13
2.4 Estado del Arte
El aporte de la tecnología RFID Móvil es la distribución de dispositivos de lectura
en un área y la difusión de los datos capturados a una variedad de aplicaciones.
Actualmente, la tecnología RFID Móvil puede representar dos tipos de combina-
ciones: teléfono inteligente equipado con etiqueta RFID (RFID-tag-attached mobile
phone) o equipado con lector RFID (RFID-reader-equipped mobile phone). Clara-
mente cada combinación tiene campos de aplicación diferentes. La primera apunta
más al pago de tarjetas, control de accesos, autenticación de identidad, entre otras.
La segunda, por otro lado, puede ser utilizada para proveer al usuario informa-
ción detallada del objeto etiquetado accediendo a la red de datos inalámbrica como
muestra la �gura 2.6:
Figura 2.6: Ejemplo de aplicación RFID-reader-equipped mobile phone [17]
Los sistemas móviles RFID desarrollados hasta el momento tienen una arquitec-
tura de red convencionalmente adoptada en la que incluyen ciertos elementos como:
las etiquetas RFID, el lector RFID, un servidor web y un servidor para la base de
datos. Esta arquitectura típica fue originalmente de�nida por la EPCGlobal [18].
Figura 2.7: Modelo de comunicación de datos RFID [16]
14
2.4 Estado del Arte
Los teléfonos inteligentes actuales aún no cuentan con la capacidad de lectura
de etiquetas RFID. Si bien ya existen modelos que permiten leer etiquetas NFC,
como el Samsung Nexus S1, los grandes fabricantes de teléfonos inteligentes (Apple,
Samsung y recientemente Nokia) tienen en sus planes incluir un lector RFID. Tam-
bién, empresas relacionadas con la fabricación de adaptadores y aplicaciones para
los teléfonos inteligentes han desarrollado módulos de lectura RFID adaptables. Por
un lado, Wireless Dynamics2 ha desarrollado para los teléfonos inteligentes iPhone
el adaptador iCarte. Algunas de sus características técnicas son:
Rango de escritura/lectura hasta 6.0 cm con la norma ISO 15693.
Consume 90 mA en el modo RFID escritura/lectura.
Diseñado para el iPhone 4S y iPhone 4.
Figura 2.8: Adaptador iCarte para iPhone de la empresa Wireless Dynamics[19]
Por otro lado, la empresa que desarrolló un adaptador RFID para los teléfonos
inteligentes Android es la taiwanesa Microelectronics Technology Inc.3. Este adap-
tador se denomina MINI ME RFID Reader y sus principales características técnicas
son:
Cumple con las normas: ISO 18000-6C / EPC Class 1 Gen2.
Frecuencia de operación: 902-928 MHz (US), 865-868 MHz (EU).
1http://www.samsungnexuss.com/nexus-s-specs/2www.wdi.ca3www.mti.com.tw
15
2.4 Estado del Arte
Consumo máximo 0.38 A.
Compatible con Samsung Galaxy Nexus y Samsung Galaxy S III.
Figura 2.9: Adaptador MINI ME RFID Reader para Android de la empresa MTI [20]
Ambos adaptadores de lectura RFID mencionados cuentan con aplicaciones para
su uso inmediato. Para el adaptador iCarte se pueden descargar desde el sitio o�cial
de aplicaciones AppStore, algunas como iCarte Wallet y BCARDReader, utilizadas
para negocios electrónicos. En cambio para el adaptador MINI ME se puede en-
contrar en el Google Play Market la aplicación MTI RFID ME GUI, que permite
con�gurar desde el teléfono el adaptador.
2.4.4. Desarrollo de aplicaciones para situaciones de emer-
gencia
El objetivo primordial que debe cumplir una aplicación de un teléfono móvil en
una situación de emergencia es evacuar por la ruta más segura y más corta en el
menor tiempo posible [3]. Esta evacuación se ha resuelto a través de diversas formas
de presentar las instrucciones de navegación al usuario. La efectividad de una u otra
instrucción de navegación depende fuertemente de las características de la situación
de emergencia.
Baus, Cheverst y Kray [5] muestran un estudio sobre las diferentes soluciones
empleadas en guías móviles. Indican que la mayoría de las soluciones existentes están
basadas en planos 2D pero igualmente otras soluciones alternativas valiosas son:
Fotos del entorno aumentas con ayudas visuales de navegación,
Modelos 3D,
Instrucciones textuales,
Direcciones auditivas, y
16
2.4 Estado del Arte
Croquis de rutas.
Baus et al [5], indica que si bien los modelos 2D son representaciones bien co-
nocidas del entorno, los modelos 3D o fotografías con realidad aumentada usan las
habilidades espaciales naturales del usuario, es decir, le proveen a éste las mismas
señales visuales, por ejemplo: obstrucciones o tamaño de los objetos. Además, de que
los modelos 3D sirven para entrenar a los usuarios a navegar un espacio sin estar
en el mismo hay que señalar que el nivel de desarrollo del modelo 3D debe ser alto
para que cumpla con todas estas cualidades. Si el modelo 3D no tiene una calidad
excelente el entorno que navega sería confuso y tampoco serviría para entrenamien-
to. En este aspecto, un modelo 2D requiere un nivel mínimo de calidad y se presta
a menos confusiones o desorientaciones del usuario.
2.4.4.1. Aplicación desarrollada en la Universidad de Udine
Una de las aplicaciones más desarrollada y e�caz en cuánto a situaciones de emer-
gencia es la desarrollada en la universidad de Udine (Italia) por Chittaro y Nadalutti
[2]. Dicha propuesta consiste en implementar un prototipo que dé instrucciones sim-
ples y efectivas para la evacuación mediante grá�cos de realidad aumentada (modelo
3D del edi�cio) en el dispositivo móvil como se puede ver en la �gura 2.10. El sistema
usa lectores RFID en los celulares y varías etiquetas colocadas en lugares �jos del
edi�cio, el �n es determinar la ubicación de la persona quien posee el móvil para
guiarlo a la salida de emergencia.
Figura 2.10: Modelo de realidad aumentada del edi�cio [2]
Chittaro y Nadalutti [2] determinaron, una vez �nalizado y testeado el proyecto,
dos restricciones importantes para que la determinación de la ubicación sea precisa.
La distancia entre cada etiqueta RFID no debe ser mayor a 2 metros, lo que
directamente implica un gran número de etiquetas en todo el edi�cio.
17
2.4 Estado del Arte
La velocidad de movimiento del dispositivo que realiza la lectura de cada
etiqueta debe ser constante.
Una falencia en la aplicación es que muestra un único camino hacía la salida de
emergencia.
2.4.4.2. Aplicación RescueMe
Otra solución e�caz de evacuación para teléfonos móviles es la desarrollada por
Junho Ahn y Richard Han de la Universidad de Colorado (EU) denominada Rescue-
ME [3]. Esta solución, para ambientes internos, está enfocada en edi�cios o fábricas
de gran tamaño y con caminos complejos hacia las puertas de evacuación, algunas
imágenes de la aplicación las muestra la �gura 2.11. Su objetivo primordial es indi-
car la salida óptima al usuario, es decir, la salida menos concurrida y a la cual toma
menos tiempo llegar.
Todo el sistema de evacuación de la aplicación RescueME tiene como base cuatro
componentes:
Localización basada en imágenes (image-based location),
Realidad aumentada (AR, Augmented Reality),
Podometría personalizada (personalized pedometry), y
Algoritmo de recomendación.
Estos componentes necesitan para su funcionamiento el servicio de correlación de
fotografías IQEngine, servidores en la nube (cloud servers) y los sensores del teléfono
móvil. Al no depender estos componentes de ninguna infraestructura adicional no
es necesario que se instale cientos o miles de etiquetas RFID en el edi�cio, como sí
se requería en la aplicación de la sección 2.4.4.1.
Parte del estudio para la validación de la aplicación RescueMe implicó simular
un escenario de emergencia según distintas dispersiones de la gente en el edi�cio
y según distintas decisiones de cuál camino tomar. Los tipos de dispersiones simu-
ladas fueron; gente distribuida aleatoriamente, y gente en grupos numerosos, las
simulaciones se muestran en la �gura 2.12.
Así mismo, las posibles decisiones de la gente en el escenario de emergencia
fueron:
Elección de una salida aleatoriamente,
Elección de la salida más cercana, y
18
2.4 Estado del Arte
Figura 2.11: Aplicación RescueMe en uso: mapa 3D y 2D [3]
Elección de la salida que toma el menor tiempo (método RescueMe).
Las simulaciones de la aplicación con las variables especi�cadas arrojaron las
siguientes conclusiones:
Cuando la gente está distribuida aleatoriamente el método de la salida más
cercana y el método RescueMe son más efectivos y toman, en promedio, el
mismo tiempo de evacuación de toda la gente.
Cuando la gente está en grupos numerosos el método RescueMe evacua más
rápidamente la gente, que el método de la salida más cercana.
La segunda conclusión de las simulaciones muestra la importancia del algoritmo
de recomendación de la aplicación. Este algoritmo puede cambiar la ruta de evacua-
ción indicada basándose en información de los demás usuarios, más especí�camente
basándose en la velocidad con la que concurren a la salida.
2.4.4.3. Desarrollos de la Universidad de Karabuk
Otros trabajos en evacuación para situaciones de emergencia se enfocan más en la
toma de decisiones de las personas cuando se encuentran en una situación de peligro.
En un estudio para un sistema de evacuación para una circunstancia de desastre,
liderado por la Universidad Karabuk (Turquía)[4], se indican ciertas consideraciones
que se deben tomar en cuenta a la hora de diseñar un sistema como tal:
19
2.4 Estado del Arte
Figura 2.12: Simulación en Software de la aplicación RescueMe: casos de distribuciónde personal [3]
En una situación de emergencia, los visitantes usan la puerta de entrada para
evacuar porque les es más familiar.
En una situación de emergencia, los ocupantes regulares del edi�cio usan la
puerta de emergencia para evacuar.
Cuando una alarma suena los ocupantes usan un periodo crítico de tiempo
solamente en decidirse evacuar el edi�cio.
Los ocupantes tardan cuatro veces más tiempo decidiendo evacuar luego de
escuchar la alarma que evacuando.
El 82% de las razones por las que los ocupantes evacuan un edi�cio es por
humo, gritos, voces y llamas. Solo un 7% evacua inmediatamente luego de
escuchar la alarma.
Un 36% de la razones de muerte en un incendio residencial es la inhalación de
humo. Un 25% es por quemaduras y as�xia.
El tiempo de evacuación depende de dos factores: preferencias de salida y
problemas de visibilidad por el humo.
La mayoría de ocupantes se vuelven o detienen si el humo impide ver menos
de 20 metros adelante en la ruta de evacuación.
Se puede concluir de los datos anteriores que los actuales sistemas de evacuación
no son lo su�cientemente inteligentes para resolver los posibles incidentes. Es muy
probable que un sistema actual de evacuación dirija a la gente a salidas bloqueadas
o a lugares donde hay una fuga de gas. Peor aún, este tipo de sistemas de evacuación
se vuelven inútiles cuando no hay visibilidad debido al humo o a cortes de energía.
20
2.4 Estado del Arte
Figura 2.13: Sistema de evacuación óptimo [4]
Según Rakip [4] un sistema de evacuación óptimo (OES, Optimum Evacuation
System) necesita siete componentes importantes:
1. Sistema para posicionamiento interno.
2. Enlace de comunicación.
3. Sistema GSM.
4. Modelo del edi�cio.
5. Información acerca de los ocupantes del edi�cio (edad, género, etc).
6. Información en tiempo real de los sensores (humo, temperatura, etc).
7. Sistema de evacuación central (software y hardware) para calcular la ruta
óptima y distribuirla a los ocupantes.
2.4.5. Situación de aplicaciones en dispositivos móviles para
localización en interiores
Las aplicaciones móviles para localización en interiores se desarrollan general-
mente usando como medio de detección las redes Wi� o Bluetooth disponibles, otros
21
2.4 Estado del Arte
sistemas incorporan además los sensores de los smartphones, como son acelerómetro
y magnetómetro como en [21] que muestra un sistema de localización en interiores
asistida por sensores.
En cuanto a localización en interiores utilizando tecnología RFID se han desarro-
llado algunos sistemas los que consideramos más relevantes se citan a continuación.
2.4.5.1. Aplicación móvil para localización en interiores basada en sis-
temas de localización geográ�ca
Este trabajo [22] utiliza un servidor SIG (Sistema de Información Geográ�ca) que
envía los planos de las construcciones e información interna asociada con los clientes.
Para determinar la ubicación precisa del usuario de utiliza teléfonos equipados con
tecnología RFID. La demostración del sistema se la hace en un campus con los
usuarios viendo los mapas interactivos. Cada usuario puede cambiar los niveles de
los edi�cios, encontrar o�cinas y ver las rutas entre lugares seleccionados.
Figura 2.14: PDA Display [22]
Cabe mencionar que la aplicación no se ejecuta de manera nativa en el telé-
fono sino que se hace accediendo al servidor SIG mediante el navegador propio del
teléfono.
Las conclusiones a las que llegan luego de realizar el trabajo son que la localiza-
ción en interiores tiene mucha utilidad en lugares extensos en los que la red Wi-Fi
esté presente en su totalidad, además concluyen que el costo para acceder a la in-
terfaz de su aplicación desde el teléfono es muy alto, debido al costo por cantidad
de datos consumidos.
22
2.4 Estado del Arte
2.4.5.2. LANDMARC: Localización en interiores utilizando RFID Acti-
vas
En [23] se diseña un prototipo que usa tecnología RFID para ubicar objetos
dentro de edi�cios. El proyecto se desarrolla en base a etiquetas de referencia para
garantizar la precisión en la ubicación. Basándose en un análisis experimental, de-
muestran que las RFID activas son una manera viable en cuanto a costo-bene�cio
para sistemas de localización en interiores. En la �gura 2.15 se ve los equipos RFID
utilizados.
Figura 2.15: Lector y etiquetas RFID utilizadas en el prototipo LANDMARC[23]
Los análisis experimentales que se realiza evalúan los efectos de la cercanía de
los usuarios, in�uencia de los factores del ambiente, número de lectores, ubicación
de las etiquetas de referencia. Esto les permite concluir que utilizar RFID resulta
menos costoso y muy preciso. A pesar de ello se determina tres problemas con este
sistema.
El primero de ellos, que los productos RFID desarrollados hasta ahora no proveen
el nivel de señal de las etiquetas, sino que únicamente se sabe que son detectables
o no detectables en el rango determinado. El segundo problema, la larga latencia
entre el rastreo de la ubicación física de una etiqueta con la ubicación en el servidor.
El tercer problema, son las variaciones en el comportamiento de las etiquetas. El
sistema LANDMARC [23] se desarrolla asumiendo que todas las etiquetas emiten
con la misma potencia. Pero en realidad se obtienen niveles de potencia variables
detectados por un mismo lector para dos etiquetas en idéntica ubicación.
2.4.5.3. Sistema de rastreo móvil RFID
El departamento de ingenieros en computación de la Universidad Americana de
Sharjah [24], desarrolló una aplicación para el monitoreo de la ubicación de niños en
áreas extensas como parques o mercados. El sistema utiliza etiquetas RFID activas,
23
2.4 Estado del Arte
Figura 2.16: Arquitectura de sistema de rastreo por RFID [24]
lectores RFID, servidores web y un servidor para la base de datos. Los lectores RFID
se ubican en varios sectores del área a cubrir. Cada niño llevara una etiqueta RFID
tipo pulsera. La comunicación entre los lectores y el servidor web es vía LAN. Y se
utiliza software para el manejo de la información de la base de datos además de una
interfaz amigable para el usuario, como se ve en la �gura 2.16.
El sistema sería implementado en "Dubai Global Village", el cual es un centro
de exhibiciones que atrae cada año de 40000 a 50000 visitantes. En este centro los
o�ciales de seguridad reciben cientos de denuncias de niños desaparecidos. Con el
sistema de rastreo implementado la búsqueda de estos niños será mucho más rápida
y sencilla.
24
3
MATERIALES Y MÉTODOS
3.1. Metodología
La metodología adoptada divide el proyecto de �n de titulación en 3 fases, para
dar cumplimiento a los objetivos. Las fases de�nidas son: exploratoria, experimental
y análisis de resultados.
La fase exploratoria consistió en una investigación en proyectos de tesis, revis-
tas y publicaciones cientí�cas, papers e informes técnicos, disponibles en la red de
Internet, sobre la tecnología RFID, sus aplicaciones en proyectos comerciales y de
investigación, especialmente en proyectos relacionados a la evacuación en situaciones
de emergencia. Ésto permitió redactar el estado del arte, dando así cumplimiento a
nuestro primer objetivo.
La fase experimental divide el sistema de evacuación en bloques de desarrollo
independientes. Pudiendo trabajar en varios módulos a la vez, para su posterior
integración al sistema. Los bloques de�nidos son cinco: red de sensores, servidor
Web, aplicación móvil Android, sistema de localización RFID, montaje del sistema
e infraestructura.
La tabla 3.1, muestra el detalle de los bloques y la �gura 3.1 el esquema del
sistema de evacuación.
Finalmente, la fase de análisis de resultados, consiste en desplegar el testbed
al sistema, con el �n de optimizarlo. Analizar el comportamiento y respuesta del
sistema, mediante simulaciones de situaciones de emergencia, en el modelo a escala
del edi�cio. Esto con el �n de establecer las conclusiones y recomendaciones para el
proyecto de �n de titulación.
25
3.1 Metodología
Tabla 3.1: Bloques de la fase experimental
Bloques de la fase experimental DescripciónComprende el sistema que va desde los sensores hasta la
Red de sensores generación de tramas TCP/IP, de las mediciones de lossensores, para la conexión con el servidor.Recibe las tramas generadas por la red de sensores y
Servidor Web procesa la información para generar alertas. Genera laaplicación WEB y el servicio Web para ser publicadosen internet.Es la parte central del sistema, consume el servicio WEB
Aplicación móvil Android y utiliza el sistema de localización RFID. Presenta tam-bién las opciones para entrenamiento en situaciones deemergencia.Recoge la información de las etiquetas RFID, mediante
Sistema de localización RFID el módulo de lectura conectado al teléfono para rela-cionarlas con la posición de la persona.Es la parte de modelado del edi�cio a evacuar, éste
Montaje del sistema e infraestructura detalla la ubicación de los sensores y las etiquetas RFID,para poder realizar la simulación del sistema.
Figura 3.1: Fase experimental del sistema de evacuación
26
3.2 Selección de materiales
3.2. Selección de materiales
3.2.1. Materiales para la red de sensores
De acuerdo con los bloques de�nidos en la metodología, ésta etapa corresponde
a los sensores utilizados para detectar las situaciones de evacuación, el microcontro-
lador para procesar la información y el módulo para convertir las señales en tramas
TCP/IP, que luego serán enviadas al servidor.
Los sensores envían sus lecturas en el rango de milivoltios. Éstos datos son to-
mados por el microcontrolador para ser digitalizados y acondicionados en la escala
de grados centígrados. Luego se les da el formato de envío junto con los datos de
todos los sensores. Finalmente se envía la información por el puerto serial hacia el
módulo conversor ,Serial a Ethernet, para crear la trama TCP/IP.
Los sensores a utilizar, para la simulación, son los de precisión en grados cen-
tígrados LM35, ver �gura 3.2, debido a que posee una respuesta lineal en voltaje,
proporcional a la temperatura en grados centígrados. El rango de temperatura que
puede medir el sensor va desde los 2 hasta los 150◦C.
Figura 3.2: Sensor de temperatura LM35
El microncontrolador es el ATMEGA32, debido a que tiene un puerto completo
para entradas analógicas, que será en donde se conectarán los sensores.
Para la generación de la trama TCP/IP se utiliza el módulo WIZnet S2E (Serial-
to-Ethernet), que viene acondicionado con un puerto serial DB9 como entrada y un
puerto Ethernet a la salida. Para el funcionamiento del módulo, es necesario asignarle
una dirección IP y un puerto de comunicación.
Tanto el microcontrolador como el conversor WIZnet S2E, se los montó en una
placa junto con el circuito impreso que une los sensores con el microcontrolador y
conecta los puertos seriales de ambos dispositivos. Éste módulo realiza el acondi-
cionamiento de la señal de los sensores y envía la trama TCP/IP al servisor. Se
27
3.2 Selección de materiales
con�guró 8 entradas analógicas y 16 entradas digitales. La �gura 3.3, muestra el
módulo de acondicionamiento de señales.
Figura 3.3: Módulo de acondicionamiento de señales de los sensores
3.2.2. Montaje del servidor Web
3.2.2.1. Software para la Base de Datos
El principal requerimiento de la base de datos es un sistema completo de gestión
de la misma, es decir, más que una base de datos se necesita de un Sistema de
Gestión de Base de Datos (DBMS, DataBase Management System). Existe un gran
número de sistemas de gestión de base de datos: jerárquicas, de red, transaccionales,
relacionales, multidimensionales, orientadas a objetos, documentales, deductivas y
distribuidas.
El sistema de gestión necesario para el sistema de evacuación debe tener caracte-
rísticas básicas como: licencia libre, de tipo relacional y gestión sencilla. Los sistemas
DBMS que cumplen estas características son: PostgreSQL, Firebird, SQLite, IBM
DB2 Express-C, Apache Derby, MariaDB y MySQL.
De los entornos integrados de desarrollo (Integrated Development Environment,
IDE) mencionados anteriormente, NetBeans y Eclipse son compatibles con bases
de datos que cumplen estos requerimientos. Por un lado, NetBeans1 trabaja con
MySQL y PostgreSQL. Por otro lado, Eclipse permite crear y gestionar bases de
datos via SQL y otros editores prede�nidos.
1http://netbeans.org/features/ide/database.html
28
3.2 Selección de materiales
Se decidió usar el sistema de gestión de base de datos MySQL1 ya que su inte-
gración con NetBeans es más desarrollado que SQL en Eclipse.
Figura 3.4: Sistema de Gestión de Base de Datos MySQL
3.2.2.2. Preparación de la Base de Datos MySQL
La base de datos MYSQL para el prototipo de evacuación no requiere ninguna
preparación especial. Solamente es necesario crear la base de datos con sus respec-
tivas tablas y crear la conexión a la misma [25]. La conexión a la base de datos se
realiza mediante un conector JDBC (Java DataBase Conectivity). En la pestaña de
servicios de NetBeans se puede visualizar la base de datos creada y su respectiva
conexión, como podemos ver en la �gura 3.5.
3.2.2.3. Software para la Aplicación Web
La aplicación web diseñada es una interfaz de usuario basada en web. Es común
diseñar, desarrollar e integrar este tipo de interfaces en JSF (Java Server Faces),
un marco de aplicaciones web basado en Java. Además, se suele usar JSF junto con
Ajax (Asynchronous JavaScript and XML), una tecnología que permite desarrollar
interfaces con mejores presentaciones.
Existen varias compañías y proyectos de diseño de aplicaciones web basados en
JSF y Ajax, se puede destacar tres por ser RAD (Rapid Application Development),
es decir, que siguen una metodología de mínima plani�cación para desarrollar pro-
totipos en el menor tiempo posible. Éstos son: RichFaces, ICEfaces y PrimeFaces
que presentan la misma facilidad de diseño e integración y cuentan con todas las
características para desarrollar el prototipo de aplicación web. Se eligió Primefaces2
para desarrollar la interfaz de usuario de la aplicación web.
1http://www.mysql.com/2http://www.primefaces.org/showcase/ui/home.jsf
29
3.2 Selección de materiales
Figura 3.5: Base de datos MySQL y conexión JDBC
Figura 3.6: Primefaces: librería para la aplicación web
3.2.2.4. Preparación del software para la Aplicación Web
Para diseñar la interfaz de la aplicación web con JSF, especí�camente con la
librería Primefaces, se necesita crear un proyecto tipo `Web Application' en el IDE
NetBeans y a éste añadirle la última librería de Primefaces. Para que la aplicación
web cuente con otras características como: un controlador para subir archivos (�le
Upload Controller) y un tema para mejorar la presentación, se requiere añadir las
siguientes extensiones, que muestra la �gura 3.7:
3.2.2.5. Generación del servicio web en Netbeans
La aplicación Android/RFID necesita consumir un servicio web para poder con-
sultar inalámbricamente desde la base de datos las alarmas de fuego y recomendacio-
nes de evacuación. Un servicio web es un sistema de software diseñado para soportar
30
3.2 Selección de materiales
Figura 3.7: Extensiones añadidas a la Aplicación web
interoperabilidad entre máquinas sobre una red [26], de tal forma que distintas apli-
caciones diseñadas sobre lenguajes diferentes pueden utilizarlo e intercambiar datos.
Esta interoperabilidad se consigue mediante varios protocolos y estándares. El están-
dar usado en nuestra aplicación Android/RFID es el estándar abierto SOAP (Simple
Object Access Protocol). SOAP realiza esta comunicación mediante intercambio de
mensajes con formato JSON (JavaScript Object Notation).
Para que la aplicación Android/RFID consuma el servicio web no se necesita
ningún programa adicional. Es necesario con�gurar el servicio en Netbeans y la
consulta del mismo en el teléfono.
En Netbeans se con�gura la generación del servicio dentro de la aplicación web.
Para esto se le añade un nuevo archivo tipo `RESTful Web Services from Database'
ubicado dentro de la carpeta `Web Services', como se ve en la �gura 3.8. A este
nuevo archivo solo se lo debe asociar a la base de datos y a la correspondiente tabla,
ver �gura 3.9.
Figura 3.8: Generación del servicio web
31
3.2 Selección de materiales
Figura 3.9: Selección de la base de datos para generar el servicio web
3.2.3. Desarrollo de Aplicación móvil Android
3.2.3.1. Software para desarrollo aplicaciones Android
Desde la aparición del sistema operativo Android para teléfonos móviles en el
2008 [27] hasta la actualidad existen un gran número de opciones de programación
de aplicaciones. Todas estas opciones se pueden dividir en dos grupos: lenguajes
amigables y ambientes de desarrollo integrado (IDE, Integrated Development En-
vironment). Los primeros, no requieren conocimientos de Java; son programas que
han sido diseñados para construir aplicaciones con lenguajes de programación pro-
pio e incluso mediante bloques de programación, como: Basic4Android, Mono, App
Inventor y LiveCode. Los IDE's, por otro lado, integran más herramientas de desa-
rrollo, a continuación se detalla los consideramos para el desarrollo de la aplicación
Android.
3.2.3.2. Entornos de desarrollo de aplicaciones Android
Los IDE's son los entornos que permiten programar aplicaciones Android aña-
diendo librerías API (Application Programming Interface) y herramientas de desa-
rrollo. Éstas permiten crear, probar y depurar aplicaciones Android. Google a través
de su página de desarrolladores1 permite descargar todas estas librerías y herramien-
tas contenidas en el Android SDK (Software Development Kit). El Android SDK
está disponible para Windows, Mac y Linux, siendo los requerimientos de sistema
los mínimos.1developer.android.com
32
3.2 Selección de materiales
Existen varios IDE's compatibles con el Android SDK y que ya han sido proba-
dos para desarrollar exitosamente aplicaciones Android. En la tabla 3.2 se detalla
las características de los más conocidos. De esta tabla se puede concluir que Net-
beans, Eclipse e IntelliJIDEA son los entornos de desarrollo más completos ya que
se encuentran disponibles para varias plataformas, por otro lado ofrecen más fun-
cionalidades al programador como el constructor de interfaz para el usuario (GUI
builder) y soporte de JavaScript. Otros IDE's como Geany, Greenfoot, jGRASP,
Servoy y más, presentan limitaciones similares a JCreator: carecen de GUI builder
o no soportan JavaScript.
Tabla 3.2: IDE's para desarrollo de aplicaciones Android
IDE LICENCIA PLATAFORMAS GUI Builder JavaScriptNetBeans CDDL, GPL2 Windows, Linux, Mac, Solaris Si Si
Eclipse JDT EPL Windows, Linux, Mac, Solaris Si SiIntelliJIDEA ALv2, proprietario Windows, Linux, Mac Si SiJCreator proprietario Windows No No
3.2.3.3. Selección del programa para desarrollo de aplicaciones Android
La aplicación Android para el sistema de evacuación se programó en el lenguaje
Java. La información sobre el desarrollo de aplicaciones es más extensa y completa,
debido a que Java es el lenguaje o�cial elegido por Google.
Elegido el lenguaje de programación de las aplicaciones Android, queda selec-
cionar el IDE, pudiendo ser Netbeans1, Eclipse2 e IntelliJIDEA3. Estos tres IDE's
cuentan con las mismas características y se encuentran al mismo nivel de desarrollo.
Se decidió usar Eclipse Indigo, en su versión 3.7.2(�gura 3.10), porque es el IDE
recomendado en la página de desarrolladores de Android y porque incorpora el ADT
(Android Developer Tools) para simpli�car el desarrollo de estas aplicaciones.
Figura 3.10: Eclipse Indigo: IDE seleccionado para desarrollo de la aplicación Android
1http://netbeans.org/2http://www.eclipse.org/indigo/3http://www.jetbrains.com/idea/
33
3.2 Selección de materiales
3.2.3.4. Preparación del IDE Eclipse
Para crear aplicaciones en Eclipse se necesita agregarle librerías API y herramien-
tas de desarrollo. Como se mencionó anteriormente, existe una versión de Eclipse
que trae incorporado todo lo necesario para desarrollar aplicaciones Android. Todas
las librerías que se encuentran condensadas en el paquete ADT1, son:
Eclipse más el Plugin ADT 3.11.
Herramientas Android SDK.
Herramientas de plataforma Android.
La última plataforma Android.
La última imagen de sistema Android para el emulador.
Figura 3.11: Paquete ADT para Windows
Por otro lado, si se desea instalar por separado el IDE Eclipse y los paquetes para
crear aplicaciones Android se debe descargar e instalar los siguientes programas y
librerías:
Eclipse 3.6.2 o mayor.
Plugin Eclipse JDT (Java Development Tools).
JDK 6 (Java Development Kit).
Plugin ADT.
El Android SDK incluye todas las librerías necesarias para aprovechar cada una
de las características del dispositivo móvil Android, basta con importarlas en el
programa principal, con el comando import seguido por el nombre del paquete,como
muestra la �gura 3.12.
1http://developer.android.com/sdk/index.html
34
3.2 Selección de materiales
Figura 3.12: Paquetes importados a la aplicación Android/RFID
3.2.3.5. Consumo del servicio web desde el dispositivo móvil
En Eclipse es necesario indicar dentro de la aplicación Android los paquetes que
se deben importar y la dirección IP en la que se deben buscar los datos del servicio
web, esto se ve en las �guras 3.13 y 3.14.
Figura 3.13: Paquetes importados para consultar el servicio web
Las consultas al servicio Web, se realizan de manera continua cada 10 segundos
desde que se inicia la aplicación. Es decir, que el estado de las alertas se actualiza
en este tiempo como máximo, esto se hace debido a que las actualizaciones de los
sensores son cada 20 segundos. Para la implementación del sistema en un edi�cio, se
debería considerar siempre que el tiempo de consumo del servicio Web, sea menor
al de actualización de los sensores.
35
3.2 Selección de materiales
Figura 3.14: Código para consumir el servicio web
3.2.3.6. Retrasos en aplicaciones Android
Las características de tiempo de respuesta son importantes en una situación de
emergencia. Android está diseñado para evitar tiempos de respuesta muy grandes,
mostrando un diálogo al usuario llamado diálogo ANR (Application Not Respon-
ding) como se ve en la �gura 3.15.
Figura 3.15: Mensaje Android ANR
Este diálogo permite elegir al usuario entre `Forzar el cierre de la aplicación'
o `Esperar'. Adicionalmente, en la página o�cial de Android para desarrolladores
se especi�ca que el tiempo después del cual un usuario percibe retraso o falta de
continuidad de la aplicación es 100 a 200 ms. En consecuencia, la aplicación que se
desarrolle no debería tener fases (procesos, salto entre procesos, salto entre ventanas)
que duren más de 200 ms.
3.2.3.7. Tiempos de retraso de la aplicación de evacuación Android/RFID
Tomando en cuenta los tiempos de retraso permitidos en una aplicación Android
se de�ne un conjunto de tiempos de retraso especí�cos de la aplicación desarrollada:
Tiempo de puesta en marcha de la aplicación.
Tiempo de reconocimiento del módulo de lectura RFID.
36
3.2 Selección de materiales
Tiempo de lectura de una tarjeta.
Tiempo de actualización de la posición en el plano según la tarjeta.
Tiempo de actualización del ícono de orientación.
Tiempo de recepción de alarmas de fuego y sugerencias de evacuación.
Tiempo de ejecución de una llamada de emergencia.
3.2.3.8. Tiempo de puesta en marcha de la aplicación
Este es el tiempo de ingreso a la aplicación y es el mínimo posible ya que cuando
se ingresa no existe ningún proceso de búsqueda de dispositivo o lectura de tarjeta
RFID. La primera ventana, que se ve en la �gura 3.16, permite al usuario elegir
entre 'Evacuación' o 'Entrenamiento'.
Figura 3.16: Pantalla de inicio de la Aplicación
3.2.3.9. Tiempo de reconocimiento del módulo de lectura RFID
Una vez que se ingresa a `Evacuación' la aplicación busca el módulo de lectura
RFID y lo compara con un conjunto de posibles dispositivos de lectura RFID. Si la
aplicación reconoce el módulo aparecerá un mensaje en pantalla indicando `RFID
conectado'.
37
3.2 Selección de materiales
3.2.3.10. Tiempo de lectura de una tarjeta
Una vez que se ha detectado el dispositivo correcto para lectura de tarjetas RFID
la aplicación leerá las etiquetas RFID correspondientes. Para la lectura de cada
etiqueta es necesario acercar el teléfono y automáticamente el módulo encenderá un
LED de lectura y el valor de ID de la tarjeta se comparará con un registro de otros
posibles ID's. Este tiempo de lectura podría verse afectado por interferencia de otras
etiquetas (intento de múltiples lecturas) o por no acercar el módulo la distancia y
tiempo su�cientes.
3.2.3.11. Tiempo de actualización de la posición en el plano según la
etiqueta RFID
Una vez que se ha identi�cado el ID de la etiqueta y se lo relacione con la posición
en el edi�cio, se actualizará la ventana de la aplicación mostrando la sección del plano
correspondiente (zoom y orientación adecuados).
3.2.3.12. Tiempo de actualización del ícono de orientación
El ícono de orientación está constantemente actualizándose. Éste indica la di-
rección del usuario con respecto a la sección del plano en la que se encuentra. Esta
actualización toma determinado tiempo que depende de las características del mag-
netómetro y cómo la aplicación accede a estos datos. Este tiempo de respuesta po-
dría verse afectado por características propias del magnetómetro o por interferencias
electromagnéticas externas.
3.2.3.13. Tiempo de recepción de alarmas de fuego y sugerencias de
evacuación
La recepción de las alarmas de fuego y sugerencias de evacuación toma un tiempo
de actualización con�gurable, debido a que estos datos los consulta via WiFi de una
base de datos externa. Para ejecutar el testbed se estableció un tiempo de lectura de
sensores en 20 segundos. Las consultas al `web service' desde el teléfono se realizan
cada 10 segundos. En un sistema de evacuación real los tiempos de medición de los
sensores sería mucho mayores debido a la alta cantidad de datos que generarían,
en el servidor. Considerando además la infraestructura del edi�cio y el tiempo de
propagación del fuego, se podría con�gurar valores alrededor de 5 minutos.
38
3.2 Selección de materiales
3.2.3.14. Tiempo de ejecución de una llamada de emergencia
Dentro de la sección `Entrenamiento' se ubica la opción `Números de emergencia'
en la que se ubican los principales contactos en caso de necesitar ayuda: Bomberos,
Policía, Cruz Roja, entre otros. El tiempo que toma a la aplicación hacer la llamada
al contacto especi�cado, es el mismo que tomaría, si la llamada se hiciera directa-
mente, sin la aplicación. Los casos en los que este tiempo de llamada aumentaría
son raros y dependerían exclusivamente de la red celular, puesto que en este proceso
existe uso mínimo de recursos.
Dentro de la aplicación existen otros tiempos de respuesta que no son conside-
rados urgentes por su cualidad de opciones de entrenamiento, como son, el plan de
evacuación y recomendaciones en una situación de emergencia.
3.2.4. Prototipo de lectura de etiquetas RFID y dispositivo
móvil
Con respecto al prototipo que utilizaremos en el proyecto para situaciones de
emergencia se pueden de�nir algunos tipos de características, como:
Características técnicas (electrónicas y eléctricas) del funcionamiento del mó-
dulo de lectura RFID.
Características de la conexión lógica entre el módulo de lectura RFID y el
dispositivo móvil con Android.
Características de respuesta del prototipo en situaciones adversas.
Características de tiempos de respuesta de la aplicación.
Características de diseño de la aplicación.
Las características del prototipo que se tomarán en cuenta y detallarán son las
que podrían afectar la respuesta y la toma de decisión de un usuario en caso de una
situación de emergencia, como por ejemplo, que la aplicación o una parte de ésta sea
lenta, se cuelgue o se congele durante largos períodos, o tarde demasiado en entrar
en un proceso.
3.2.4.1. Características Lógicas
La trama enviada por el módulo de lectura RFID tiene el siguiente formato: la
secuencia de lectura empieza cuando la línea `Preset' de la Tarjeta se activa (bajo).
Luego siguen 10 ciclos de reloj en cero `0' (10 Leading Zeros). Al �nalizar estos 10
39
3.2 Selección de materiales
ciclos guía, se envía el carácter de inicio `11010' (SS) y a continuación los datos
leídos (Data). Los datos leídos van seguidos por el LCR (Longitudinal Redundancy
Check). Finalmente se envían un tren de pulsos de 10 bits y la línea `Preset' de la
tarjeta se desactiva. La �gura 3.17, muestra la trama de datos.
La duración de los bits de datos es aproximadamente 330µs. La duración aproximada
de los ciclos de reloj es 110µs.
Figura 3.17: Trama de envío de datos de la tarjeta RFID
3.2.4.2. Características Físicas
La tabla 3.3 especi�ca las características físicas y lógicas del módulo de lectura
RFID. De estas características las dimensiones del módulo son importantes para el
montaje del prototipo.
Tabla 3.3: Características del módulo de lectura RFID
PARÁMETRO DETALLEDimensiones 26 mm x 25 mm x 7mmFrecuencia 125kHz
Formato de las tarjetas EM 4001 o compatiblesDecodi�cación Manchester 64 bits, módulo 64
Requerimientos de potencia 5Vdc 5mA nominalVoltaje de alimentación 4,6V a 5,4V
3.2.5. Montaje del sistema de evacuación
El montaje del prototipo consiste en adherir al dispositivo móvil Android el
módulo de lectura RFID de tal forma que no afecte la libertad con la que el usuario
maneja el dispositivo. El cable que conecta el dispositivo Android con el módulo
RFID es USB-Mini a USB-Micro del tipo OTG. En la �gura 3.18, se puede visualizar
el montaje del prototipo.
3.2.5.1. Características, alcances y limitaciones
La Base de Datos está alojada en un servidor MySQL por lo tanto es relacional,
multihilo y multiusuario. Se crearon dos bases de datos: db_r�d y db_registro, cada
una con un objetivo especí�co. Ambas bases de datos tienen el mismo par de tablas
denominadas: tb_sensores y tb_alertas.
40
3.2 Selección de materiales
Figura 3.18: Montaje del prototipo: captura lateral
Base de datos db_r�d: guarda las lecturas inmediatas de los sensores analógi-
cos y digitales,
Base de datos db_registro: carga los registros que se deseen consultar.
La base de datos db_r�d es gestionada por una aplicación en Java que realiza
las siguientes funciones:
1. Se ejecuta en el servidor donde llegan los datos de los sensores a través de un
cable de red.
2. Crea un socket en el puerto Ethernet para recibir las tramas con los datos de
los sensores.
3. Sincroniza las tramas leídas para insertar las lecturas de los sensores en la
tabla tb_sensores.
4. Inserta en la tabla tb_alertas la alarma correspondiente a cada sensor.
5. Cuando las lecturas de todos los sensores suman 50 saca un respaldo de toda
la base de datos y trunca la misma. La �gura 3.19 muestra los respaldos
obtenidos.
La aplicación web se diseñó especí�camente para que el personal de socorro en
caso de una situación de emergencia, como el Cuerpo de Bomberos, pueda informarse
41
3.2 Selección de materiales
Figura 3.19: Respaldo de las lecturas de los sensores
sobre la situación del edi�cio en peligro. La información disponible para el personal
de socorro es toda la que el sistema ha adquirido y puede aportar:
Página de ingreso y autenticación que la muestra la �gura 3.20.
Relación de cada uno de los sensores con el edi�cio, piso y sector al cual
pertenecen.
Lectura en tiempo real de cada uno de los sensores en el edi�cio (últimas 50
lecturas), ver �gura 3.21.
Grá�co Temperatura (oC) vs Tiempo (00h00) de todos los sensores (últimas
50 lecturas), ver �gura 3.22.
Planos de todos los pisos del edi�cio con detalle de las zonas de peligro.
Consulta de los registros de las lecturas de los sensores con grá�co Temp. vs
Tiempo.
Figura 3.20: Página de ingreso y autenticación
42
3.2 Selección de materiales
Figura 3.21: Lectura en tiempo real de los sensores
Figura 3.22: Grá�co Temperatura vs Tiempo de los sensores
3.2.6. Modelado de la infraestructura
Para realizar las pruebas al sistema de evacuación a través de dispositivos móviles
Android se diseñó y construyó un modelo a escala del edi�cio a evacuar: segundo y
tercer piso del edi�cio UGTI (UTPL). Esta maqueta aparte de contener los sensores
analógicos y digitales, y la placa electrónica de la adquisición de las lecturas de los
sensores, permite que el dispositivo Android con el lector RFID adherida se desplace
por encima de los pasillos y de los cuartos de la misma. Las principales características
de la maqueta orientadas a facilitar el test del prototipo son:
Carece de techo y cielo raso para permitir visualizar los cuartos, los pasillos y
las salidas de emergencia.
43
3.2 Selección de materiales
Figura 3.23: Planos de los pisos del edi�cio con detalle de las zonas de peligro
Consta de dos pisos (como mínimo) para poder probar el sistema de evacuación
de un piso a otro. El modelo del edi�cio se puede ver en la �gura 3.24.
Las paredes de la maqueta son diseñadas tomando en cuenta la distancia
máxima de lectura del módulo RFID.
El material con el cual está diseñada la maqueta no causa interferencias en la
lectura de las etiquetas RFID.
3.2.6.1. Ubicación de sensores
El piso superior se dividió en 5 sectores, para cubrir los departamentos. Los
sensores se ubicaron uno por cada sector. En el piso inferior existen 2 sectores, con
igual número de sensores. Se utiliza sólo un sensor correspondiente al área de las
escaleras que conecta ambos pisos.
Los sectores de�nidos se pueden ver en la �gura 3.25 y 3.26.
3.2.6.2. Ubicación de tarjetas RFID
Las tarjetas y etiquetas RFID se ubicaron en los pasillos, escaleras y salidas de
emergencia. Éstas no corresponden a la cantidad que se usarían en un escenario real
sino a la conveniencia de su ubicación para probar el sistema. Un calculo del número
de sensores para un edi�cio se puede ver en la sección 4.6. La disposición de las
etiquetas para el piso superior se muestra en la �gura 3.27.
44
3.3 Pruebas y optimización del sistema de evacuación
Figura 3.24: Maqueta para probar el sistema de evacuación
Tabla 3.4: Cantidad tarjetas, etiquetas RFID y sensores por piso
DETALLE Piso superior Piso inferiorTarjetas RFID 11 4Etiquetas RFID o 7Sensores analógicos 5 3
El total de tarjetas, etiquetas RFID y sensores ubicados e instalados en cada
piso de la maqueta se resumen en la tabla 3.5:
3.3. Pruebas y optimización del sistema de evacua-
ción
Para el sistema de evacuación los test se enfocaron al desempeño de la aplicación
y a desplegar testbed al sistema completo.
3.3.1. Prueba al desempeño de la aplicación
El primer test trata de determinar cuan robusta es la aplicación. Para esto se
somete la aplicación a distintas pruebas de desempeño. Sin embargo, no existe un
programa de test y validación para aplicaciones Android. Ante esta carencia de nor-
malización para testear y validar una aplicación en Android, nació la alianza AQuA
45
3.3 Pruebas y optimización del sistema de evacuación
Figura 3.25: Sensores piso superior de la maqueta
(Alianza para la Calidad de Aplicaciones). Esta alianza es un cuerpo industrial móvil
fundado por AT&T, LG, Motorola, Nokia, Oracle, Orange, Samsung y Sony Mobile.
La alianza tiene como objetivo publicar documentos guía multiplataforma para el
desarrollo de aplicaciones móviles.
Como resultado del trabajo de AQuA se han publicado, hasta la fecha, dos
documentos sobre cómo se debe testear y validar el desempeño de una aplicación
Android. Éstos son:
Uni�ed Testing Criteria for Android applications version 1.0: March 2011
UTI Testing Criteria (UTC) for Android applications version 1.1: June 2012
El test con el cual se validará la aplicación será el documentado en la UTI Testing
Criteria versión 1.1 (Junio 2012) por ser el más reciente. Éste requiere como requi-
sito que se resetee el dispositivo Android a un estado de fábrica y haber instalado
solamente la aplicación que se va a validar. De esta manera, los errores producidos
sólo serán atribuibles a la aplicación en proceso de validación y la experiencia del
usuario testeada será una solución end-to-end.
Además, en este documento se indica que no todos los test deben ser aplicados.
El tipo de test que se aplique depende del tipo de aplicación que se desee validar.
46
3.3 Pruebas y optimización del sistema de evacuación
Figura 3.26: Sensores piso inferior de la maqueta
Existen tres categorías para de�nir las aplicaciones, éstas son: simple, framework y
compleja. Se de�nen a continuación.
3.3.1.1. Aplicación simple
Una aplicación Android simple cumple con lo siguiente, según[28]:
No envía SMS ni MMS.
No escribe datos a archivos de datos estándares, como contactos, calendario.
No escribe datos a servicios externos, como redes sociales.
Accede pero no cambia el estado de la red de servicios, como 3G/Wi�/Bluetooth.
Accede a sitios externos para recuperar información.
Accede a información de localización.
Lee archivos estándares de datos.
Lee SMS y MMS.
Accede a la pantalla, al sonido, a la cámara y al teclado.
47
3.3 Pruebas y optimización del sistema de evacuación
Figura 3.27: Ubicación de tarjetas RFID en la parte posterior de la maquetas
Escribe sus propios datos, como fotografías, nuevos documentos.
A este tipo de aplicación se le debe aplicar los test indicados en la tabla 3.5.
3.3.1.2. Aplicación Framework
En este tipo de aplicaciones el mismo marco de la aplicación se usa repetidamente
como por ejemplo aplicaciones de diccionarios, libros y revistas. Para este tipo de
aplicaciones es demasiado hacer un test completo por lo que se recomienda hacer
el test de aplicación simple o compleja a la aplicación principal. A las aplicaciones
subsecuentes derivadas de la principal se debe aplicar un test más especí�co como
se detallará a continuación la tabla 3.5.
3.3.1.3. Aplicación Compleja
Cualquier aplicación que no se clasi�ca como Simple o Framework será conside-
rada Compleja y se le aplicará el test de criterio completo.
Existe también una clasi�cación para este tipo de test que describe el nivel
de importancia del mismo. Así, estos tests se clasi�can en Críticos (Critical) y de
Advertencia (Warning) y se de�nen como:
Test Críticos, aquellos test que deben ser pasados. Si la aplicación falla el test
implica que tiene una falla total y general.
48
3.3 Pruebas y optimización del sistema de evacuación
Tabla 3.5: Test para aplicaciones Simples y Framework
TIPO DE TEST TEST Simp. Fram.1 Instalación y 1.1 Instalación OTA (over the air)
√ √
ejecución 1.3 Largo tiempo de ejecución√
3 Conectividad 3.1 Envío y Recepción de datos√ √
3.4 Descarga de recursos√ √
5 Mensajes y 5.2 Recepción de mensajes√
llamadas 5.3 Llamada entrante√
6 In�uencia externa 6.1 Operación de la tarjeta de memoria√
7.1 Legibilidad√ √
7.3 Repintado de Pantalla√
7.5 Facilidad de uso de las teclas√
7.8 Función de progreso√
7 Interfaz de 7.10 Manejo de formato de display√
usuario 7.11 Distintos tamaños de pantalla√
7.12 Manejo del formato de las entradas√
7.14 Errores de Ortografía√
7.15 Errores de texto técnicos√
8 Lenguaje 8.1 Operación correcta del lenguaje√
8.3 Formatos soportados del lenguaje√
9 Rendimiento 9.1 Suspender/reanudar desde el menúprincipal
√
9.2 Suspender/reanudar durante la eje-cución
√
10 Media 10.1 Opción mute de la aplicación√
10.2 Ayuda y acerca de√ √
12 Funcionalidad 12.1 Comprobación de la funcionalidad√ √
13 Teclas 13.1 Desplazamiento por los menús√
13.3 Pausa√
15.1 Estabilidad de la aplicación√ √
15 Estabilidad 15.2 Comportamiento luego del cierreforzado
√
16 Manejo datos 16.2 Eliminación de datos√
49
3.3 Pruebas y optimización del sistema de evacuación
Test de Advertencia, hay cuatro tipos de niveles de advertencia: pasa, molesto,
difícil e imposible. Se de�nen así:
• Pasa: la aplicación pasa el test, no hay inconvenientes.
• Molesto: un error mínimo ha ocurrido con la aplicación, por ejemplo:
algún error tipográ�co.
• Difícil: un error más serio ha ocurrido con la aplicación, por ejemplo:
varios errores tipográ�cos que hacen la aplicación difícil de usar.
• Imposible: un error serio ocurrió con la aplicación, por ejemplo: los errores
hacen la aplicación imposible de usar.
3.3.1.4. Clasi�cación UTC de la aplicación
Según la descripción que se ha hecho de los distintos tipos de aplicaciones se
puede clasi�car a la aplicación como Compleja. No encaja en la descripción de
Simple ya que ésta escribe datos a archivos y tampoco se cataloga como Framework
puesto que no se usa el mismo marco repetidamente. Para validar nuestra aplicación
Compleja se debe elegir tests especí�cos que se le pueden aplicar para validar cada
uno de sus procesos. No se pueden aplicar todos los tests catalogados dentro de
aplicación Compleja ya que existen procesos que la aplicación no usa, como por
ejemplo: envío y recepción de mensajes, selección manual del lenguaje, etc. En la
tabla 3.6 se indica los test UTI que se evaluarán en la aplicación Android/RFID.
3.3.2. Procedimientos para las pruebas al sistema
Las pruebas a aplicar al sistema se realizan de acuerdo a los bloques establecidos
en la metodología 3.1, en el siguiente orden:
1. Evaluación del funcionamiento de la red de sensores
2. Evaluación al servidor Web, junto con la red de sensores para la generación
alertas.
3. Test a la aplicación móvil Android.
4. Evaluación al sistema de localización RFID.
5. Evaluación al sistema de evacuación completo montado en la maqueta.
A continuación, se detalla los procedimientos a seguir para la evaluación de cada
bloque dentro del sistema de evacuación.
50
3.3 Pruebas y optimización del sistema de evacuación
Tabla 3.6: Test aplicables a la aplicación Android/RFID
Test Descripción1.1 Instalación OTA (overthe air)
Comprueba la correcta instalación de la apli-cación
1.2 Largo tiempo de ejecu-ción
Comprueba si la aplicación noti�ca al usuariocuando tarda demasiado en iniciar
5.3 Llamada entrante Asegura que el dispositivo puede recibir lla-madas cuando la aplicación está en uso
6.1 Operación de la tarjetade memoria
Asegura que la aplicación trabaja correcta-mente removiendo e insertando la tarjeta
7.1 Legibilidad Asegura que el contenido es legible7.2 Tiempo de lectura Asegura que el tiempo para la lectura del
contenido es adecuado7.3 Repintado de Pantalla Asegura que haya sobreposición de objetos7.4 Consistencia Asegura la consistencia de la interfaz de
usuario7.5 Facilidad de uso de lasteclas
Asegura que los botones y otros métodos deingreso son fáciles de usar
7.6 Velocidad de la aplica-ción
Asegura que la velocidad de la aplicación esaceptable para su propósito
7.7 Mensajes de error Asegura que los mensajes de error son enten-dibles y explican el problema
7.8 Función de progreso Asegura una indicación visual del progresoen la ejecución en una función
7.13 Respuesta de los senso-res
La respuesta de la aplicación al movimientoo al cambio de dirección no debe perjudicarel uso de la aplicación
9.1 Suspender/reanudardesde el menú principal
Asegura que la aplicación se suspende correc-tamente en el menú principal
9.2 Suspender/reanudar du-rante la ejecución
Asegura que la aplicación se suspende correc-tamente durante la ejecución
10.1 Opción mute Asegura que la aplicación se puede silenciar11.1 Ayuda y Acerca de La aplicación debe tener ítems de `Ayuda' y
`Acerca de'12.1 Comprobación de lafuncionalidad
Comprueba la funcionalidad general de laaplicación
3.3.2.1. Procedimiento para la evaluación a la red de sensores
Los sensores han sido colocados de acuerdo a la distribución descrita en la sección
3.2.6.1, y estarán en funcionamiento desde el instante en que se energiza el sistema
de evacuación.
Para evaluar el sistema de evacuación hasta este bloque, se utiliza una herra-
mienta que permita recibir las tramas enviadas por un puerto TCP; hemos elegido
el software Hercules 3.071, por ser de licencia libre.
El procedimiento a seguir para evaluar la red de sensores, es:
1. Una vez conectado el sistema, revisar que los datos que llegan por el puerto
TCP/IP, concuerden con los enviados desde el microcontrolador.
1http://www.hercules-390.org/
51
3.3 Pruebas y optimización del sistema de evacuación
2. Veri�car que el sistema no presente retardos en el envío de los datos.
3. Comparar la temperatura que lee cada sensor con la del ambiente.
4. Variar la temperatura en los sensores y comprobar que el sistema responde
correctamente.
3.3.2.2. Procedimiento para evaluación de Servidor Web
La evaluación a este bloque comprende, recepción de las tramas por TCP/IP,
procesamiento de los datos, generación alertas, respaldo de información y presenta-
ción en aplicación Web y servicio Web.
Corroborar que las tramas enviadas desde el bloque anterior, concuerdan con
los recibidos por la aplicación Java en el servidor.
Veri�car que las alertas se generen correctamente.
Comprobar el funcionamiento de la aplicación Web de manera continua.
Comprobar que las tramas generadas en notación JSON, por el servicio Web,
sean coherentes con las alertas generadas en el servidor.
Veri�car que los datos respaldados sean correctos, de modo que se puedan
acceder a ellos desde el servidor.
3.3.2.3. Procedimientos para evaluación de la Aplicación Android
Esta evaluación corresponde al software que estará en funcionamiento en el te-
léfono. Los procedimientos a seguir son:
1. Aplicar los test UTI, mencionados en la tabla 3.6.
2. Evaluar los módulos asociados con la aplicación para el sistema de evacuación,
estos son:
Consumo de servicio Web.
Lectura de etiquetas RFID.
Módulo grá�co para la navegación, incluye, actualización de rutas, planos,
zoom, orientación y alertas.
Mensajes de evacuación
3. Evaluar las opciones para el sistema de entrenamiento en la aplicación Android.
52
3.3 Pruebas y optimización del sistema de evacuación
3.3.2.4. Procedimiento para evaluación del sistema de localización RFID
El sistema de localización RFID relaciona las etiquetas con el lugar en el que se
encuentra el usuario. En una circunstancia de evacuación es clave la respuesta que
el sistema dé al usuario, por esta razón se evaluará el tiempo de respuesta de lectura
de una tarjeta RFID, y las interferencias que podría tener esta comunicación en un
edi�cio.
El procedimiento a seguir para la evaluación de esta parte del sistema de eva-
cuación es:
1. Evaluar la conexión entre el módulo RFID y el teléfono y de�nir el tiempo de
reconocimiento.
2. Realizar lecturas de etiquetas del sistema de evacuación. Con el �n de estable-
cer distancia máxima y tiempo de lectura, además el efecto de la cantidad de
tarjetas leídas y considerar posibles interrupciones que pueden presentarse en
el sistema de evacuación.
3.3.2.5. Análisis al Sistema de Evacuación RFID
Una vez que se ha veri�cado cada bloque del sistema, por separado, se realizará
las pruebas al sistema con el �n de determinar posibles fallos, que permitan optimizar
el sistema de evacuación.
Las pruebas que se van a realizar son:
Medir los tiempos máximos de actualización de las alarmas en el teléfono,
respecto a las variaciones de temperatura.
Evaluar la respuesta de las etiquetas RFID, respecto al lugar en el que se
mueva el teléfono.
Analizar la correspondencia entre la zona que cubren los sensores y las alarmas
mostradas en el teléfono.
Realizar pruebas activando varias alarmas a la vez.
Evaluar las alertas generadas y la actualización de rutas en el teléfono, al
activarse alarmas entre los dos pisos.
53
4
ANÁLISIS DE RESULTADOS
4.1. Red de sensores
Realizadas las pruebas a la red de sensores para el sistema de evacuación, se
obtuvieron los siguientes resultados:
1. El formato de la trama recibida en el servidor, es el mismo que se envía desde el
microcontrolador. La trama se puede ver en la �gura 4.1. Los valores recibidos
de cada sensor, corresponden a la temperatura ambiente, en grados centígra-
dos, para las diferentes zonas del modelo a escala del edi�cio, de acuerdo con
los sectores de�nidos en la sección 3.2.6.1.
Figura 4.1: Formato de datos enviados desde el microcontrolador
2. El retardo en el tiempo de actualización del valor leído por el sensor, está en
el orden de los milisegundos, por tanto, no afecta de manera signi�cativa el
tiempo de emisión de una alerta.
3. El microcontrolador realiza las lecturas a los sensores cada 20 segundos, adi-
cionalmente, tarda 2 segundos en envíar los datos hasta el servidor. Por tanto,
el tiempo máximo de espera por la actualización de un valor de temperatura,
es 22 segundos.
54
4.2 Servidor Web
En esta parte del sistema de evacuación se tendría un retraso máximo de 22
segundos, cabe destacar que este tiempo se lo utiliza como prueba para el sistema
montado en la maqueta. En un sistema de evacuación montado en un edi�cio, el
tiempo de actualización, debe dimensionarse adecuadamente, con el �n de no tener
una cantidad elevada de lecturas, que luego puedan saturar la memoria de almace-
namiento del servidor.
4.2. Servidor Web
Los resultados obtenidos de las pruebas realizadas al servidor, son los siguientes:
La aplicación Java tarda 2 segundos en recibir la trama completa, esto se
con�guró en el microcontrolador.
Las alertas generadas en el servidor concuerdan con las lecturas de tempera-
tura de los sensores y el límite establecido para activar una alerta. El valor
con�gurado para la activación de una alarma es 23◦C para la simulación del
sistema de evacuación.
Los datos obtenidos de la generación de una alarma se muestran en la �gura
4.2. En ésta se puede veri�car que cuando la temperatura supera el valor
máximo, se genera la alarma en el servidor y se actualiza la trama en notación
JSON. Las etiquetas S1 hasta S8, identi�can los sectores que están siendo
monitoreados y los valores `11' y `00', determinan si la alarma se ha activado
o no, respectivamente.
Figura 4.2: Trama en notación JSON generada de una alerta
De los resultados obtenidos, podemos decir que ni el procesamiento del servidor ni
las aplicaciones generan retrasos considerables en el sistema, puesto que los valores
de los sensores se actualizan, cada vez que llegan los datos al servidor desde el
microcontrolador.
55
4.3 Aplicación Android
Tabla 4.1: Resultado de tests UTI a la aplicación Android RFID
Test Descripción Resultado1.1 Instalación OTA (overthe air)
Comprueba la correcta instalación de la apli-cación
√
1.2 Largo tiempo de ejecu-ción
Comprueba si la aplicación noti�ca al usuariocuando tarda demasiado en iniciar
√
5.3 Llamada entrante Asegura que el dispositivo puede recibir lla-madas cuando la aplicación está en uso
√
6.1 Operación de la tarjetade memoria
Asegura que la aplicación trabaja correcta-mente removiendo e insertando la tarjeta
√
7.1 Legibilidad Asegura que el contenido es legible√
7.2 Tiempo de lectura Asegura que el tiempo para la lectura delcontenido es adecuado
√
7.3 Repintado de Pantalla Asegura que haya sobreposición de objetos√
7.4 Consistencia Asegura la consistencia de la interfaz deusuario
√
7.5 Facilidad de uso de lasteclas
Asegura que los botones y otros métodos deingreso son fáciles de usar
√
7.6 Velocidad de la aplica-ción
Asegura que la velocidad de la aplicación esaceptable para su propósito
√
7.7 Mensajes de error Asegura que los mensajes de error son enten-dibles y explican el problema
7.8 Función de progreso Asegura una indicación visual del progresoen la ejecución en una función
√
7.13 Respuesta de los senso-res
La respuesta de la aplicación al movimientoo al cambio de dirección no debe perjudicarel uso de la aplicación
√
9.1 Suspender/reanudardesde el menú principal
Asegura que la aplicación se suspende correc-tamente en el menú principal
√
9.2 Suspender/reanudar du-rante la ejecución
Asegura que la aplicación se suspende correc-tamente durante la ejecución
√
10.1 Opción mute Asegura que la aplicación se puede silenciar√
11.1 Ayuda y Acerca de La aplicación debe tener ítems de `Ayuda' y`Acerca de'
√
12.1 Comprobación de lafuncionalidad
Comprueba la funcionalidad general de laaplicación
√
4.3. Aplicación Android
De la tabla 4.1, se puede ver que la aplicación cumple con la mayoría de las
pruebas recomendadas por la UTI, ésto garantiza que la aplicación no presenta
errores ni mensajes que sumen retrasos en la obtención de datos y actualización de
rutas.
4.4. Evaluación al sistema de localización RFID
Los resultados obtenidos de la evaluación al sistema RFID del sistema de eva-
cuación simulado en la maqueta, son:
Al conectar y desconectar el módulo varias veces, el teléfono no presenta erro-
56
4.5 Análisis al sistema de evacuación
res.
El tiempo de reconocimiento del módulo de lectura está al rededor de 2 segun-
dos, sólo cuando se conecta por primera y no es necesario que la aplicación del
sistema de evacuación este funcionando.
El lector RFID está con�gurado para presentar el valor de la etiqueta, sólo
sí, ésta se encuentra en el rango de lectura. Lo que hace que los retrasos en
lectura de etiquetas no sean apreciados por el usuario.
La distancia máxima que puede alejarse el lector, de las etiquetas, es de 6 cm.
Con la presencia de varias etiquetas el lector muestra únicamente el valor de
la etiqueta que tenga la mayor intensidad de campo.
La conexión exitosa entre el teléfono y el módulo, se debe a que es directa por el
puerto USB, por tanto, sólo existirá un dispositivo conectado a la vez. Las posibles
causas de una desconexión lógica del módulo serían debido a defectos en el cable o
en los conectores.
4.5. Análisis al sistema de evacuación
4.5.1. Tiempo máximo de actualización de las alarmas
Del análisis de los tiempos de actualización y los posibles retrasos hechos en las
secciones anteriores, se puede calcular el tiempo máximo que se debería esperar por
la actualización de una alarma, dicho de otra forma, es el tiempo que tardaría el
usuario en ver la alerta en su teléfono desde el instante en que la temperatura superó
el valor máximo.
El tiempo máximo puede calcularse cómo:
T1 = (Tmicro + Tweb + Tjson + Trfid)
Donde:
Tmicro : tiempo total de actualización de las alertas en el teléfono.
Tweb : tiempo máximo que tarda el micro en realizar las lecturas del valor de los
sensores.
Tjson : tiempo máximo de consumo de servicio web desde el teléfono.
Trfid : tiempo de reconocimiento del módulo de lectura RFID.
57
4.5 Análisis al sistema de evacuación
La variable Trfid debe considerarse en caso de que se conecte el módulo en el
momento de iniciar la aplicación, caso contrario es igual a 0.
Los valores máximos para las variables son: Tmicro = 20s., Tweb = 2s., Tjson = 10s.
Entonces el tiempo máximo sería:
T1 = 20 + 2 + 10 + 2 = 34s.
Esta fórmula sirve de igual manera para el sistema de evacuación montado en
un edi�cio. Se debe considerar que el tiempo de actualización de cada lectura de los
sensores, no sea muy corto, porque se generaría muchos datos que pueden saturar
la memoria del servidor, ni tampoco sea tan alto que haga que las alertas lleguen
demasiado tarde. Según la revista online Means of escape1, la clasi�cación para el
edi�cio UGTI de la UTPL, es tipo A y el tiempo de evacuación mínimo recomendado
para éstas construcciones es 3 minutos, éste valor aumenta de acuerdo al número
de personal y salidas disponibles. Un valor razonable para la actualización de la
temperatura en el sistema es 1 minuto.
4.5.2. Etiquetas RFID en la localización
La distancia máxima de lectura del módulo RFID es de 6 cm. al mover el teléfono
por la maqueta, las lecturas corresponden al sector que muestra el teléfono. Se puede
ver en la �gura 4.3 que la posición del teléfono concuerda con la imagen que presenta
en la pantalla.
Figura 4.3: Lectura de etiquetas RFID para localización
1http://www.means-of-escape.com/articles/68/calculating-an-e�ective-means-of-escape/
58
4.5 Análisis al sistema de evacuación
4.5.3. Alarmas mostradas en el teléfono
Para examinar la coherencia entre las imágenes mostradas en el teléfono y las
alertas de los sensores, se simuló alarmas incrementando la temperatura alrededor
de los sensores. En las �guras 4.4 y 4.5, se muestra los resultados obtenidos de las
imágenes del servidor y las obtenidas en el teléfono.
Figura 4.4: Alerta generada en el servidor
Figura 4.5: Alerta vista desde la aplicación Android
4.5.3.1. Resultados al activar alertas simultáneamente
Al detectar cada alerta, el mensaje de evacuación, de la parte inferior de la
aplicación cambia mostrando la salida disponible para evacuar. Con la activación
de varias alarmas la aplicación actualiza la ruta de emergencia y el mensaje de
evacuación presenta las salidas disponibles en ese momento.
59
4.5 Análisis al sistema de evacuación
En la �gura 4.6, se puede ver que se han activado las alarmas en el sector 1 y
sector 4, ver �gura 3.25. Se ve, además el mensaje de evacuación en la parte inferior
y la línea que indica la ruta se dirige únicamente hacia las salidas de emergencia.
Figura 4.6: Aplicación móvil, situación de dos alertas activadas
4.5.3.2. Comportamiento del sistema de evacuación al activarse todas
las alarmas
Con la activación de todas las alarmas de un piso, lo que implica que todas las
salidas de evacuación están bloqueadas, el sistema recomienda al usuario ubicarse
en un sector libre de amenazas y donde se facilite su rescate. La ruta de evacuación
dirige al usuario a este sector y el mensaje le indica que espere la ayuda del cuerpo
de bomberos. En la �gura 4.7, se puede ver que el sector libre de amenazas se recalca
con un cuadrante azul y la ruta de evacuación y el mensaje dirigen al usuario hasta
allí.
4.5.4. Comportamiento del sistema de evacuación con alar-
mas en diferentes pisos del edi�cio
Hasta aquí se analizó el resultado de simulaciones de alertas en varios sensores
del mismo piso. Ahora se procederá a comprobar que los mensajes y las rutas de
evacuación, se actualizan con alarmas generadas en un piso diferente. El objetivo de
60
4.6 Selección de tecnologías para el sistema de evacuación en un edi�cio
Figura 4.7: Captura de pantalla de la aplicación, todas las alertas activadas
estas pruebas es garantizar una ruta de evacuación segura, de acuerdo a la situación
en todo el edi�cio.
Se activó las alertas en el piso inferior de la maqueta, en el sector 5 y sector 7,
ver �gura 3.26.Si el usuario se encuentra en el piso superior, el sistema de evacuación
envía las noti�caciones del piso donde se detecte una alerta. Como se puede ver en
la �gura 4.8, el mensaje de evacuación indica que se ha activado una alerta en el
piso inferior a pesar de encontrarse en un piso distinto.
El sistema también actualiza el mensaje de evacuación. En la �gura 4.9, se puede
ver que la alerta corresponde a las escaleras del piso inferior (sector 5), por tanto el
mensaje de evacuación recomienda usar únicamente la salida de emergencia.
4.6. Selección de tecnologías para el sistema de eva-
cuación en un edi�cio
Las pruebas realizadas permiten constatar la funcionalidad e�ciente del sistema
de evacuación, sin embargo no proporcionan el número exacto de etiquetas RFID y
sensores. En esta sección, determinamos las modi�caciones en tecnología utilizada
para el sistema de evacuación puesto en funcionamiento en un edi�cio, tomando
como base los bloques, de la fase experimental, especi�cados en la metodología.
Presentamos las características y costo de dichas tecnologías, sin tomar en cuenta
el número total de elementos, puesto que eso se podría realizar sólo en el momento
61
4.6 Selección de tecnologías para el sistema de evacuación en un edi�cio
Figura 4.8: Aplicación móvil, alerta en el piso inferior
de implementar y tomando en cuenta las características físicas de la infraestructura
y el plan de evacuación del edi�cio.
En la red de sensores del sistema de evacuación, consideramos que en un edi�cio
se utiliza mayor variedad de sensores para alertar en situaciones de emergencia, sin
embargo sus interfaces de salida son de tipo digital o analógico, por lo que se utilizaría
el mismo módulo de acondicionamiento de señales. Los sensores recomendados se
detallan a continuación:
Botones de pánico y emergencia: son los más comunes en sistemas de
evacuación y son de acción manual, su interfaz de salida es digital. Existen al-
gunos como, botón de emergencia SS075Q1; normalmente abierto y de montaje
super�cial, ver �gura4.10. El botón de pánico YA012 funciona como interrup-
tor de emergencia o llave de emergencia es de montaje en pared o instalación
de montaje oculto.
Sensores de humo: existen en el mercado varios que incorporan detectores
de humo y termostatos con salidas de voltaje analógico o digital. El detector
multisensor XP95 analógico3, incorpora un sensor de humo óptico y un sensor
de temperatura de termostato cuyas salidas se combinan para dar lugar al
1http://www.seco-larm.com/DoubleSp.htm2http://www.hkvstar.com/es/item/panic-button-ya-01.html3http://www.isolse.com.ar/
62
4.6 Selección de tecnologías para el sistema de evacuación en un edi�cio
Figura 4.9: Aplicación móvil, alerta en escaleras del piso inferior
Figura 4.10: Botón de emergencia SS075Q de la empresa SECOALARM
valor analógico �nal. Los Sensores digitales de humo, usan un LED interno y
un fotodiodo en ángulo obtuso. Cuando el humo se introduce en la cámara, el
pulso de luz del LED será dispersado y registrado por el fotodiodo. El voltaje
es analizado y un valor analógico es convertido a una señal digital que se
transmite al modulo de acondicionamiento de señal. Ver �gura 4.13.
Detectores de fuego:1 detectan tanto, la radiación ultravioleta, como la
infrarroja emitidas por el fuego. La �gura 4.14, muestra un sensor de fuego de
la empresa ISOLSE.
El servidor Web conservaría las mismas funciones que en el sistema de evacuación
montado en un modelo a escala.
La aplicación móvil Android, debe programarse teniendo en cuenta el número de
pisos y los planos de evacuación del edi�cio.
1http://deteccion-alarma-contra-incendio.isolse.com.ar/contra-incendios-i.asp
63
4.6 Selección de tecnologías para el sistema de evacuación en un edi�cio
Figura 4.11: Botón de pánico YA-01 de la empresa VSTAR
Figura 4.12: Sensor de humo con salidas analógicas de la empresa ISOLSE
Para el sistema de localización RFID, debe considerarse la distancia máxima a
la que se encontraría el usuario, el rango de lectura del módulo y la distancia y
cantidad de etiquetas RFID. Los dispositivos RFID que proponemos para el sistema
de evacuación montado en el edi�cio son:
Etiqueta pasiva RFID de largo alcance CFTU9101: 1 Tiene un rango de
lectura de 10 m. y de escritura de 3m., cumple el estándar ISO18000-6C(EPC-
Gen2) y trabaja en la frecuencia de 860 a 960MHz. El precio unitario está
alrededor de $1,50 USD.
Etiqueta RFID activa YL-702: 2 El rango de transmisión es de 200 m.,
usa tecnología TDMA y CDMA, y trabaja en la frecuencia de 915MHz. Su
precio unitario está alrededor de $3,00 USD.
1http://www.alibaba.com/product-gs/694545906/long_range_passive_rfid_tag_with.
html?s=p2http://www.alibaba.com/product-gs/272603071/RFID_card_rfid_active_tag_active.
html
64
4.6 Selección de tecnologías para el sistema de evacuación en un edi�cio
Figura 4.13: Sensor de humo con salidas digitales de la empresa ISOLSE
Figura 4.14: Sensor detector de fuego
Módulo de lectura/escritura RFID de largo alcance GAO216010: Tie-
ne un rango de cobertura de 15 m., cumple con estándares EPC Class1, Gen 1
y Gen 2, y trabaja en la frecuencia de 860 a 960 MHz. El precio de una unidad
está alrededor de $100,00 USD.
Finalmente, se debe analizar el plan de evacuación del edi�cio y disponibilidad
física de la infraestructura, para determinar el tipo y cantidad total de dispositivos
que se usaría.
65
4.6 Selección de tecnologías para el sistema de evacuación en un edi�cio
Figura 4.15: Etiqueta pasiva RFID de largo alcance CF-TU9101
Figura 4.16: Etiqueta RFID activa modelo YL-702
Figura 4.17: Módulo de lectura/escritura RFID de largo alcance
66
5
CONCLUSIONES Y TRABAJO
FUTURO
Finalizada la investigación y cumplidos los objetivos propuestos en el presente
proyecto de �n de titulación, exponemos las siguientes conclusiones y recomenda-
ciones.
5.1. Conclusiones
La metodología adoptada para la fase experimental del sistema de evacuación,
permitió desarrollar y probar el sistema por bloques, facilitando la detección
de errores y su corrección.
El tiempo de actualización de las lecturas de los sensores, in�uye de manera
directa al tiempo total de evacuación. Para las pruebas se utiliza un valor
máximo de espera de una alerta de 34 segundos, en cambio si se implementa
el sistema en un edi�cio se con�guraría un tiempo de 1 minuto, tomando en
cuenta la excesiva cantidad de datos que generarían al funcionar el sistema de
manera continúa y la generación oportuna de las alertas.
En el servidor Web se desprecian los valores de tiempo de procesamiento de
datos, la generación de los servicios Web y la publicación de datos en Inter-
net. Por lo que, se podría decir que las rutas de evacuación, en la aplicación
Android, se actualizan de manera inmediata.
Realizados los test de funcionalidad a la aplicación Android, se la clasi�ca de
nivel complejo y cumple con los items para esta clasi�cación; garantizando que
no presentará errores de ejecución, ni mensajes de error que incrementen los
retrasos.
67
5.1 Conclusiones
El requisito de mayor importancia en una aplicación móvil de localización, es
la apariencia grá�ca que le muestra al usuario. Algunas usan una interfaz de
realidad aumentada del edi�cio o modelado 3D, sin embargo, éstas opciones
tienen que ser lo su�cientemente detalladas y claras para que puedan ser com-
prendidas. Una interfaz 2D, requiere pocos detalles y es mucho más fácil que
el usuario entienda su ubicación, debido a que en interfaces 3D, no se puede
manejar las vistas de los planos completos.
La tecnología RFID brinda una gran ventaja al momento de implementar sis-
temas de localización, puesto que los recursos de infraestructura son mínimos,
comparados con sistemas de localización para interiores, como WiFi o Blue-
tooth. Además el costo es mucho menor. El inconveniente es que todos los
teléfonos deberían contar con un lector de etiquetas NFC o RFID, que es la
tendencia del desarrollo de teléfonos inteligentes.
En el sistema de localización RFID, corresponde la ubicación de las etiquetas
con la posición mostrada en la aplicación Android. Para lograrlo se debe con-
siderar el número de etiquetas por cada sector y la distancia entre sí y hasta el
usuario. Del análisis realizado determinamos que las etiquetas deben colocarse
una cada 2 metros como máximo. Garantizando la actualización de la posición
del usuario de manera inmediata.
El sistema de evacuación responde correctamente a alarmas activadas simul-
táneamente, incluso si fueran provenientes de pisos diferentes en el edi�cio.
Se implementó y probó, en un modelo a escala, un sistema de evacuación que
integra diferentes tecnologías, para mostrar la ruta de evacuación desde la
ubicación del usuario, en un teléfono inteligente. La localización se obtiene de
etiquetas RFID leídas con un módulo incorporado al teléfono. La actualización
de rutas de evacuación es posible con la información proporcionada por la red
de sensores.
Las pruebas del sistema de evacuación en un modelo a escala sirven para anali-
zar la funcionalidad del sistema, pero no permite armar un presupuesto exacto
del montaje para un edi�cio. Para ello, debe considerarse también parámetros
externos al sistema, como pueden ser la relevancia de algunos departamentos
en el edi�cio, y las facilidades físicas para la ubicación de sensores.
68
5.2 Recomendaciones
5.2. Recomendaciones
Para implementar el sistema de evacuación en edi�cios se debe modi�car el
módulo de localización RFID, usando tecnología de mayor alcance o con eti-
quetas activas. En el servidor se debe reprogramar las condiciones para el
almacenamiento de las lecturas en la base de datos.
Para obtener mejores resultados al momento de montar el sistema de locali-
zación por RFID, elegir el tipo de tecnología de acuerdo al espacio en el que
se va a aplicar, y tomando en cuenta el número de etiquetas que puede leer el
módulo a la vez.
Para que las pruebas al sistema de evacuación no lleven demasiado tiempo, se
recomienda programar tiempos de lectura y actualización, de pocos segundos.
El sistema permite variar el número de datos recibidos en el servidor con
relación a los que se usaría en un sistema para un edi�cio. Sin embargo, para
un sistema real los tiempos deben estar entre valores que permitan la recepción
oportuna de las alerta y valores que eviten saturar la memoria del servidor,
por exceso de datos.
Se recomienda utilizar una versión completa de los software de programación,
tanto Eclipse como Netbeans, para evitar posibles errores por la ausencia de
librerías.
La generación de un servicio WEB en notación JSON hace que la recepción y
procesamiento de las tramas en el dispositivo móvil sean mas sencillas, puesto
que la información se recibe como texto plano.
Para ubicar los sensores y etiquetas RFID en la maqueta, es necesario conocer
la infraestructura del edi�cio. Dimensionar el número de sensores y etiquetas
RFID tomando en cuenta los lugares relevantes, como pueden ser, pasillos de
mayor a�uencia, salas de servidores y o�cinas administrativas; para garantizar
la e�ciencia del sistema.
Como el módulo de lectura RFID no está registrado por el fabricante del
teléfono es necesario, en el archivo de los permisos de los puertos del teléfono
de desarrollo, asignar permisos de lectura y escritura al puerto USB.
Las rutas de evacuación se eligieron en base a la señalética del edi�cio, debido
a que no se cuenta con un plan de evacuación.
69
5.2 Recomendaciones
Para las situaciones en las que la alarma se origine en las posibles salidas de
emergencia, planteamos como solución dirigir al usuario a un punto despejado
cuya ventana sea de fácil acceso para los organismos de socorro.
70
5.3 Trabajos futuros
5.3. Trabajos futuros
Orientar la aplicación a personas con capacidades especiales. Por ejemplo;
incluir al sistema mensajes de evacuación tomando en cuenta el tipo de dis-
capacidad del usuario, incorporar alertas sonoras a la aplicación para ofrecer
una ayuda más completa e integrar el módulo de conversión de texto a voz,
de Android, para que la ruta de evacuación pueda escucharse.
Incluir a la aplicación la posibilidad de ver la infraestructura en grá�cos de
realidad aumentada, para facilitar la ubicación al usuario. Además, crear ma-
pas completos del edi�cio en 3D para facilitar la navegación, aunque deberían
tener un nivel alto de detalle.
Aumentar las funciones de la aplicación adicionando la información de los sen-
sores propios de los Smartphones, como son, acelerómetros y magnetómetros,
complementando al sistema RFID para que la ubicación dentro del edi�cio sea
más precisa.
Las rutas y lugares de evacuación, en futuros desarrollos, deben considerarse en
base al plan de evacuación del edi�cio. En el teléfono podría verse la señalética
completa del edi�cio y los planos a utilizarse serían los mismos del plan de
evacuación.
El sistema de evacuación podría permitir hacer minería de datos y estudios
estadísticos, para implementar inteligencia arti�cial en la actualización de las
rutas. Dichas rutas tomarían en cuenta la información del personal median-
te RFID y de los sensores en el edi�cio. Los datos que se obtendrían, por
ejemplo, son de sitios de mayor aglomeración, horas en las que la a�uencia
de personas es mayor, determinar lugares propensos a incendios, sectores con
poca movilización de personal, etc.
Se podría crear una red que comunique todos los sistemas de evacuación en
diferentes edi�cios, de manera que el cuerpo de bomberos y grupos de rescate
tengan acceso a la información de estos sistemas, con el �n de detectar las
alertas de emergencia de manera oportuna en dispositivos móviles o por medio
de la aplicación Web.
71
BIBLIOGRAFÍA
[1] �Start Developing iOS Apps Today.� https://developer.apple.com/. Acces-
sed: 29/11/2012.
[2] A. Catalán, Curso Android Desarrollo de Aplicaciones moviles. Junio 2011.
Este trabajo se encuentra bajo una licencia Creative Commons.
[3] R. G. Namje Park, System framework and its aplicattion in mobile r�d service
network. Department of Mechanical and Aerospace Engineering UCLA, 2011.
[4] P. Kumar, Framework of Smart Mobile RFID Network. EDE Deptt, 2011.
Vidya Vihar Institute of Technology.
[5] Wireless Dynamics, http://www.icarte.ca/docs/
SW10-0058-DSiCarte420NFC/RFID&PaymentAdaptorforiPhone4S.
[6] Microelectronics Technology Inc, http://www.rfidconnect.com/
ProductDetails.aspx?id=7b1a0be9-9cdb-494e-b113-21772efbc5c9,
RU-827-100/110 MINI ME UHF RFID Reader for Android Powered Devices.
[7] D. Chittaro, L. y Nadalutti, A Mobile RFID-based System for Supporting Eva-
cuation of Buildings. Dept. of Math and Computer Science, Udine, Italia.
[8] J. Ahn and R. Han, RescueMe: An Indoor Mobile Augmented-Reality Evacua-
tion System by Personalized Pedometry. Department of Computer Science,
University of Colorado.
[9] A. A. K Rakip, B Fatmagul, An evacuation system for extraordinary Indoor
Air Pollution Disaster Circunstances. Universidad Karabuk, Turquía, 2012.
[10] J. Candy, A MOBILE INDOOR LOCATION BASED GIS APPLICATION.
British Columbia Institute of Technology, 2010.
[11] L. M. NI and Y. LIU, LANDMARC: Indoor Location Sensing Using Active
RFID. Kluwer Academic Publishers, 2014.
72
BIBLIOGRAFÍA
[12] A. A.-Z. Fadi Aloul, Nada Aji and N. Fakhro, Mobile RFID Tracking System.
Computer Engineering Department, American University of Shraja.
[13] Q. N. Rossetti and T. Sattar, Simulating Large-Scale Evacuation Scenarios in
Commercial Shopping Districts Methodologies and Case Study. U.S. Depart-
ment of Homeland Security, 1 ed., 2010.
[14] K. C. Jorg Baus and C. Kray, A Survey of Map-based Mobile Guides. Saarland
University, Denmark.
[15] INEC, Reporte anual de estadísticas sobre tecnologías de la información y co-
muniaciones (TIC's 2011). Diciembre 2011.
[16] �About Near Field Communication.� http://www.nearfieldcommunication.
org/about-nfc.html. Accessed: 28/11/2012.
[17] �NFC Signaling Technologies.� http://www.nearfieldcommunication.org/
nfc-signaling.html. Accessed: 28/11/2012.
[18] ITU-R, �Report ITU-R SM.2153-1technical and operating parameters and
spectrum use for short-range radiocommunication devices,� tech. rep., ITU,
http://www.nearfieldcommunication.org/nfc-signaling.html, 2010. Ac-
cessed: 28/11/2012.
[19] w. p. s. LIBERA, RFID: Tecnología, aplicaciones y perspecti-
vas. Málaga, España: Libera Networks, 2010. disponible en:
http://www.libera.net/productos/libera-r�d-library-system.
[20] A. Ramírez, Estudio de la evacuación de ocupantes y control de humo en edi-
�ocio en altura. Universidad Ponti�cia Comillas, 1 ed., 2012.
[21] S. M. Michael McGlennon and B. Turner, Promoting Safe Egress and Evacua-
tion for People with Disabilities. National Disability Authority, 1 ed., 2010.
[22] O. A.-M. L. J. Capote, D. Alvear and A. Cuesta, �Modelado y simulación
computacional de evacuación en edi�cios singulares,� Revista Internacional de
Métodos Numéricos para Cálculo y Diseño en Ingeniería, vol. 25, pp. 227�245,
2009.
[23] M. Harrison, The EPC Network. University of Cambridge, 2004.
[24] H.-h. C. P. H. Yi-Chao Chen, Ji-Rung Chiang and A. W. Tsui, Sensor As-
sisted WiFi Indoor Location System for Adapting to Environmental Dynamics.
National Taiwan University, 2010.
73
BIBLIOGRAFÍA
[25] �Connecting to a MySQL Database.� http://netbeans.org/kb/docs/ide/
mysql.html. Accessed: 20/11/2012.
[26] �Web Service.� http://en.wikipedia.org/wiki/Web_service. Accessed:
26/11/2012.
[27] �Qué bene�cio le aporta Android a Google.� http://www.elandroidelibre.
com/2012/04/que-beneficio-le-aporta-android-a-google.html. Acces-
sed: 28/11/2012.
[28] A. members, UTI Testing Criteria (UTC) for Android applications V1.1. 2012.
74
ANEXOS
75
ANEXO A
Acondicionamiento del dispositivo
móvil para funcionamiento con el
módulo de lectura RFID
La conexión entre el dispositivo Android utilizado (Samsung Galaxy Nexus-ICS-
Maguro) y el módulo de lectura de tarjetas RFID (Sparkfun 125kHz RFID USB
Reader) requiere de una conexión física y una conexión lógica. La conexión física debe
garantizar que el módulo RFID se conecte como dispositivo periférico del teléfono
y reciba el suministro de energía para funcionar. Por otro lado, la conexión lógica
debe garantizar que el teléfono reciba todas las tramas de datos que el módulo RFID
envía.
A.1. Conexión física de los dispositivos
El teléfono Android funciona en modo USB-Host1, lo que signi�ca que éste es
el an�trión usb y puede energizar todos los dispositivos que se conecten al puerto
en este modo. Android soporta USB host desde la versión 3.0. Sin embargo, el
dispositivo no energizará el módulo conectado al puerto al no ser que se conecte
mediante un cable USB tipo OTG2. El puerto de salida del módulo RFID es del
tipo mini USB, en cambio el puerto del teléfono es micro usb, por lo que el cable
OTG deberá tener éste tipo de conectores en sus extremos. La �guraA.1 muestra
el modo de conexión de los cables desde un usb normal para que funcione en modo
otg.
1http://developer.android.com/guide/topics/connectivity/usb/host.html2Usb OTG: Usb On-The-Go http://www.usb.org/developers/onthego/USB_OTG_Intro.
76
A.2 Conexión lógica de los dispositivos
Figura A.1: Cableado para conectores tipo USB normal y USB modo OTG1
El módulo de lectura RFID es el RFID Reader ID-20(SEN-08628), adquiridos
en la tienda de elementos electrónicos por internet Sparkfun2, además se le integra
el módulo RFID USB para que permita la conexión con otros dispositivos por el
puerto serial, cuyo protocolo de comunicación es FTDI3.
Figura A.2: a) módulo de lectura ID-20. b)Placa de montaje RFID USB con interfazmini USB.
A.2. Conexión lógica de los dispositivos
Los dispositivos FTDI funcionan con sus propios drivers, en el caso del módulo
RFID y el dispositivo móvil el driver es el D2XX que puede ser descargado de la web
de los desarrolladores http://www.ftdichip.com/Drivers/D2XX.htm.En adición,
para el sistema operativo Android incluye código para la interface nativa de Java
2https://www.sparkfun.com/products/86283http://www.ftdichip.com/
77
A.3 Funcionamiento del módulo RFID conectado al móvil
(JNI) y una clase de Java D2XX (Java class) que permite a las aplicaciones acceder
fácilmente al driver D2XX. El código para la JNI y el driver se proveen dentro
la librería libftd2xx.jni.so disponible para descargar en la página o�cial de FTDI
sección Android: http://www.ftdichip.com/Android.htm.
A.2.1. Instalación de librerías D2XX JNI
Una ves descargada la librería D2XX, para el sistema operativo Android, se debe
instalarla en el dispositivo y ejecutar la aplicación de prueba del módulo de lectura
RFID.
La instalación de la librería consiste en copiar el archivo dentro de la SDcard
del teléfono y luego poner la dirección en la cual se copio dentro del código de la
aplicación Java.
La librería debe copiarse a la dirección /sdcard/Android/data/com.ftdi.d2xx/libftd2xx-
jni.so. Se puede copiar directamente al teléfono o agregar utilizando la conexión ADB
instalada con las con�guraciones Android SDK para Windows. Para esto es nece-
sario ir al directorio del SDK y buscar la carpeta platform-tool. En esta capeta se
abre una terminal de windows y se introduce el comando:
adb devices Este comando devolverá el número identi�cativo del dispositivo.
Luego se copia la librería con el siguiente comando.
adb push libftd2xx-jni.so /sdcard/Android/data/com.ftdi.d2xx/libftd2xx-jni.so
A.2.2. Cambiar permisos para el funcionamiento de Usb Host
En los directorios del teléfono el archivo que controla los permisos de uso del
puerto usb es el llamado ueventd.rc, que se encuentra dentro del directorio raíz. El
permiso que debe cambiarse es en la línea donde dice:
/dev/bus/usb/* 0660 root usb
Se debe modi�car el número 0660 por 0666 para permitir la lectura y escritura a
través del puerto usb.
A.3. Funcionamiento del módulo RFID conectado
al móvil
Para realizar una prueba a la conexión entre los dispositivos, hemos hecho uso de
la aplicación para Android disponible en la web de los fabricantes1. Esta aplicación1http://www.ftdichip.com/Drivers/D2XX/D2XXSample/D2XXSample.zip
78
A.3 Funcionamiento del módulo RFID conectado al móvil
reconoce automáticamente los dispositivos conectados y permite recibir y enviar
datos a través del puerto usb.
Figura A.3: Captura de pantalla de la aplicación Android para el módulo de lecturaRFID
En la �gura A.3 se ve la aplicación funcionando y resaltado el código leído por
el módulo RFID.
79
ANEXO B
Código de programación del
microcontrolador
*****************************************************/
#include <mega32.h>#include <delay.h>#include <stdlib.h>#include <stdio.h>
#define LEDs PORTB#define red 0b00000001#define green 0b00000010#define yellow 0b00000100#define xtal 8000000L#define baud 9600unsigned char sensor[3];
float vin;int i;int a;int Amp_sensor=100; //factor de amplificación de LM35int alerta_sensor;#define ADC_VREF_TYPE 0x40 //para usar AVCC
float adc_data; /*variable de lectura directa del ADC*/
float read_adc(unsigned char adc_input){ADMUX=adc_input | (ADC_VREF_TYPE & 0xff);// Delay needed for the stabilization of the ADC input voltagedelay_us(10);// Start the AD conversionADCSRA|=0x40;// Wait for the AD conversion to completewhile ((ADCSRA & 0x10)==0);ADCSRA|=0x10;
vin=(ADCW*5);vin=vin/1023;return vin;
80
}
void main(void){
/********puerto de salida para los leds**********/DDRB=0x07; /*toma los 3 bits más significativos para la salida*/
/***********canal y parámetros para ADC************///ADMUX=0x3; /*selecciona el canal de solo lectura*/ADMUX=ADC_VREF_TYPE & 0xff;//ADCSRA=0xCE;/*ADC encendido, /64, por interrupcion e iniciar*/ADCSRA=0x84;/************Comunicacion Serial RS232*************/UBRRH=0x00;UBRRL=0x33; /*BaudRAte*/UCSRB=0x18;/*inicializacion del puerto serial*/UCSRC=0x86;// se setea el bit de paridad, el bit de parada
#asm("sei") /*habilitador global de interrupciones*/
while (1){
PORTB.0=1;
for (i=0;i<8;i++) {adc_data = read_adc(i)*Amp_sensor; /*leerlos bits de la variable*/
if (adc_data > 26.00){
PORTB.2=1;}
else {PORTB.2=0;
}ftoa(adc_data,2,sensor);
printf("\n Sensor%i_%s\r",i+1,sensor);
for(a=0;a<4;a++){PORTB.1=~PORTB.1;delay_ms(100);};
};delay_ms(15000);
};}
81
ANEXO C
Paper
82
