Вы находитесь на странице: 1из 97

UNIVERSIDAD TCNICA PARTICULAR DE LOJA

La Universidad Catlica de Loja

TITULACIN DE INGENIERO EN ELECTRNICA Y TELECOMUNICACIONES

Sistema de evacuacin a travs de dispositivos mviles Android de adquisicin y respuesta de etiquetas RFID para asistencia en situaciones de emergencia
Trabajo de n de titulacin

AUTORES:
Palacios Arias Csar Augusto Rohoden Jaramillo Max Napolen

DIRECTOR:
Ludea Gonzlez Patricia Jeanneth, Ing.

LOJA - ECUADOR

2013

CERTIFICACIN
Ing. Patricia Ludea Gonzlez, DIRECTOR DEL PROYECTO DE FIN DE TITULACIN

CERTIFICA:
Sistema de evacuacin a travs de dispositivos mviles Android de adquisicin y respuesta de etiquetas RFID para asistencia en situaciones de emergencia, realizado por Csar Augusto Palacios Arias y Max Napolen Rohoden Jaramillo; de la titulacin de ELECTRNICA Y TELECOMUNICACIONES, ha sido dirigido y revisado
Que el proyecto: en todas sus partes; por lo mismo, cumple con las exigencias y requisitos legales establecidos por la Universidad Tcnica Particular de Loja, quedando autorizada su presentacin.

Loja, Enero de 2013

F.

Ing. Patricia Ludea Gonzlez

Visto Bueno del Coordinador de Titulacin

Ing. Jorge Luis Jaramillo Pacheco


COORDINADOR DE LA TITULACIN DE ELECTRNICA Y TELECOMUNICACIONES Enero, 2013

F.

CESIN DE DERECHOS

Nosotros,

Csar Augusto Palacios Arias

Max Napolen Rohoden

Jaramillo;

declaramos ser autores del presente trabajo y eximimos ex-

presamente a la Universidad Tcnica Particular de Loja y a sus representantes legales de posibles reclamos o acciones legales.

Adicionalmente declaramos conocer y aceptar la disposicin del Art. 67 del Estatuto Orgnico de la Universidad Tcnica Particular de Loja, que en su parte pertinente textualmente dice: Forman parte del patrimonio de la Universidad la propiedad intelectual de investigaciones, trabajos cientcos o tcnicos y tesis de grado que se realicen a travs, o con el apoyo nanciero, acadmico o institucional (operativo) de la Universidad.

F.

F.

Csar Augusto Palacios Arias


C.I.: 1104444730

Max Napolen Rohoden Jaramillo


C.I.: 1104868391

ii

AUTORA

Las ideas, opiniones, conclusiones, recomendaciones y dems contenido expuesto en el presente informe de tesis; son de absoluta responsabilidad de los autores.

Queda expresamente sealado que la informacin de otros autores incluida en el presente, se encuentra debidamente citada en las fuentes de referencia y bibliografa.

F.

F.

Csar Augusto Palacios Arias


C.I.: 1104444730

Max Napolen Rohoden Jaramillo


C.I.: 1104868391

iii

DEDICATORIA

Dedico este trabajo a mi familia por el apoyo brindado para culminar esta titulacin, y tambin a aquellos estudiantes que encuentren en este trabajo ayuda y motivacin para mejorarlo.

Max

A mis padres y hermanos


Por el apoyo que me brindaron durante la realizacin de este trabajo, por los consejos y motivacin durante toda mi educacin tanto, acadmica, 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 compaeros durante todos estos aos y porque seguimos siendo amigos.

Csar Augusto

iv

AGRADECIMIENTO
Mi agradecimiento a aquellos profesores que dentro como fuera del aula, durante estos cinco aos, fortalecieron el deseo de aprendizaje. En especial, a nuestra directora de tesis por facilitarnos la infraestructura y elementos para desarrollar este trabajo.

Al innito 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 compaeros cada da. A los profesores que estuvieron detrs de todo lo aprendido, y la directora del proyecto quien gui nuestro trabajo durante todo este tiempo.

Gracias de corazn. Csar Augusto

ndice general
CERTIFICACIN CESIN DE DERECHOS AUTORA DEDICATORIA AGRADECIMIENTO ndice de guras ndice de tablas Resumen 1. ALCANCE DE LA INVESTIGACIN
1.1. Objetivos 1.1.1. 1.1.2. 1.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objetivo General

i ii iii iv v x xiii xiv

1
1 1 1 2

Objetivos Especcos . . . . . . . . . . . . . . . . . . . . . . .

Justicacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2. MARCO REFERENCIAL
2.1. Sistema de comunicacin de campo cercano por radiofrecuencia 2.1.1. 2.1.2. . . . Comunicacin de campo cercano . . . . . . . . . . . . . . . . . Identicacin por radiofrecuencia 2.1.2.1. 2.1.2.2. 2.1.2.3. 2.2. 2.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3
3 3 4 4 5 6 7 7 8

Elementos de un sistema RFID Frecuencias de funcionamiento

Estandarizacin para sistemas RFID

Tecnologa RFID en dispositivos mviles

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

Desarrollo de aplicaciones para dispositivos mviles 2.3.1.

Desarrollo de aplicaciones para dispositivos mviles Apple

vi

NDICE GENERAL
2.3.1.1. 2.3.2. 2.4. Funcionamiento de una aplicacin nativa Apple . . . . . . . . . . . . . . . . . . 8 9 11 11 12 13 16 17 18 19

Desarrollo de aplicaciones Android

Estado del Arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1. 2.4.2. 2.4.3. 2.4.4. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estudio de una situacin de emergencia . . . . . . . . . . . . . Aplicaciones con RFID en dispositivos mviles . . . . . . . . . Desarrollo de aplicaciones para situaciones de emergencia . . . 2.4.4.1. 2.4.4.2. 2.4.4.3. 2.4.5. Aplicacin desarrollada en la Universidad de Udine . Aplicacin RescueMe . . . . . . . . . . . . . . . . . . Desarrollos de la Universidad de Karabuk . . . . . .

Situacin de aplicaciones en dispositivos mviles para localizacin en interiores . . . . . . . . . . . . . . . . . . . . . . . . 2.4.5.1. Aplicacin mvil para localizacin en interiores basada en sistemas de localizacin geogrca . . . . . . 2.4.5.2. LANDMARC: Localizacin en interiores utilizando RFID Activas . . . . . . . . . . . . . . . . . . . . . . 2.4.5.3. Sistema de rastreo mvil RFID . . . . . . . . . . . . 23 23 22 21

3. MATERIALES Y MTODOS
3.1. 3.2. Metodologa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Seleccin de materiales . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1. 3.2.2. Materiales para la red de sensores . . . . . . . . . . . . . . . . Montaje del servidor Web 3.2.2.1. 3.2.2.2. 3.2.2.3. 3.2.2.4. 3.2.2.5. 3.2.3. . . . . . . . . . . . . . . . . . . . .

25
25 27 27 28 28 29 29 30 30 32 32 32

Software para la Base de Datos . . . . . . . . . . . . Preparacin de la Base de Datos MySQL . . . . . . . Software para la Aplicacin Web . . . . . . . . . . . . .

Preparacin del software para la Aplicacin Web

Generacin del servicio web en Netbeans . . . . . . .

Desarrollo de Aplicacin mvil Android . . . . . . . . . . . . . 3.2.3.1. 3.2.3.2. 3.2.3.3. Software para desarrollo aplicaciones Android Entornos de desarrollo de aplicaciones Android . . . . . . .

Seleccin del programa para desarrollo de aplicaciones Android . . . . . . . . . . . . . . . . . . . . . . . 33 34 35 36

3.2.3.4. 3.2.3.5. 3.2.3.6. 3.2.3.7.

Preparacin del IDE Eclipse . . . . . . . . . . . . . . Consumo del servicio web desde el dispositivo mvil . Retrasos en aplicaciones Android . . . . . . . . . . .

Tiempos de retraso de la aplicacin de evacuacin Android/RFID . . . . . . . . . . . . . . . . . . . . . 36

vii

NDICE GENERAL
3.2.3.8. 3.2.3.9. Tiempo de puesta en marcha de la aplicacin . . . . 37

Tiempo de reconocimiento del mdulo de lectura RFID 37 38

3.2.3.10. Tiempo de lectura de una tarjeta . . . . . . . . . . . 3.2.3.11. Tiempo de actualizacin de la posicin en el plano segn la etiqueta RFID . . . . . . . . . . . . . . . . . .

38 38

3.2.3.12. Tiempo de actualizacin del cono de orientacin

3.2.3.13. Tiempo de recepcin de alarmas de fuego y sugerencias de evacuacin . . . . . . . . . . . . . . . . . . . 38 39 39 39 40 40 40 43 44 44 45 45 47 48 48 50 50 51 52

3.2.3.14. Tiempo de ejecucin de una llamada de emergencia . 3.2.4. Prototipo de lectura de etiquetas RFID y dispositivo mvil . . 3.2.4.1. 3.2.4.2. 3.2.5. Caractersticas Lgicas . . . . . . . . . . . . . . . . . Caractersticas Fsicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Montaje del sistema de evacuacin 3.2.5.1.

Caractersticas, alcances y limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2.6.

Modelado de la infraestructura 3.2.6.1. 3.2.6.2. Ubicacin de sensores

Ubicacin de tarjetas RFID

3.3.

Pruebas y optimizacin del sistema de evacuacin 3.3.1.

Prueba al desempeo de la aplicacin . . . . . . . . . . . . . . 3.3.1.1. 3.3.1.2. 3.3.1.3. 3.3.1.4. Aplicacin simple . . . . . . . . . . . . . . . . . . . . Aplicacin Framework . . . . . . . . . . . . . . . . .

Aplicacin Compleja . . . . . . . . . . . . . . . . . . Clasicacin UTC de la aplicacin . . . . . . . . . .

3.3.2.

Procedimientos para las pruebas al sistema . . . . . . . . . . . 3.3.2.1. 3.3.2.2. 3.3.2.3. Procedimiento para la evaluacin a la red de sensores Procedimiento para evaluacin de Servidor Web . . . Procedimientos para evaluacin de la Aplicacin Android . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2.4. Procedimiento para evaluacin del sistema de localizacin RFID . . . . . . . . . . . . . . . . . . . . . . 3.3.2.5. Anlisis al Sistema de Evacuacin RFID . . . . . . .

52

53 53

4. ANLISIS DE RESULTADOS
4.1. 4.2. 4.3. 4.4. 4.5. Red de sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Servidor Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54
54 55 56 56 57

Aplicacin Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . Evaluacin al sistema de localizacin RFID . . . . . . . . . . . . . . . Anlisis al sistema de evacuacin . . . . . . . . . . . . . . . . . . . .

viii

NDICE GENERAL
4.5.1. 4.5.2. 4.5.3. Tiempo mximo de actualizacin de las alarmas . . . . . . . . Etiquetas RFID en la localizacin . . . . . . . . . . . . . . . . Alarmas mostradas en el telfono 4.5.3.1. 4.5.3.2. . . . . . . . . . . . . . . . . 57 58 59 59

Resultados al activar alertas simultneamente . . . . Comportamiento del sistema de evacuacin al activarse todas las alarmas . . . . . . . . . . . . . . . . .

60

4.5.4.

Comportamiento del sistema de evacuacin con alarmas en diferentes pisos del edicio . . . . . . . . . . . . . . . . . . . . 60 61

4.6.

Seleccin de tecnologas para el sistema de evacuacin en un edicio

5. CONCLUSIONES Y TRABAJO FUTURO


5.1. 5.2. 5.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

67
67 69 71

BIBLIOGRAFA ANEXOS

72 75

A. Acondicionamiento del dispositivo mvil para funcionamiento con el mdulo de lectura RFID 76
A.1. Conexin fsica de los dispositivos . . . . . . . . . . . . . . . . . . . . A.2. Conexin lgica de los dispositivos . . . . . . . . . . . . . . . . . . . 76 77 78 78 78

A.2.1. Instalacin de libreras D2XX JNI . . . . . . . . . . . . . . . . A.2.2. Cambiar permisos para el funcionamiento de Usb Host . . . .

A.3. Funcionamiento del mdulo RFID conectado al mvil . . . . . . . . .

B. Cdigo de programacin del microcontrolador C. Paper

80 82

ix

ndice de guras
2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8. 2.9. Sistema RFID bsico . . . . . . . . . . . . . . . . . . . . . . . . . . . Frecuencias de funcionamiento de RFID . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5 8 9 13 14 14 15

Capas del sistema operativo mvil de Apple[11]

Bloques bsicos de una aplicacin para Android [12] . . . . . . . . . . Lnea temporal del desarrollo de evacuacin de una emergencia . . . . Ejemplo de aplicacin RFID-reader-equipped mobile phone [17] . . .

Modelo de comunicacin de datos RFID [16] . . . . . . . . . . . . . . Adaptador iCarte para iPhone de la empresa Wireless Dynamics[19] . Adaptador MINI ME RFID Reader para Android de la empresa MTI [20] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16 17 19

2.10. Modelo de realidad aumentada del edicio [2] 2.11. Aplicacin RescueMe en uso: mapa 3D y 2D [3]

. . . . . . . . . . . . . . . . . . . . . . . . .

2.12. Simulacin en Software de la aplicacin RescueMe: casos de distribucin de personal [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.13. Sistema de evacuacin ptimo [4] . . . . . . . . . . . . . . . . . . . . 20 21 22 23 24 26 27 28 29 30 30 31 31 32

2.14. PDA Display [22] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.15. Lector y etiquetas RFID utilizadas en el prototipo LANDMARC[23] . 2.16. Arquitectura de sistema de rastreo por RFID [24] 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. 3.8. 3.9. Fase experimental del sistema de evacuacin Sensor de temperatura LM35 . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

Mdulo de acondicionamiento de seales de los sensores . . . . . . . . Sistema de Gestin de Base de Datos MySQL Base de datos MySQL y conexin JDBC Primefaces: librera para la aplicacin web . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Extensiones aadidas a la Aplicacin web . . . . . . . . . . . . . . . . Generacin del servicio web . . . . . . . . . . . . . . . . . . . . . . .

Seleccin de la base de datos para generar el servicio web . . . . . . .

3.10. Eclipse Indigo: IDE seleccionado para desarrollo de la aplicacin Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

NDICE DE FIGURAS
3.11. Paquete ADT para Windows . . . . . . . . . . . . . . . . . . . . . . . 3.12. Paquetes importados a la aplicacin Android/RFID . . . . . . . . . . 3.13. Paquetes importados para consultar el servicio web . . . . . . . . . . 34 35 35 36 36 37 40 41 42 42 43 43 44 45 46 47 48 54 55 58 59 59 60 61 62 63 63 64 64 65 65 66 66 66 77

3.14. Cdigo para consumir el servicio web . . . . . . . . . . . . . . . . . . 3.15. Mensaje Android ANR . . . . . . . . . . . . . . . . . . . . . . . . . . 3.16. Pantalla de inicio de la Aplicacin . . . . . . . . . . . . . . . . . . . . 3.17. Trama de envo de datos de la tarjeta RFID 3.18. Montaje del prototipo: captura lateral . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

3.19. Respaldo de las lecturas de los sensores . . . . . . . . . . . . . . . . . 3.20. Pgina de ingreso y autenticacin . . . . . . . . . . . . . . . . . . . . 3.21. Lectura en tiempo real de los sensores . . . . . . . . . . . . . . . . . . 3.22. Grco Temperatura vs Tiempo de los sensores . . . . . . . . . . . .

3.23. Planos de los pisos del edicio con detalle de las zonas de peligro . . . 3.24. Maqueta para probar el sistema de evacuacin . . . . . . . . . . . . . 3.25. Sensores piso superior de la maqueta . . . . . . . . . . . . . . . . . .

3.26. Sensores piso inferior de la maqueta . . . . . . . . . . . . . . . . . . . 3.27. Ubicacin de tarjetas RFID en la parte posterior de la maquetas . . . 4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. 4.8. 4.9. Formato de datos enviados desde el microcontrolador Trama en notacin JSON generada de una alerta Lectura de etiquetas RFID para localizacin . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . .

Alerta generada en el servidor . . . . . . . . . . . . . . . . . . . . . . Alerta vista desde la aplicacin Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Aplicacin mvil, situacin de dos alertas activadas

Captura de pantalla de la aplicacin, todas las alertas activadas Aplicacin mvil, alerta en el piso inferior

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Aplicacin mvil, alerta en escaleras del piso inferior

SECOALARM . . 4.11. Botn de pnico YA-01 de la empresa VSTAR . . . . . . . . . 4.12. Sensor de humo con salidas analgicas de la empresa ISOLSE 4.13. Sensor de humo con salidas digitales de la empresa ISOLSE .
4.10. Botn de emergencia SS075Q de la empresa 4.14. Sensor detector de fuego 4.15. Etiqueta pasiva RFID de largo alcance CF-TU9101

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.16. Etiqueta RFID activa modelo YL-702 . . . . . . . . . . . . . . . . . . 4.17. Mdulo de lectura/escritura RFID de largo alcance . . . . . . . . . .

A.1. Cableado para conectores tipo USB normal y USB modo OTG . . . . A.2. a) mdulo de lectura ID-20. b)Placa de montaje RFID USB con interfaz mini USB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

xi

NDICE DE FIGURAS
A.3. Captura de pantalla de la aplicacin Android para el mdulo de lectura RFID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

xii

ndice de tablas
3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 4.1. Bloques de la fase experimental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 33 40 45 49 51 56 IDE's para desarrollo de aplicaciones Android Caractersticas del mdulo de lectura RFID

Cantidad tarjetas, etiquetas RFID y sensores por piso . . . . . . . . . Test para aplicaciones Simples y Framework Test aplicables a la aplicacin Android/RFID . . . . . . . . . . . . . . . . . . . . . . . . . . .

Resultado de tests UTI a la aplicacin Android RFID . . . . . . . . .

xiii

Resumen
En el presente proyecto se desarrolla un sistema de evacuacin a travs de dispositivos mviles Android para asistencia personalizada en situaciones de emergencia. Se accede al sistema por medio de una aplicacin mvil, la cual indica al usuario su ubicacin dentro del edicio y la ruta ms corta y segura de evacuacin. El usuario recibe las indicaciones a travs de planos 2D con rutas de evacuacin actualizables y por medio de mensajes indicndole qu lugares evitar y cul salida tomar.

El sistema integra varias tecnologas y lenguajes de programacin para que la evacuacin sea eciente. Para la ubicacin del usuario dentro del edicio se usa la tecnologa RFID ubicando etiquetas en pasillos, escaleras y salidas de emergencia y acoplando un mdulo de lectura RFID al dispositivo mvil. Para la actualizacin peridica de las rutas y mensajes de evacuacin se instalaron sensores en pasillos y ocinas, y se conectaron a un servidor, por medio de un mdulo de adquisicin, para que ste inalmbricamente actualice los datos del dispositivo mvil.

xiv

1 ALCANCE DE LA INVESTIGACIN
1.1. Objetivos
1.1.1. Objetivo General
Desarrollar un sistema de evacuacin a travs de dispositivos mviles Android de adquisicin y respuesta de tarjetas RFID para asistencia en situaciones de emergencia.

1.1.2. Objetivos Especcos


1. Redactar el estado del arte relacionado con los sistemas de evacuacin en dispositivos mviles. 2. Desarrollar la interfaz dispositivo mvil-lector RFID (hardware-software). 3. Determinar las caractersticas del prototipo y los escenarios de prueba para la aplicacin. 4. Desarrollar el sistema de evacuacin en base a mdulos para localizacin en interiores, direccionamiento, actualizacin de rutas y mensajes de evacuacin. 5. Demostrar el funcionamiento del sistema de evacuacin en un modelo a escala del edicio. 6. Realizar pruebas y optimizar el prototipo, deniendo tiempos de actualizacin y respuesta. 7. Analizar los resultados obtenidos.

1.2 Justicacin

1.2. Justicacin
La evacuacin de un determinado lugar (edicios, fbricas, supermercados) en caso de emergencia (un incendio, terremotos, o inundaciones) ha constituido desde tiempo atrs una preocupacin continua para el sector la seguridad ciudadana. Existen varios anlisis acadmicos de situaciones de evacuacin desde los ms bsicos, como el de metodologa esttica, hasta los que han arrojado mejores resultados, como el de metodologa de modelado [1]. Este inters por los sistemas de evacuacin se ha visto reejado en varios proyectos de desarrollo de aplicaciones mviles para los ocupantes dentro de un edicio [2] [3] [4] [5]. Estos proyectos estudian una falencia de los procesos de evacuacin e incluso de la infraestructura, y en base a sta desarrollan una aplicacin mvil que facilite la salida de los ocupantes haca una zona segura, en una situacin de emergencia. Algunas de estas aplicaciones requieren de montaje de infraestructura costosa en el edicio, mientras que, otras slo hacen uso de los sensores propios del telfono mvil. La mayora de estos proyectos de evacuacin citados se desarrollan en pases del primer mundo, en donde, el ndice de penetracin del Internet es alto. En la Unin Europea (UE) la media de este ndice es del 68 % . En Ecuador, segn estadsticas del INEC (Instituto Nacional de Estadsticas y Censos) a Diciembre del 2011, el 31.4 % de la poblacin utiliz Internet. De este grupo un 62.5 % lo hizo fuera de sus hogares, es decir, en centros de acceso pblico, en instituciones educativas y en el trabajo; lugares adecuados para la aplicacin de un sistema de evacuacin basado en dispositivos mviles[6]. Por otro lado, slo un 8,4 % de los ecuatorianos, que tienen un telfono celular activo (46.6 %), poseen un smartphone, es decir, menos de la media de Latinoamrica (17 %)

y muy por debajo de la media comunitaria de

banda ancha mvil en la UE (43.1 %). Sin embargo, la tendencia en Latinoamrica es reducir la brecha digital con los pases del primer mundo y subsecuentemente la implementacin de los sistemas tecnolgicos ms avanzados, como son los sistemas de evacuacin basados en dispositivos mviles. Se propone un sistema de evacuacin que incorpore varias tecnologas, logrando un balance entre precisin de ubicacin y costo de montaje. El sistema integra la plataforma de desarrollo Android, tecnologa RFID para la localizacin, red de sensores para la actualizacin de las rutas de evacuacin e interfaz grca en base a planos del edicio.

mayor-penetracioninternet-movil-ue/537595.shtml 2 http://www.coberturadigital.com/2012/02/16/internet-en-ecuador-smartphones-gananterreno/
2

1 http://www.rtve.es/noticias/20120618/espana-entre-paises-mas-caros-

2 MARCO REFERENCIAL
2.1. Sistema de comunicacin de campo cercano por radiofrecuencia
2.1.1. Comunicacin de campo cercano
Los sistemas de comunicacin de campo cercano conocidos por sus siglas en Ingls como NFC (Near Field Communications), son una forma de comunicacin sin contacto entre dispositivos como smartphones o tablets. Permiten el intercambio de informacin a travs de ondas de radio frecuencia (RF) facilitando las transacciones electrnicas, intercambio de contenido digital, y la conexin entre dispositivos. Es una evolucin de las tecnologas originalmente usadas para identicacin por radio frecuencia o RFID (Radio Frecuency IDentication) y los sistemas de pago electrnico. Las especicaciones para las tarjetas de identicacin, de proximidad y de circuitos integrados RFID las dicta el estndar ISO/IEC 14443 . NFC conserva la interoperabilidad entre diferentes mtodos de comunicacin inalmbrica, tales como Bluetooth u otros estndares NFC como FeliCa . El NFC Forum , fundado en 2004 por Sony, Nokia y Philips, es el organismo internacional que hace cumplir estrictamente los estndares de NFC con el n de obtener dispositivos completamente compatibles [7]. Los sistemas de comunicacin NFC constan de dos elementos: un dispositivo maestro y otro esclavo. El dispositivo maestro es un mdulo de lectura, y el esclavo, etiquetas NFC que almacenan la informacin codicada.

csnumber=39693
2 FeliCa

1 http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?

co.jp/en/ 3 http://www.nfc-forum.org

es el sistema NFC desarrollado por Sony para Japn http://www.felicanetworks.

2.1 Sistema de comunicacin de campo cercano por radiofrecuencia


El lector es capaz de identicar las etiquetas cercanas por ondas de radio y adems de diferenciar el tipo de comunicacin de campo cercano de la que se trate. La etiqueta se activa con la presencia del campo RF, el lector establece la comunicacin usando el esquema de modulacin, codicacin a nivel de bit, velocidad de bit, y otros parmetros asociados con los mtodos de sealizacin [8]. La comunicacin entre sistemas NFC es activa o pasiva. Activa, en donde ambos generan sus propios campos electromagnticos, o de manera pasiva, en donde un dispositivo genera el campo RF y el otro elemento se activa por induccin.

2.1.2. Identicacin por radiofrecuencia


La tecnologa RFID es una aplicacin especca de los sistemas NFC, usada en sistemas de identicacin de personas, animales, vehculos o accesorios. Se aplica tambin en sistemas de localizacin y rastreo de mercanca. Los sistemas RFID permiten la identicacin de manera inalambrca y sin necesidad de lnea de vista directa [9]. Esta identicacin se logra al incorporar un transpondedor al objeto, el cual transmite los datos que contiene al ser interrogada por un lector RFID. Aunque la aplicacin natural de la tecnologa es dentro de la cadena de produccin y distribucin, aparecen, cada da, nuevas aplicaciones y oportunidades de negocio alrededor de las variantes de uso de esta tecnologa y su incorporacin dentro de sistemas.

2.1.2.1. Elementos de un sistema RFID


Un sistema RFID bsico se forma, cmo se ve en la gura 2.1, por un lector con una o ms antenas, etiquetas de identicacin y software que realice el procesamiento de la informacin recogida por los lectores [10].

Figura 2.1:

Sistema RFID bsico

2.1 Sistema de comunicacin de campo cercano por radiofrecuencia


Las etiquetas RFID mantienen la unicidad de cdigo identicador, es decir un nmero nico, registrado en el EPC (Electronic Product Code), que identica de manera inequvoca 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 caractersticas fsicas, es decir, que al aumentar la frecuencia de operacin se hace uso de antenas y circuitos integrados ms pequeas, posibilitando as, la reduccin de costos de produccin. Adems, condiciona la propagacin del campo electromagntico, afectando a la distancia mxima de lectura, velocidad de transmisin, sensibilidad de los materiales, incluso limitando las aplicaciones comerciales para las que se puede utilizar la tecnologa RFID. Esto se lo puede apreciar en la gura 2.2:

Figura 2.2:

Frecuencias de funcionamiento de RFID

Dependiendo de la frecuencia, la comunicacin 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 magntico 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 modulacin y poder transmitir los datos. El acoplamiento capacitivo se usa para frecuencias UHF y microondas. El lector enva una seal RF que la etiqueta recibe, modula y reeja haca el lector. Dependiendo si las etiquetas son pasivas o activas, tomarn de la seal su alimentacin o no.

2.1 Sistema de comunicacin de campo cercano por radiofrecuencia 2.1.2.3. Estandarizacin para sistemas RFID
Numerosos organismos regulatorios inuyen en la estandarizacin de la tecnologa RFID. La ISO (International Organization for Standardization ) dene algunos estndares, a nivel comercial e industrial, para las aplicaciones y rangos de frecuencia de la tecnologa RFID. La IEC (International Electrotechnical Commission), en cambio, impulsa la cooperacin internacional para la estandarizacin en los campos de la electrnica y tecnologa. Entre algunas de las normas de ambas organizaciones, tenemos:

ISO 11784 e ISO 11785: Identicacin animal por radiofrecuencia. Estructuras de cdigo y conceptos tcnicos ISO/IEC 14443: Tarjetas de identicacin, tarjetas con circuitos integrados y tarjetas de proximidad. ISO/IEC 18000: RFID para gestin de artculos. Contiene la descripcin de los diferentes rangos de frecuencia y las aplicaciones. ISO/IEC TR 18046: Mtodos para pruebas de rendimiento para dispositivos RFID.

El estndar en que se basa el sistemas de evacuacin RFID es el ISO/IEC 14443. Una organizacin que apoya la industria RFID, es EPCGlobal, la cual establece y mantiene la red EPCGlobal (EPCGlobal Network) como estndar mundial para identicacin automtica de objetos. Entre los estndares para RFID podemos mencionar:

Formato lgico de los datos en una etiqueta EPC. Protocolo de comunicacin:

Clase 0 a 900 MHz. Clase 1 a 13,56 MHz. Clase 1 para el rango de 860 MHz a 930 MHz.

La especicacin ONS (Object Name Service), para la red global, que retiene la informacin sobre cualquier objeto etiquetado con EPC en el mundo.

1 http://www.iso.org/iso/home.html

2.2 Tecnologa RFID en dispositivos mviles

2.2. Tecnologa RFID en dispositivos mviles


Los avances en cuanto a diseo de microchips da lugar a completos circuitos en dispositivos muy pequeos permitiendo incorporar sensores en smartphones y tablets. Esta tendencia representa un avance signicativo en cuanto a obtencin de informacin directamente digitalizada, es as que, se puede estar al tanto del clima de cualquier parte del mundo en cuestin de segundos. Esta idea se ampla ms an con la incorporacin de la tecnologa RFID en smartphones y tablets, que permitira saber no nicamente informacin del clima sino, la identicacin de personas, la ubicacin, rastreo de objetos, manejo de inventarios, etc. Samsung

la principal compaa de venta de dispositivos de ltima generacin

bajo la plataforma Android, ha lanzado a la venta algunos smartphones con la tecnologa NFC incorporada; por mencionar algunos estn los Nexus 4 y Nexus 7, Galaxy S III

y Galaxy Note. Otras empresas como LG tienen en el mercado los de

la versin Optimus L5 y Optimus L7, por su parte Sony tambin a lanzado los de la gama Xperia con la tecnologa NFC. Algunas de las aplicaciones mviles desarrolladas para interaccin con NFC son NFC TagInfo y NFC TagWriter. La primera permite visualizar en la pantalla del telfono, el cdigo de cualquier etiqueta NFC y la segunda permite la lectura y escritura de etiquetas NFC activas. Para los dispositivos que no traen incorporada la tecnologa NFC o RFID, se han desarrollado libreras especcas las cuales pueden incorporarse a las aplicaciones, mientras que la conexin con los dispositivos se logra por el puerto USB.

2.3. Desarrollo de aplicaciones para dispositivos mviles


Dada la importante demanda y buena acogida que han tenido los telfonos inteligentes, muchas compaas 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 desarrollador tenga un alto nivel de conocimiento de programacin para realizar una aplicacin bsica. Se han lanzado al mercado opciones como App Inventor

desarrollado por

programadores del MIT , tan fcil de usar como arrastrar bloques para disear una

1 http://www.samsung.com/latin/aboutsamsung/

GT-I9300MBLTTT 3 http://appinventor.mit.edu/
4 Massachusetts

2 http://www.samsung.com/latin/consumer/mobile-phones/mobile-phones/smartphone/

Institute of Technologyhttp://www.mit.edu/
7

2.3 Desarrollo de aplicaciones para dispositivos mviles


aplicacin Android bsica. Para aplicaciones especializadas o de mayor complejidad comnmente se utiliza algn IDE (Integrated Development Environment) de Java, como puede ser Eclipse Indigo o Netbeans.

2.3.1. Desarrollo de aplicaciones para dispositivos mviles Apple


Las aplicaciones para Iphone o Ipad funcionan en el sistema operativo mvil de Apple, conocido como iOS (iPhone Operating System). Pueden desarrollarse de dos maneras: mediante aplicacin web o como aplicacin nativa. Mediante aplicacin web, consiste en una aplicacin desarrollada en HTML, CSS, JavaScript, que funciona en un servidor al cual el smartphone puede tener acceso y visualizar mediante el cdigo HTML generado por PHP, NET o Java. Las aplicaciones nativas en cambio son aquellas que vienen con los dispositivos electrnicos o que pueden ser compradas 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 aplicacin nativa Apple


Apple proporciona la imagen de la gura 2.3 para entender ms fcilmente el funcionamiento de una aplicacin para IOS.

Figura 2.3:

Capas del sistema operativo mvil 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 aplicacin en s. Media.- Contiene todos los archivos que la aplicacin tendr, es decir, audio, video, imgenes, soporte para grcos 3D OPENGL ES, etc.

2.3 Desarrollo de aplicaciones para dispositivos mviles


Core Services.- Provee los servicios fundamentales para la aplicacin, por ejemplo acceso a contactos, o base de datos SQLITE, etc. Core OS.- Es el ncleo del sistema operativo, gestiona archivos, memoria, seguridad y comunicacin.

2.3.2. Desarrollo de aplicaciones Android


Android utiliza de base el Kernel de Linux , debido a su robustez y la implementacin de funciones bsicas para otros sistemas operativos, tales funciones pueden ser: seguridad, administracin de memoria y procesos, implementacin de conectividad de red y varios controladores para comunicacin con dispositivos fsicos [12]. El desarrollo de aplicaciones para Android se resume en bloques bsicos que se muestran en la gura 2.4. Los componentes bsicos de una aplicacin son actividades, intentos, vistas, servicios, proveedores de contenido y receptores de broadcast; convencionalmente se utiliza la traduccin al ingls de los trminos por la compatibilidad con los lenguajes de programacin, es decir que se preere los trminos: activities, intents, views, services, content providers y broadcast receivers.

Figura 2.4:

Bloques bsicos de una aplicacin para Android [12]


1
.

A continuacin se describe cada bloque constituyente de la aplicacin

1 http://developer.android.com/guide/components/fundamentals.html

2.3 Desarrollo de aplicaciones para dispositivos mviles Activities:


Es una ventana que representa cada una de las pantallas de la

aplicacin. Por ejemplo, una pantalla de bienvenida al iniciar la aplicacin, sera una activity.

Intents: son mensajes utilizados para lanzar operaciones a mitad de procesos,


pueden ser noticaciones, 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 aplicacin.

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 informacin


en el telfono como son los archivos de audio, video, contactos, etc.

Manifest: es el archivo que contiene la conguracin de la aplicacin, en ella


se agrega las

activities

y sus propiedades, adems se puede asignar permisos

a la aplicacin para acceder a informacin de contactos, de Internet, a datos del usuario, etc.

10

2.4 Estado del Arte

2.4. Estado del Arte


2.4.1. Introduccin
Desde la aparicin de los PDA (Personal Digital Assistant) y de los telfonos inteligentes en la dcada de los 90 y en el ao 2000, respectivamente, su popularidad ha crecido vertiginosamente a la par que su precio es algo ms razonable y la aprobacin del pblico en general cada vez es ms favorable. Se suma a esto las numerosas aplicaciones y servicios a los cuales se puede acceder desde estos dispositivos: GPS, banca electrnica, correo electrnico, redes sociales, pago de servicios bsicos (electricidad agua potable), consulta del estado meteorolgico, aviso de desastres, etc. Una proyeccin en el futuro nos deja claro como muchas compaas, hospitales, negocios y centros comerciales conarn en los telfonos inteligentes y, subsecuentemente, dependern de stos para su mejor funcionamiento. Un factor clave en el desarrollo de estos sistemas es la posibilidad de que el usuario o un grupo de desarrolladores de software puedan crear sus propias aplicaciones. De esta manera, el tiempo que demora una aplicacin en salir al mercado es menor y su utilidad ms especca, porque se crea para una necesidad determinada. Ms an, 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 mviles en sensores disponibles todo el tiempo, interactuando entre s y con el ambiente, realizando recoleccin de datos los cuales permitirn acciones con o sin la intervencin humana a ciertos eventos. Dicha tendencia incluye tambin la reduccin de tiempo de obtencin de informacin 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 conexin a Internet en cualquier momento y lugar. Tcnicamente, es la integracin de sensores y dispositivos en objetos cotidianos de modo que puedan estar conectados a Internet a travs de redes jas o mviles. De este modo se podr pensar en sistemas de actualizacin de informacin, mediante sensores, cualquier momento del da. Siguiendo estos conceptos, se ha desarrollado un sistema de localizacin dentro de un edicio, capaz de dar a conocer al usuario las rutas de evacuacin e informacin adicional para situaciones de emergencia. El objetivo del sistema es que las personas que laboran en el edicio, como las que no, se entrenen y afronten una situacin de emergencia nicamente haciendo uso de la aplicacin en su celular y basndose en informacin verdica y en tiempo real.

11

2.4 Estado del Arte

2.4.2. Estudio de una situacin de emergencia


En esta seccin 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 edicio, especcamente incendios, y los factores que afectan a los ocupantes en la evacuacin del mismo. La principal prioridad en un edicio ante una situacin de emergencia es que la totalidad de los ocupantes puedan desplazarse hasta un lugar seguro en el mnimo tiempo con las mnimas garantas de seguridad. Este tiempo de evacuacin (Tevac ) se dene en [13] segn la siguiente frmula:

Tevac = (Tdet + Tresp + Tdesp )


Donde:

Tevac

: tiempo de evacuacin.

Tdet : tiempo de deteccin. Tresp : tiempo de pre-movimiento Tdesp


: tiempo de desplazamiento.

(respuesta de los usuarios).

Cada una de stas variables se denen como:

Tiempo de deteccin: tiempo que tarda el sistema de deteccin en activar e iniciar la secuencia de noticacin de alarma.

Tiempo de respuesta:

tiempo que tardan los ocupantes en empezar a moverse

hacia las rutas de evacuacin.

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 signicativamente estos valores. La forma en que el ocupante elige la ruta de escape se considera un aspecto complejo del comportamiento humano. Segn [15], dos factores denen esta eleccin: Conocimiento del entorno en base a factores internos, por ejemplo, un mapa cognitivo de la geometra del edicio, Conocimiento del entorno en base a factores externos, es decir, la interaccin 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:

Lnea temporal del desarrollo de evacuacin de una emergencia

Un factor ms a tomar en cuenta es la velocidad de evacuacin en los diferentes lugares del edicio. ste depende de aptitudes fsicas propias de los ocupantes, la densidad de personas en una regin del edicio, y la interaccin social entre individuos. Por otro lado, los factores que ayudan a disminuir el tiempo de evacuacin son la sealizacin adecuada de las salidas, un sistema eciente de comunicacin y un entrenamiento apropiado del personal. Estos factores son decisivos ya que si el usuario recibe informacin incompleta el ocupante podra no percibir la amenaza y por ende ignorar las seales, buscar ms informacin o seguir con sus actividades, como se menciona en [15].

2.4.3. Aplicaciones con RFID en dispositivos mviles


Los dispositivos de lectura RFID pueden ser estacionarios o mviles. Esta ltima cualidad de movilidad permite una mayor gama de aplicaciones. RFID Mvil es una tecnologa emergente que usa el telfono mvil como un dispositivo de lectura RFID que integra la tecnologa wireless, las comunicaciones mviles y una infraestructura 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 aplicacin, es decir, la relacin entre el mdulo de lectura RFID y la aplicacin era uno-a-uno.

13

2.4 Estado del Arte


El aporte de la tecnologa RFID Mvil es la distribucin de dispositivos de lectura en un rea y la difusin de los datos capturados a una variedad de aplicaciones. Actualmente, la tecnologa RFID Mvil puede representar dos tipos de combinaciones: telfono inteligente equipado con etiqueta RFID (RFID-tag-attached mobile phone) o equipado con lector RFID (RFID-reader-equipped mobile phone). Claramente cada combinacin tiene campos de aplicacin diferentes. La primera apunta ms al pago de tarjetas, control de accesos, autenticacin de identidad, entre otras. La segunda, por otro lado, puede ser utilizada para proveer al usuario informacin detallada del objeto etiquetado accediendo a la red de datos inalmbrica como muestra la gura 2.6:

Figura 2.6:

Ejemplo de aplicacin RFID-reader-equipped mobile phone [17]

Los sistemas mviles RFID desarrollados hasta el momento tienen una arquitectura 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 tpica fue originalmente denida por la EPCGlobal [18].

Figura 2.7:

Modelo de comunicacin de datos RFID [16]

14

2.4 Estado del Arte


Los telfonos inteligentes actuales an no cuentan con la capacidad de lectura de etiquetas RFID. Si bien ya existen modelos que permiten leer etiquetas NFC, como el Samsung Nexus S , los grandes fabricantes de telfonos inteligentes (Apple, Samsung y recientemente Nokia) tienen en sus planes incluir un lector RFID. Tambin, empresas relacionadas con la fabricacin de adaptadores y aplicaciones para los telfonos inteligentes han desarrollado mdulos de lectura RFID adaptables. Por un lado, Wireless Dynamics

ha desarrollado para los telfonos inteligentes iPhone

el adaptador iCarte. Algunas de sus caractersticas tcnicas son:

Rango de escritura/lectura hasta 6.0 cm con la norma ISO 15693. Consume 90 mA en el modo RFID escritura/lectura. Diseado 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 telfonos inteligentes Android es la taiwanesa Microelectronics Technology Inc. . Este adaptador se denomina MINI ME RFID Reader y sus principales caractersticas tcnicas son:

Cumple con las normas: ISO 18000-6C / EPC Class 1 Gen2. Frecuencia de operacin: 902-928 MHz (US), 865-868 MHz (EU).

1 http://www.samsungnexuss.com/nexus-s-specs/ 2 www.wdi.ca 3 www.mti.com.tw


15

2.4 Estado del Arte


Consumo mximo 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 ocial de aplicaciones AppStore, algunas como iCarte Wallet y BCARDReader, utilizadas para negocios electrnicos. En cambio para el adaptador MINI ME se puede encontrar en el Google Play Market la aplicacin MTI RFID ME GUI, que permite congurar desde el telfono el adaptador.

2.4.4. Desarrollo de aplicaciones para situaciones de emergencia


El objetivo primordial que debe cumplir una aplicacin de un telfono mvil en una situacin de emergencia es evacuar por la ruta ms segura y ms corta en el menor tiempo posible [3]. Esta evacuacin se ha resuelto a travs de diversas formas de presentar las instrucciones de navegacin al usuario. La efectividad de una u otra instruccin de navegacin depende fuertemente de las caractersticas de la situacin de emergencia. Baus, Cheverst y Kray [5] muestran un estudio sobre las diferentes soluciones empleadas en guas mviles. Indican que la mayora de las soluciones existentes estn basadas en planos 2D pero igualmente otras soluciones alternativas valiosas son: Fotos del entorno aumentas con ayudas visuales de navegacin, 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 fotografas con realidad aumentada usan las habilidades espaciales naturales del usuario, es decir, le proveen a ste las mismas seales visuales, por ejemplo: obstrucciones o tamao de los objetos. Adems, de que los modelos 3D sirven para entrenar a los usuarios a navegar un espacio sin estar en el mismo hay que sealar 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 sera confuso y tampoco servira para entrenamiento. En este aspecto, un modelo 2D requiere un nivel mnimo de calidad y se presta a menos confusiones o desorientaciones del usuario.

2.4.4.1. Aplicacin desarrollada en la Universidad de Udine


Una de las aplicaciones ms desarrollada y ecaz en cunto a situaciones de emergencia es la desarrollada en la universidad de Udine (Italia) por Chittaro y Nadalutti [2]. Dicha propuesta consiste en implementar un prototipo que d instrucciones simples y efectivas para la evacuacin mediante grcos de realidad aumentada (modelo 3D del edicio) en el dispositivo mvil como se puede ver en la gura 2.10. El sistema usa lectores RFID en los celulares y varas etiquetas colocadas en lugares jos del edicio, el n es determinar la ubicacin de la persona quien posee el mvil para guiarlo a la salida de emergencia.

Figura 2.10:

Modelo de realidad aumentada del edicio [2]

Chittaro y Nadalutti [2] determinaron, una vez nalizado y testeado el proyecto, dos restricciones importantes para que la determinacin de la ubicacin sea precisa. La distancia entre cada etiqueta RFID no debe ser mayor a 2 metros, lo que directamente implica un gran nmero de etiquetas en todo el edicio.

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 aplicacin es que muestra un nico camino haca la salida de emergencia.

2.4.4.2. Aplicacin RescueMe


Otra solucin ecaz de evacuacin para telfonos mviles es la desarrollada por Junho Ahn y Richard Han de la Universidad de Colorado (EU) denominada RescueME [3]. Esta solucin, para ambientes internos, est enfocada en edicios o fbricas de gran tamao y con caminos complejos hacia las puertas de evacuacin, algunas imgenes de la aplicacin las muestra la gura 2.11. Su objetivo primordial es indicar la salida ptima al usuario, es decir, la salida menos concurrida y a la cual toma menos tiempo llegar. Todo el sistema de evacuacin de la aplicacin RescueME tiene como base cuatro componentes: Localizacin basada en imgenes (image-based location), Realidad aumentada (AR, Augmented Reality), Podometra personalizada (personalized pedometry), y Algoritmo de recomendacin. Estos componentes necesitan para su funcionamiento el servicio de correlacin de fotografas IQEngine, servidores en la nube (cloud servers) y los sensores del telfono mvil. Al no depender estos componentes de ninguna infraestructura adicional no es necesario que se instale cientos o miles de etiquetas RFID en el edicio, como s se requera en la aplicacin de la seccin 2.4.4.1. Parte del estudio para la validacin de la aplicacin RescueMe implic simular un escenario de emergencia segn distintas dispersiones de la gente en el edicio y segn distintas decisiones de cul camino tomar. Los tipos de dispersiones simuladas 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: Eleccin de una salida aleatoriamente, Eleccin de la salida ms cercana, y

18

2.4 Estado del Arte

Figura 2.11:

Aplicacin RescueMe en uso: mapa 3D y 2D [3]

Eleccin de la salida que toma el menor tiempo (mtodo RescueMe). Las simulaciones de la aplicacin con las variables especicadas arrojaron las siguientes conclusiones:

Cuando la gente est distribuida aleatoriamente el mtodo de la salida ms cercana y el mtodo RescueMe son ms efectivos y toman, en promedio, el mismo tiempo de evacuacin de toda la gente. Cuando la gente est en grupos numerosos el mtodo RescueMe evacua ms rpidamente la gente, que el mtodo de la salida ms cercana.

La segunda conclusin de las simulaciones muestra la importancia del algoritmo de recomendacin de la aplicacin. Este algoritmo puede cambiar la ruta de evacuacin indicada basndose en informacin de los dems usuarios, ms especcamente basndose en la velocidad con la que concurren a la salida.

2.4.4.3. Desarrollos de la Universidad de Karabuk


Otros trabajos en evacuacin para situaciones de emergencia se enfocan ms en la toma de decisiones de las personas cuando se encuentran en una situacin de peligro. En un estudio para un sistema de evacuacin para una circunstancia de desastre, liderado por la Universidad Karabuk (Turqua)[4], se indican ciertas consideraciones que se deben tomar en cuenta a la hora de disear un sistema como tal:

19

2.4 Estado del Arte

Figura 2.12: Simulacin en Software de la aplicacin RescueMe: casos de distribucin de personal [3]

En una situacin de emergencia, los visitantes usan la puerta de entrada para evacuar porque les es ms familiar. En una situacin de emergencia, los ocupantes regulares del edicio usan la puerta de emergencia para evacuar. Cuando una alarma suena los ocupantes usan un periodo crtico de tiempo solamente en decidirse evacuar el edicio. Los ocupantes tardan cuatro veces ms tiempo decidiendo evacuar luego de escuchar la alarma que evacuando. El 82 % de las razones por las que los ocupantes evacuan un edicio 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 inhalacin de humo. Un 25 % es por quemaduras y asxia. El tiempo de evacuacin depende de dos factores: preferencias de salida y problemas de visibilidad por el humo. La mayora de ocupantes se vuelven o detienen si el humo impide ver menos de 20 metros adelante en la ruta de evacuacin. Se puede concluir de los datos anteriores que los actuales sistemas de evacuacin no son lo sucientemente inteligentes para resolver los posibles incidentes. Es muy probable que un sistema actual de evacuacin dirija a la gente a salidas bloqueadas o a lugares donde hay una fuga de gas. Peor an, este tipo de sistemas de evacuacin se vuelven intiles cuando no hay visibilidad debido al humo o a cortes de energa. 20

2.4 Estado del Arte

Figura 2.13:

Sistema de evacuacin ptimo [4]

Segn Rakip [4] un sistema de evacuacin ptimo (OES, Optimum Evacuation System) necesita siete componentes importantes: 1. Sistema para posicionamiento interno. 2. Enlace de comunicacin. 3. Sistema GSM. 4. Modelo del edicio. 5. Informacin acerca de los ocupantes del edicio (edad, gnero, etc). 6. Informacin en tiempo real de los sensores (humo, temperatura, etc). 7. Sistema de evacuacin central (software y hardware) para calcular la ruta ptima y distribuirla a los ocupantes.

2.4.5. Situacin de aplicaciones en dispositivos mviles para localizacin en interiores


Las aplicaciones mviles para localizacin en interiores se desarrollan generalmente usando como medio de deteccin las redes Wi o Bluetooth disponibles, otros

21

2.4 Estado del Arte


sistemas incorporan adems los sensores de los smartphones, como son acelermetro y magnetmetro como en [21] que muestra un sistema de localizacin en interiores asistida por sensores. En cuanto a localizacin en interiores utilizando tecnologa RFID se han desarrollado algunos sistemas los que consideramos ms relevantes se citan a continuacin.

2.4.5.1. Aplicacin mvil para localizacin en interiores basada en sistemas de localizacin geogrca
Este trabajo [22] utiliza un servidor SIG (Sistema de Informacin Geogrca) que enva los planos de las construcciones e informacin interna asociada con los clientes. Para determinar la ubicacin precisa del usuario de utiliza telfonos equipados con tecnologa RFID. La demostracin del sistema se la hace en un campus con los usuarios viendo los mapas interactivos. Cada usuario puede cambiar los niveles de los edicios, encontrar ocinas y ver las rutas entre lugares seleccionados.

Figura 2.14:

PDA Display [22]

Cabe mencionar que la aplicacin no se ejecuta de manera nativa en el telfono sino que se hace accediendo al servidor SIG mediante el navegador propio del telfono. Las conclusiones a las que llegan luego de realizar el trabajo son que la localizacin en interiores tiene mucha utilidad en lugares extensos en los que la red Wi-Fi est presente en su totalidad, adems concluyen que el costo para acceder a la interfaz de su aplicacin desde el telfono es muy alto, debido al costo por cantidad de datos consumidos. 22

2.4 Estado del Arte 2.4.5.2. LANDMARC: Localizacin en interiores utilizando RFID Activas
En [23] se disea un prototipo que usa tecnologa RFID para ubicar objetos dentro de edicios. El proyecto se desarrolla en base a etiquetas de referencia para garantizar la precisin en la ubicacin. Basndose en un anlisis experimental, demuestran que las RFID activas son una manera viable en cuanto a costo-benecio para sistemas de localizacin 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 anlisis experimentales que se realiza evalan los efectos de la cercana de los usuarios, inuencia de los factores del ambiente, nmero de lectores, ubicacin 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 seal 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 ubicacin fsica de una etiqueta con la ubicacin 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 idntica ubicacin.

2.4.5.3. Sistema de rastreo mvil RFID


El departamento de ingenieros en computacin de la Universidad Americana de Sharjah [24], desarroll una aplicacin para el monitoreo de la ubicacin de nios 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 nio llevara una etiqueta RFID tipo pulsera. La comunicacin entre los lectores y el servidor web es va LAN. Y se utiliza software para el manejo de la informacin de la base de datos adems de una interfaz amigable para el usuario, como se ve en la gura 2.16. El sistema sera implementado en "Dubai Global Village", el cual es un centro de exhibiciones que atrae cada ao de 40000 a 50000 visitantes. En este centro los ociales de seguridad reciben cientos de denuncias de nios desaparecidos. Con el sistema de rastreo implementado la bsqueda de estos nios ser mucho ms rpida y sencilla.

24

3 MATERIALES Y MTODOS
3.1. Metodologa
La metodologa adoptada divide el proyecto de n de titulacin en 3 fases, para dar cumplimiento a los objetivos. Las fases denidas son: exploratoria, experimental y anlisis de resultados. La fase exploratoria consisti en una investigacin en proyectos de tesis, revistas y publicaciones cientcas, papers e informes tcnicos, disponibles en la red de Internet, sobre la tecnologa RFID, sus aplicaciones en proyectos comerciales y de investigacin, especialmente en proyectos relacionados a la evacuacin 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 evacuacin en bloques de desarrollo independientes. Pudiendo trabajar en varios mdulos a la vez, para su posterior integracin al sistema. Los bloques denidos son cinco: red de sensores, servidor Web, aplicacin mvil Android, sistema de localizacin 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 evacuacin. Finalmente, la fase de anlisis 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 edicio. Esto con el n de establecer las conclusiones y recomendaciones para el proyecto de n de titulacin.

25

3.1 Metodologa

Tabla 3.1:

Bloques de la fase experimental


Descripcin
Comprende el sistema que va desde los sensores hasta la generacin de tramas TCP/IP, de las mediciones de los sensores, para la conexin con el servidor. Recibe las tramas generadas por la red de sensores y

Bloques de la fase experimental


Red de sensores

Servidor Web

procesa la informacin para generar alertas. Genera la aplicacin WEB y el servicio Web para ser publicados en internet. Es la parte central del sistema, consume el servicio WEB

Aplicacin mvil Android

y utiliza el sistema de localizacin RFID. Presenta tambin las opciones para entrenamiento en situaciones de emergencia. Recoge la informacin de las etiquetas RFID, mediante

Sistema de localizacin RFID

el mdulo de lectura conectado al telfono para relacionarlas con la posicin de la persona. Es la parte de modelado del edicio a evacuar, ste

Montaje del sistema e infraestructura

detalla la ubicacin de los sensores y las etiquetas RFID, para poder realizar la simulacin del sistema.

Figura 3.1:

Fase experimental del sistema de evacuacin

26

3.2 Seleccin de materiales

3.2. Seleccin de materiales


3.2.1. Materiales para la red de sensores
De acuerdo con los bloques denidos en la metodologa, sta etapa corresponde a los sensores utilizados para detectar las situaciones de evacuacin, el microcontrolador para procesar la informacin y el mdulo para convertir las seales en tramas TCP/IP, que luego sern enviadas al servidor. Los sensores envan sus lecturas en el rango de milivoltios. stos datos son tomados por el microcontrolador para ser digitalizados y acondicionados en la escala de grados centgrados. Luego se les da el formato de envo junto con los datos de todos los sensores. Finalmente se enva la informacin por el puerto serial hacia el mdulo conversor ,Serial a Ethernet, para crear la trama TCP/IP. Los sensores a utilizar, para la simulacin, son los de precisin en grados centgrados LM35, ver gura 3.2, debido a que posee una respuesta lineal en voltaje, proporcional a la temperatura en grados centgrados. 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 analgicas, que ser en donde se conectarn los sensores. Para la generacin de la trama TCP/IP se utiliza el mdulo WIZnet S2E (Serialto-Ethernet), que viene acondicionado con un puerto serial DB9 como entrada y un puerto Ethernet a la salida. Para el funcionamiento del mdulo, es necesario asignarle una direccin IP y un puerto de comunicacin. 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 mdulo realiza el acondicionamiento de la seal de los sensores y enva la trama TCP/IP al servisor. Se

27

3.2 Seleccin de materiales


congur 8 entradas analgicas y 16 entradas digitales. La gura 3.3, muestra el mdulo de acondicionamiento de seales.

Figura 3.3:

Mdulo de acondicionamiento de seales 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 gestin de la misma, es decir, ms que una base de datos se necesita de un Sistema de Gestin de Base de Datos (DBMS, DataBase Management System). Existe un gran nmero de sistemas de gestin de base de datos: jerrquicas, de red, transaccionales, relacionales, multidimensionales, orientadas a objetos, documentales, deductivas y distribuidas. El sistema de gestin necesario para el sistema de evacuacin debe tener caractersticas bsicas como: licencia libre, de tipo relacional y gestin sencilla. Los sistemas DBMS que cumplen estas caractersticas 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, NetBeans

trabaja con

MySQL y PostgreSQL. Por otro lado, Eclipse permite crear y gestionar bases de datos via SQL y otros editores predenidos.

1 http://netbeans.org/features/ide/database.html

28

3.2 Seleccin de materiales


Se decidi usar el sistema de gestin de base de datos MySQL gracin con NetBeans es ms desarrollado que SQL en Eclipse.

ya que su inte-

Figura 3.4:

Sistema de Gestin de Base de Datos MySQL

3.2.2.2. Preparacin de la Base de Datos MySQL


La base de datos MYSQL para el prototipo de evacuacin no requiere ninguna preparacin especial. Solamente es necesario crear la base de datos con sus respectivas tablas y crear la conexin a la misma [25]. La conexin a la base de datos se realiza mediante un conector JDBC (Java DataBase Conectivity). En la pestaa de servicios de NetBeans se puede visualizar la base de datos creada y su respectiva conexin, como podemos ver en la gura 3.5.

3.2.2.3. Software para la Aplicacin Web


La aplicacin web diseada es una interfaz de usuario basada en web. Es comn disear, desarrollar e integrar este tipo de interfaces en JSF (Java Server Faces), un marco de aplicaciones web basado en Java. Adems, se suele usar JSF junto con Ajax (Asynchronous JavaScript and XML), una tecnologa que permite desarrollar interfaces con mejores presentaciones. Existen varias compaas y proyectos de diseo de aplicaciones web basados en JSF y Ajax, se puede destacar tres por ser RAD (Rapid Application Development), es decir, que siguen una metodologa de mnima planicacin para desarrollar prototipos en el menor tiempo posible. stos son: RichFaces, ICEfaces y PrimeFaces que presentan la misma facilidad de diseo e integracin y cuentan con todas las caractersticas para desarrollar el prototipo de aplicacin web. Se eligi Primefaces para desarrollar la interfaz de usuario de la aplicacin web.

1 http://www.mysql.com/

2 http://www.primefaces.org/showcase/ui/home.jsf

29

3.2 Seleccin de materiales

Figura 3.5:

Base de datos MySQL y conexin JDBC

Figura 3.6:

Primefaces: librera para la aplicacin web

3.2.2.4. Preparacin del software para la Aplicacin Web


Para disear la interfaz de la aplicacin web con JSF, especcamente con la librera Primefaces, se necesita crear un proyecto tipo `Web Application' en el IDE NetBeans y a ste aadirle la ltima librera de Primefaces. Para que la aplicacin web cuente con otras caractersticas como: un controlador para subir archivos (le Upload Controller) y un tema para mejorar la presentacin, se requiere aadir las siguientes extensiones, que muestra la gura 3.7:

3.2.2.5. Generacin del servicio web en Netbeans


La aplicacin Android/RFID necesita consumir un servicio web para poder consultar inalmbricamente desde la base de datos las alarmas de fuego y recomendaciones de evacuacin. Un servicio web es un sistema de software diseado para soportar 30

3.2 Seleccin de materiales

Figura 3.7:

Extensiones aadidas a la Aplicacin web

interoperabilidad entre mquinas sobre una red [26], de tal forma que distintas aplicaciones diseadas sobre lenguajes diferentes pueden utilizarlo e intercambiar datos. Esta interoperabilidad se consigue mediante varios protocolos y estndares. El estndar usado en nuestra aplicacin Android/RFID es el estndar abierto SOAP (Simple Object Access Protocol). SOAP realiza esta comunicacin mediante intercambio de mensajes con formato JSON (JavaScript Object Notation). Para que la aplicacin Android/RFID consuma el servicio web no se necesita ningn programa adicional. Es necesario congurar el servicio en Netbeans y la consulta del mismo en el telfono. En Netbeans se congura la generacin del servicio dentro de la aplicacin web. Para esto se le aade 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:

Generacin del servicio web

31

3.2 Seleccin de materiales

Figura 3.9:

Seleccin de la base de datos para generar el servicio web

3.2.3. Desarrollo de Aplicacin mvil Android


3.2.3.1. Software para desarrollo aplicaciones Android
Desde la aparicin del sistema operativo Android para telfonos mviles en el 2008 [27] hasta la actualidad existen un gran nmero de opciones de programacin de aplicaciones. Todas estas opciones se pueden dividir en dos grupos: lenguajes amigables y ambientes de desarrollo integrado (IDE, Integrated Development Environment). Los primeros, no requieren conocimientos de Java; son programas que han sido diseados para construir aplicaciones con lenguajes de programacin propio e incluso mediante bloques de programacin, como: Basic4Android, Mono, App Inventor y LiveCode. Los IDE's, por otro lado, integran ms herramientas de desarrollo, a continuacin se detalla los consideramos para el desarrollo de la aplicacin Android.

3.2.3.2. Entornos de desarrollo de aplicaciones Android


Los IDE's son los entornos que permiten programar aplicaciones Android aadiendo libreras API (Application Programming Interface) y herramientas de desarrollo. stas permiten crear, probar y depurar aplicaciones Android. Google a travs de su pgina de desarrolladores permite descargar todas estas libreras y herramientas contenidas en el Android SDK (Software Development Kit). El Android SDK est disponible para Windows, Mac y Linux, siendo los requerimientos de sistema los mnimos.

1 developer.android.com

32

3.2 Seleccin de materiales


Existen varios IDE's compatibles con el Android SDK y que ya han sido probados para desarrollar exitosamente aplicaciones Android. En la tabla 3.2 se detalla las caractersticas de los ms conocidos. De esta tabla se puede concluir que Netbeans, Eclipse e IntelliJIDEA son los entornos de desarrollo ms completos ya que se encuentran disponibles para varias plataformas, por otro lado ofrecen ms funcionalidades 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 ms, presentan limitaciones similares a JCreator: carecen de GUI builder o no soportan JavaScript.
Tabla 3.2:

IDE's para desarrollo de aplicaciones Android


PLATAFORMAS
Windows, Linux, Mac, Solaris Windows, Linux, Mac, Solaris Windows, Linux, Mac Windows

NetBeans Eclipse JDT IntelliJIDEA JCreator

IDE

LICENCIA
CDDL, GPL2 EPL ALv2, proprietario proprietario

GUI Builder JavaScript


Si Si Si No Si Si Si No

3.2.3.3. Seleccin del programa para desarrollo de aplicaciones Android


La aplicacin Android para el sistema de evacuacin se program en el lenguaje Java. La informacin sobre el desarrollo de aplicaciones es ms extensa y completa, debido a que Java es el lenguaje ocial elegido por Google. Elegido el lenguaje de programacin de las aplicaciones Android, queda seleccionar el IDE, pudiendo ser Netbeans , Eclipse

e IntelliJIDEA . Estos tres IDE's

cuentan con las mismas caractersticas y se encuentran al mismo nivel de desarrollo. Se decidi usar Eclipse Indigo, en su versin 3.7.2(gura 3.10), porque es el IDE recomendado en la pgina de desarrolladores de Android y porque incorpora el ADT (Android Developer Tools) para simplicar el desarrollo de estas aplicaciones.

Figura 3.10:

Eclipse Indigo: IDE seleccionado para desarrollo de la aplicacin Android

1 http://netbeans.org/

2 http://www.eclipse.org/indigo/ 3 http://www.jetbrains.com/idea/
33

3.2 Seleccin de materiales 3.2.3.4. Preparacin del IDE Eclipse


Para crear aplicaciones en Eclipse se necesita agregarle libreras API y herramientas de desarrollo. Como se mencion anteriormente, existe una versin de Eclipse que trae incorporado todo lo necesario para desarrollar aplicaciones Android. Todas las libreras que se encuentran condensadas en el paquete ADT , son: Eclipse ms 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 libreras: 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 libreras necesarias para aprovechar cada una de las caractersticas del dispositivo mvil Android, basta con importarlas en el programa principal, con el comando muestra la gura 3.12.

import

seguido por el nombre del paquete,como

1 http://developer.android.com/sdk/index.html
34

3.2 Seleccin de materiales

Figura 3.12:

Paquetes importados a la aplicacin Android/RFID

3.2.3.5. Consumo del servicio web desde el dispositivo mvil


En Eclipse es necesario indicar dentro de la aplicacin Android los paquetes que se deben importar y la direccin 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 aplicacin. Es decir, que el estado de las alertas se actualiza en este tiempo como mximo, esto se hace debido a que las actualizaciones de los sensores son cada 20 segundos. Para la implementacin del sistema en un edicio, se debera considerar siempre que el tiempo de consumo del servicio Web, sea menor al de actualizacin de los sensores.

35

3.2 Seleccin de materiales

Figura 3.14:

Cdigo para consumir el servicio web

3.2.3.6. Retrasos en aplicaciones Android


Las caractersticas de tiempo de respuesta son importantes en una situacin de emergencia. Android est diseado para evitar tiempos de respuesta muy grandes, mostrando un dilogo al usuario llamado dilogo ANR (Application Not Responding) como se ve en la gura 3.15.

Figura 3.15:

Mensaje Android ANR

Este dilogo permite elegir al usuario entre `Forzar el cierre de la aplicacin' o `Esperar'. Adicionalmente, en la pgina ocial de Android para desarrolladores se especica que el tiempo despus del cual un usuario percibe retraso o falta de continuidad de la aplicacin es 100 a 200 ms. En consecuencia, la aplicacin que se desarrolle no debera tener fases (procesos, salto entre procesos, salto entre ventanas) que duren ms de 200 ms.

3.2.3.7. Tiempos de retraso de la aplicacin de evacuacin Android/RFID


Tomando en cuenta los tiempos de retraso permitidos en una aplicacin Android se dene un conjunto de tiempos de retraso especcos de la aplicacin desarrollada:

Tiempo de puesta en marcha de la aplicacin. Tiempo de reconocimiento del mdulo de lectura RFID.

36

3.2 Seleccin de materiales


Tiempo de lectura de una tarjeta. Tiempo de actualizacin de la posicin en el plano segn la tarjeta. Tiempo de actualizacin del cono de orientacin. Tiempo de recepcin de alarmas de fuego y sugerencias de evacuacin. Tiempo de ejecucin de una llamada de emergencia.

3.2.3.8. Tiempo de puesta en marcha de la aplicacin


Este es el tiempo de ingreso a la aplicacin y es el mnimo posible ya que cuando se ingresa no existe ningn proceso de bsqueda de dispositivo o lectura de tarjeta RFID. La primera ventana, que se ve en la gura 3.16, permite al usuario elegir entre 'Evacuacin' o 'Entrenamiento'.

Figura 3.16:

Pantalla de inicio de la Aplicacin

3.2.3.9. Tiempo de reconocimiento del mdulo de lectura RFID


Una vez que se ingresa a `Evacuacin' la aplicacin busca el mdulo de lectura RFID y lo compara con un conjunto de posibles dispositivos de lectura RFID. Si la aplicacin reconoce el mdulo aparecer un mensaje en pantalla indicando `RFID conectado'.

37

3.2 Seleccin 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 aplicacin leer las etiquetas RFID correspondientes. Para la lectura de cada etiqueta es necesario acercar el telfono y automticamente el mdulo 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 podra verse afectado por interferencia de otras etiquetas (intento de mltiples lecturas) o por no acercar el mdulo la distancia y tiempo sucientes.

3.2.3.11. Tiempo de actualizacin de la posicin en el plano segn la etiqueta RFID


Una vez que se ha identicado el ID de la etiqueta y se lo relacione con la posicin en el edicio, se actualizar la ventana de la aplicacin mostrando la seccin del plano correspondiente (zoom y orientacin adecuados).

3.2.3.12. Tiempo de actualizacin del cono de orientacin


El cono de orientacin est constantemente actualizndose. ste indica la direccin del usuario con respecto a la seccin del plano en la que se encuentra. Esta actualizacin toma determinado tiempo que depende de las caractersticas del magnetmetro y cmo la aplicacin accede a estos datos. Este tiempo de respuesta podra verse afectado por caractersticas propias del magnetmetro o por interferencias electromagnticas externas.

3.2.3.13. Tiempo de recepcin de alarmas de fuego y sugerencias de evacuacin


La recepcin de las alarmas de fuego y sugerencias de evacuacin toma un tiempo de actualizacin congurable, 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 telfono se realizan cada 10 segundos. En un sistema de evacuacin real los tiempos de medicin de los sensores sera mucho mayores debido a la alta cantidad de datos que generaran, en el servidor. Considerando adems la infraestructura del edicio y el tiempo de propagacin del fuego, se podra congurar valores alrededor de 5 minutos.

38

3.2 Seleccin de materiales 3.2.3.14. Tiempo de ejecucin de una llamada de emergencia


Dentro de la seccin `Entrenamiento' se ubica la opcin `Nmeros de emergencia' en la que se ubican los principales contactos en caso de necesitar ayuda: Bomberos, Polica, Cruz Roja, entre otros. El tiempo que toma a la aplicacin hacer la llamada al contacto especicado, es el mismo que tomara, si la llamada se hiciera directamente, sin la aplicacin. Los casos en los que este tiempo de llamada aumentara son raros y dependeran exclusivamente de la red celular, puesto que en este proceso existe uso mnimo de recursos. Dentro de la aplicacin existen otros tiempos de respuesta que no son considerados urgentes por su cualidad de opciones de entrenamiento, como son, el plan de evacuacin y recomendaciones en una situacin de emergencia.

3.2.4. Prototipo de lectura de etiquetas RFID y dispositivo mvil


Con respecto al prototipo que utilizaremos en el proyecto para situaciones de emergencia se pueden denir algunos tipos de caractersticas, como: Caractersticas tcnicas (electrnicas y elctricas) del funcionamiento del mdulo de lectura RFID. Caractersticas de la conexin lgica entre el mdulo de lectura RFID y el dispositivo mvil con Android. Caractersticas de respuesta del prototipo en situaciones adversas. Caractersticas de tiempos de respuesta de la aplicacin. Caractersticas de diseo de la aplicacin. Las caractersticas del prototipo que se tomarn en cuenta y detallarn son las que podran afectar la respuesta y la toma de decisin de un usuario en caso de una situacin de emergencia, como por ejemplo, que la aplicacin o una parte de sta sea lenta, se cuelgue o se congele durante largos perodos, o tarde demasiado en entrar en un proceso.

3.2.4.1. Caractersticas Lgicas


La trama enviada por el mdulo de lectura RFID tiene el siguiente formato: la secuencia de lectura empieza cuando la lnea `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 Seleccin de materiales


ciclos gua, se enva el carcter de inicio `11010' (SS) y a continuacin los datos ledos (Data). Los datos ledos van seguidos por el LCR (Longitudinal Redundancy Check). Finalmente se envan un tren de pulsos de 10 bits y la lnea `Preset' de la tarjeta se desactiva. La gura 3.17, muestra la trama de datos. La duracin de los bits de datos es aproximadamente 330s. La duracin aproximada de los ciclos de reloj es 110s.

Figura 3.17:

Trama de envo de datos de la tarjeta RFID

3.2.4.2. Caractersticas Fsicas


La tabla 3.3 especica las caractersticas fsicas y lgicas del mdulo de lectura RFID. De estas caractersticas las dimensiones del mdulo son importantes para el montaje del prototipo.
Tabla 3.3:

Caractersticas del mdulo de lectura RFID


DETALLE
26 mm x 25 mm x 7mm 125kHz EM 4001 o compatibles Manchester 64 bits, mdulo 64 5Vdc 5mA nominal 4,6V a 5,4V

Dimensiones Frecuencia Formato de las tarjetas Decodicacin Requerimientos de potencia Voltaje de alimentacin

PARMETRO

3.2.5. Montaje del sistema de evacuacin


El montaje del prototipo consiste en adherir al dispositivo mvil Android el mdulo 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 mdulo 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. Caractersticas, 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_rd y db_registro, cada una con un objetivo especco. Ambas bases de datos tienen el mismo par de tablas denominadas: tb_sensores y tb_alertas.

40

3.2 Seleccin de materiales

Figura 3.18:

Montaje del prototipo: captura lateral

Base de datos db_rd: guarda las lecturas inmediatas de los sensores analgicos y digitales, Base de datos db_registro: carga los registros que se deseen consultar.

La base de datos db_rd es gestionada por una aplicacin en Java que realiza las siguientes funciones:

1. Se ejecuta en el servidor donde llegan los datos de los sensores a travs 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 ledas 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 aplicacin web se dise especcamente para que el personal de socorro en caso de una situacin de emergencia, como el Cuerpo de Bomberos, pueda informarse

41

3.2 Seleccin de materiales

Figura 3.19:

Respaldo de las lecturas de los sensores

sobre la situacin del edicio en peligro. La informacin disponible para el personal de socorro es toda la que el sistema ha adquirido y puede aportar:

Pgina de ingreso y autenticacin que la muestra la gura 3.20. Relacin de cada uno de los sensores con el edicio, piso y sector al cual pertenecen. Lectura en tiempo real de cada uno de los sensores en el edicio (ltimas 50 lecturas), ver gura 3.21. Grco Temperatura ( C) vs Tiempo (00h00) de todos los sensores (ltimas 50 lecturas), ver gura 3.22. Planos de todos los pisos del edicio con detalle de las zonas de peligro. Consulta de los registros de las lecturas de los sensores con grco Temp. vs Tiempo.

Figura 3.20:

Pgina de ingreso y autenticacin

42

3.2 Seleccin de materiales

Figura 3.21:

Lectura en tiempo real de los sensores

Figura 3.22:

Grco Temperatura vs Tiempo de los sensores

3.2.6. Modelado de la infraestructura


Para realizar las pruebas al sistema de evacuacin a travs de dispositivos mviles Android se dise y construy un modelo a escala del edicio a evacuar: segundo y tercer piso del edicio UGTI (UTPL). Esta maqueta aparte de contener los sensores analgicos y digitales, y la placa electrnica de la adquisicin 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 caractersticas 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 Seleccin de materiales

Figura 3.23:

Planos de los pisos del edicio con detalle de las zonas de peligro

Consta de dos pisos (como mnimo) para poder probar el sistema de evacuacin de un piso a otro. El modelo del edicio se puede ver en la gura 3.24. Las paredes de la maqueta son diseadas tomando en cuenta la distancia mxima de lectura del mdulo RFID. El material con el cual est diseada la maqueta no causa interferencias en la lectura de las etiquetas RFID.

3.2.6.1. Ubicacin 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 nmero de sensores. Se utiliza slo un sensor correspondiente al rea de las escaleras que conecta ambos pisos. Los sectores denidos se pueden ver en la gura 3.25 y 3.26.

3.2.6.2. Ubicacin 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 usaran en un escenario real sino a la conveniencia de su ubicacin para probar el sistema. Un calculo del nmero de sensores para un edicio se puede ver en la seccin 4.6. La disposicin de las etiquetas para el piso superior se muestra en la gura 3.27. 44

3.3 Pruebas y optimizacin del sistema de evacuacin

Figura 3.24: Tabla 3.4:

Maqueta para probar el sistema de evacuacin

Cantidad tarjetas, etiquetas RFID y sensores por piso


Piso superior Piso inferior
11 o 5 4 7 3

DETALLE
Tarjetas RFID Etiquetas RFID Sensores analgicos

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 optimizacin del sistema de evacuacin


Para el sistema de evacuacin los test se enfocaron al desempeo de la aplicacin y a desplegar testbed al sistema completo.

3.3.1. Prueba al desempeo de la aplicacin


El primer test trata de determinar cuan robusta es la aplicacin. Para esto se somete la aplicacin a distintas pruebas de desempeo. Sin embargo, no existe un programa de test y validacin para aplicaciones Android. Ante esta carencia de normalizacin para testear y validar una aplicacin en Android, naci la alianza AQuA 45

3.3 Pruebas y optimizacin del sistema de evacuacin

Figura 3.25:

Sensores piso superior de la maqueta

(Alianza para la Calidad de Aplicaciones). Esta alianza es un cuerpo industrial mvil fundado por AT&T, LG, Motorola, Nokia, Oracle, Orange, Samsung y Sony Mobile. La alianza tiene como objetivo publicar documentos gua multiplataforma para el desarrollo de aplicaciones mviles. Como resultado del trabajo de AQuA se han publicado, hasta la fecha, dos documentos sobre cmo se debe testear y validar el desempeo de una aplicacin Android. stos son: Unied 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 aplicacin ser el documentado en la UTI Testing Criteria versin 1.1 (Junio 2012) por ser el ms reciente. ste requiere como requisito que se resetee el dispositivo Android a un estado de fbrica y haber instalado solamente la aplicacin que se va a validar. De esta manera, los errores producidos slo sern atribuibles a la aplicacin en proceso de validacin y la experiencia del usuario testeada ser una solucin end-to-end. Adems, en este documento se indica que no todos los test deben ser aplicados. El tipo de test que se aplique depende del tipo de aplicacin que se desee validar.

46

3.3 Pruebas y optimizacin del sistema de evacuacin

Figura 3.26:

Sensores piso inferior de la maqueta

Existen tres categoras para denir las aplicaciones, stas son: simple, framework y compleja. Se denen a continuacin.

3.3.1.1. Aplicacin simple


Una aplicacin Android simple cumple con lo siguiente, segn[28]: No enva SMS ni MMS. No escribe datos a archivos de datos estndares, 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 informacin. Accede a informacin de localizacin. Lee archivos estndares de datos. Lee SMS y MMS. Accede a la pantalla, al sonido, a la cmara y al teclado.

47

3.3 Pruebas y optimizacin del sistema de evacuacin

Figura 3.27:

Ubicacin de tarjetas RFID en la parte posterior de la maquetas

Escribe sus propios datos, como fotografas, nuevos documentos. A este tipo de aplicacin se le debe aplicar los test indicados en la tabla 3.5.

3.3.1.2. Aplicacin Framework


En este tipo de aplicaciones el mismo marco de la aplicacin 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 aplicacin simple o compleja a la aplicacin principal. A las aplicaciones subsecuentes derivadas de la principal se debe aplicar un test ms especco como se detallar a continuacin la tabla 3.5.

3.3.1.3. Aplicacin Compleja


Cualquier aplicacin que no se clasica como Simple o Framework ser considerada Compleja y se le aplicar el test de criterio completo. Existe tambin una clasicacin para este tipo de test que describe el nivel de importancia del mismo. As, estos tests se clasican en Crticos (Critical) y de Advertencia (Warning) y se denen como: Test Crticos, aquellos test que deben ser pasados. Si la aplicacin falla el test implica que tiene una falla total y general.

48

3.3 Pruebas y optimizacin del sistema de evacuacin

Tabla 3.5:

Test para aplicaciones Simples y Framework


TEST
1.1 Instalacin OTA (over the air) 1.3 Largo tiempo de ejecucin 3.1 Envo y Recepcin de datos 3.4 Descarga de recursos 5.2 Recepcin de mensajes 5.3 Llamada entrante 6.1 Operacin de la tarjeta de memoria 7.1 Legibilidad 7.3 Repintado de Pantalla 7.5 Facilidad de uso de las teclas 7.8 Funcin de progreso

TIPO DE TEST
1 Instalacin y ejecucin 3 Conectividad 5 Mensajes y llamadas 6 Inuencia externa

Simp. Fram.

7 Interfaz de usuario

7.10 Manejo de formato de display 7.11 Distintos tamaos de pantalla 7.12 Manejo del formato de las entradas 7.14 Errores de Ortografa 7.15 Errores de texto tcnicos

8 Lenguaje 9 Rendimiento

8.1 Operacin correcta del lenguaje 8.3 Formatos soportados del lenguaje 9.1 Suspender/reanudar desde el men principal 9.2 Suspender/reanudar durante la ejecucin

10 Media 12 Funcionalidad 13 Teclas

10.1 Opcin mute de la aplicacin 10.2 Ayuda y acerca de 12.1 Comprobacin de la funcionalidad 13.1 Desplazamiento por los mens 13.3 Pausa 15.1 Estabilidad de la aplicacin

15 Estabilidad 16 Manejo datos

15.2 Comportamiento luego del cierre forzado 16.2 Eliminacin de datos

49

3.3 Pruebas y optimizacin del sistema de evacuacin


Test de Advertencia, hay cuatro tipos de niveles de advertencia: pasa, molesto, difcil e imposible. Se denen as:

Pasa: la aplicacin pasa el test, no hay inconvenientes. Molesto: un error mnimo ha ocurrido con la aplicacin, por ejemplo: algn error tipogrco. Difcil: un error ms serio ha ocurrido con la aplicacin, por ejemplo: varios errores tipogrcos que hacen la aplicacin difcil de usar. Imposible: un error serio ocurri con la aplicacin, por ejemplo: los errores hacen la aplicacin imposible de usar.

3.3.1.4. Clasicacin UTC de la aplicacin


Segn la descripcin que se ha hecho de los distintos tipos de aplicaciones se puede clasicar a la aplicacin como Compleja. No encaja en la descripcin 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 aplicacin Compleja se debe elegir tests especcos que se le pueden aplicar para validar cada uno de sus procesos. No se pueden aplicar todos los tests catalogados dentro de aplicacin Compleja ya que existen procesos que la aplicacin no usa, como por ejemplo: envo y recepcin de mensajes, seleccin manual del lenguaje, etc. En la tabla 3.6 se indica los test UTI que se evaluarn en la aplicacin 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 metodologa 3.1, en el siguiente orden:

1. Evaluacin del funcionamiento de la red de sensores 2. Evaluacin al servidor Web, junto con la red de sensores para la generacin alertas. 3. Test a la aplicacin mvil Android. 4. Evaluacin al sistema de localizacin RFID. 5. Evaluacin al sistema de evacuacin completo montado en la maqueta.

A continuacin, se detalla los procedimientos a seguir para la evaluacin de cada bloque dentro del sistema de evacuacin.

50

3.3 Pruebas y optimizacin del sistema de evacuacin


Tabla 3.6:

Test aplicables a la aplicacin Android/RFID


Descripcin
Comprueba la correcta instalacin de la aplicacin Comprueba si la aplicacin notica al usuario cuando tarda demasiado en iniciar Asegura que el dispositivo puede recibir llamadas cuando la aplicacin est en uso Asegura que la aplicacin trabaja correctamente removiendo e insertando la tarjeta Asegura que el contenido es legible Asegura que el tiempo para la lectura del contenido es adecuado Asegura que haya sobreposicin de objetos Asegura la consistencia de la interfaz de usuario Asegura que los botones y otros mtodos de ingreso son fciles de usar Asegura que la velocidad de la aplicacin es aceptable para su propsito Asegura que los mensajes de error son entendibles y explican el problema Asegura una indicacin visual del progreso en la ejecucin en una funcin La respuesta de la aplicacin al movimiento o al cambio de direccin no debe perjudicar el uso de la aplicacin

Test
1.1 Instalacin OTA (over the air) 1.2 Largo tiempo de ejecucin 5.3 Llamada entrante 6.1 Operacin de la tarjeta de memoria 7.1 Legibilidad 7.2 Tiempo de lectura 7.3 Repintado de Pantalla 7.4 Consistencia 7.5 Facilidad de uso de las teclas 7.6 Velocidad de la aplicacin 7.7 Mensajes de error 7.8 Funcin de progreso 7.13 Respuesta de los sensores 9.1 Suspender/reanudar

Asegura que la aplicacin se suspende correctamente en el men principal Asegura que la aplicacin se suspende correctamente durante la ejecucin Asegura que la aplicacin se puede silenciar La aplicacin debe tener tems de `Ayuda' y `Acerca de'

desde el men principal 9.2 Suspender/reanudar durante la ejecucin 10.1 Opcin mute 11.1 Ayuda y Acerca de 12.1 Comprobacin de la

Comprueba la funcionalidad general de la aplicacin

funcionalidad

3.3.2.1. Procedimiento para la evaluacin a la red de sensores


Los sensores han sido colocados de acuerdo a la distribucin descrita en la seccin 3.2.6.1, y estarn en funcionamiento desde el instante en que se energiza el sistema de evacuacin. Para evaluar el sistema de evacuacin hasta este bloque, se utiliza una herramienta que permita recibir las tramas enviadas por un puerto TCP; hemos elegido el software Hercules 3.07 , 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.

1 http://www.hercules-390.org/

51

3.3 Pruebas y optimizacin del sistema de evacuacin


2. Vericar que el sistema no presente retardos en el envo 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 evaluacin de Servidor Web


La evaluacin a este bloque comprende, recepcin de las tramas por TCP/IP, procesamiento de los datos, generacin alertas, respaldo de informacin y presentacin en aplicacin Web y servicio Web.

Corroborar que las tramas enviadas desde el bloque anterior, concuerdan con los recibidos por la aplicacin Java en el servidor. Vericar que las alertas se generen correctamente. Comprobar el funcionamiento de la aplicacin Web de manera continua. Comprobar que las tramas generadas en notacin JSON, por el servicio Web, sean coherentes con las alertas generadas en el servidor. Vericar que los datos respaldados sean correctos, de modo que se puedan acceder a ellos desde el servidor.

3.3.2.3. Procedimientos para evaluacin de la Aplicacin Android


Esta evaluacin corresponde al software que estar en funcionamiento en el telfono. Los procedimientos a seguir son:

1. Aplicar los test UTI, mencionados en la tabla 3.6. 2. Evaluar los mdulos asociados con la aplicacin para el sistema de evacuacin, estos son: Consumo de servicio Web. Lectura de etiquetas RFID. Mdulo grco para la navegacin, incluye, actualizacin de rutas, planos, zoom, orientacin y alertas. Mensajes de evacuacin 3. Evaluar las opciones para el sistema de entrenamiento en la aplicacin Android.

52

3.3 Pruebas y optimizacin del sistema de evacuacin 3.3.2.4. Procedimiento para evaluacin del sistema de localizacin RFID
El sistema de localizacin RFID relaciona las etiquetas con el lugar en el que se encuentra el usuario. En una circunstancia de evacuacin es clave la respuesta que el sistema d al usuario, por esta razn se evaluar el tiempo de respuesta de lectura de una tarjeta RFID, y las interferencias que podra tener esta comunicacin en un edicio. El procedimiento a seguir para la evaluacin de esta parte del sistema de evacuacin es:

1. Evaluar la conexin entre el mdulo RFID y el telfono y denir el tiempo de reconocimiento. 2. Realizar lecturas de etiquetas del sistema de evacuacin. Con el n de establecer distancia mxima y tiempo de lectura, adems el efecto de la cantidad de tarjetas ledas y considerar posibles interrupciones que pueden presentarse en el sistema de evacuacin.

3.3.2.5. Anlisis al Sistema de Evacuacin RFID


Una vez que se ha vericado 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 evacuacin. Las pruebas que se van a realizar son:

Medir los tiempos mximos de actualizacin de las alarmas en el telfono, respecto a las variaciones de temperatura. Evaluar la respuesta de las etiquetas RFID, respecto al lugar en el que se mueva el telfono. Analizar la correspondencia entre la zona que cubren los sensores y las alarmas mostradas en el telfono. Realizar pruebas activando varias alarmas a la vez. Evaluar las alertas generadas y la actualizacin de rutas en el telfono, al activarse alarmas entre los dos pisos.

53

4 ANLISIS DE RESULTADOS
4.1. Red de sensores
Realizadas las pruebas a la red de sensores para el sistema de evacuacin, se obtuvieron los siguientes resultados:

1. El formato de la trama recibida en el servidor, es el mismo que se enva 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 centgrados, para las diferentes zonas del modelo a escala del edicio, de acuerdo con los sectores denidos en la seccin 3.2.6.1.

Figura 4.1:

Formato de datos enviados desde el microcontrolador

2. El retardo en el tiempo de actualizacin del valor ledo por el sensor, est en el orden de los milisegundos, por tanto, no afecta de manera signicativa el tiempo de emisin de una alerta. 3. El microcontrolador realiza las lecturas a los sensores cada 20 segundos, adicionalmente, tarda 2 segundos en envar los datos hasta el servidor. Por tanto, el tiempo mximo de espera por la actualizacin de un valor de temperatura, es 22 segundos.

54

4.2 Servidor Web


En esta parte del sistema de evacuacin se tendra un retraso mximo de 22 segundos, cabe destacar que este tiempo se lo utiliza como prueba para el sistema montado en la maqueta. En un sistema de evacuacin montado en un edicio, el tiempo de actualizacin, debe dimensionarse adecuadamente, con el n de no tener una cantidad elevada de lecturas, que luego puedan saturar la memoria de almacenamiento del servidor.

4.2. Servidor Web


Los resultados obtenidos de las pruebas realizadas al servidor, son los siguientes: La aplicacin Java tarda 2 segundos en recibir la trama completa, esto se congur en el microcontrolador. Las alertas generadas en el servidor concuerdan con las lecturas de temperatura de los sensores y el lmite establecido para activar una alerta. El valor

congurado para la activacin de una alarma es 23 C para la simulacin del


sistema de evacuacin. Los datos obtenidos de la generacin de una alarma se muestran en la gura 4.2. En sta se puede vericar que cuando la temperatura supera el valor mximo, se genera la alarma en el servidor y se actualiza la trama en notacin JSON. Las etiquetas S1 hasta S8, identican los sectores que estn siendo monitoreados y los valores `11' y `00', determinan si la alarma se ha activado o no, respectivamente.

Figura 4.2:

Trama en notacin 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 Aplicacin Android


Tabla 4.1:

Resultado de tests UTI a la aplicacin Android RFID


Descripcin
Comprueba la correcta instalacin de la aplicacin Comprueba si la aplicacin notica al usuario cuando tarda demasiado en iniciar Asegura que el dispositivo puede recibir llamadas cuando la aplicacin est en uso Asegura que la aplicacin trabaja correctamente removiendo e insertando la tarjeta Asegura que el contenido es legible Asegura que el tiempo para la lectura del contenido es adecuado Asegura que haya sobreposicin de objetos Asegura la consistencia de la interfaz de usuario Asegura que los botones y otros mtodos de ingreso son fciles de usar Asegura que la velocidad de la aplicacin es aceptable para su propsito Asegura que los mensajes de error son entendibles y explican el problema Asegura una indicacin visual del progreso en la ejecucin en una funcin La respuesta de la aplicacin al movimiento o al cambio de direccin no debe perjudicar el uso de la aplicacin

Test
1.1 Instalacin OTA (over the air) 1.2 Largo tiempo de ejecucin 5.3 Llamada entrante 6.1 Operacin de la tarjeta de memoria 7.1 Legibilidad 7.2 Tiempo de lectura 7.3 Repintado de Pantalla 7.4 Consistencia 7.5 Facilidad de uso de las teclas 7.6 Velocidad de la aplicacin 7.7 Mensajes de error 7.8 Funcin de progreso 7.13 Respuesta de los sensores 9.1 Suspender/reanudar

Resultado

Asegura que la aplicacin se suspende correctamente en el men principal Asegura que la aplicacin se suspende correctamente durante la ejecucin Asegura que la aplicacin se puede silenciar La aplicacin debe tener tems de `Ayuda' y `Acerca de'

desde el men principal 9.2 Suspender/reanudar durante la ejecucin 10.1 Opcin mute 11.1 Ayuda y Acerca de 12.1 Comprobacin de la

Comprueba la funcionalidad general de la aplicacin

funcionalidad

4.3. Aplicacin Android


De la tabla 4.1, se puede ver que la aplicacin cumple con la mayora de las pruebas recomendadas por la UTI, sto garantiza que la aplicacin no presenta errores ni mensajes que sumen retrasos en la obtencin de datos y actualizacin de rutas.

4.4. Evaluacin al sistema de localizacin RFID


Los resultados obtenidos de la evaluacin al sistema RFID del sistema de evacuacin simulado en la maqueta, son:

Al conectar y desconectar el mdulo varias veces, el telfono no presenta erro-

56

4.5 Anlisis al sistema de evacuacin


res. El tiempo de reconocimiento del mdulo de lectura est al rededor de 2 segundos, slo cuando se conecta por primera y no es necesario que la aplicacin del sistema de evacuacin este funcionando. El lector RFID est congurado para presentar el valor de la etiqueta, slo 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 mxima 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 conexin exitosa entre el telfono y el mdulo, se debe a que es directa por el puerto USB, por tanto, slo existir un dispositivo conectado a la vez. Las posibles causas de una desconexin lgica del mdulo seran debido a defectos en el cable o en los conectores.

4.5. Anlisis al sistema de evacuacin


4.5.1. Tiempo mximo de actualizacin de las alarmas
Del anlisis de los tiempos de actualizacin y los posibles retrasos hechos en las secciones anteriores, se puede calcular el tiempo mximo que se debera esperar por la actualizacin de una alarma, dicho de otra forma, es el tiempo que tardara el usuario en ver la alerta en su telfono desde el instante en que la temperatura super el valor mximo. El tiempo mximo puede calcularse cmo:

T1 = (Tmicro + Tweb + Tjson + Trf id )


Donde:

Tmicro Tweb Tjson Trf id

: tiempo total de actualizacin de las alertas en el telfono.

: tiempo mximo que tarda el micro en realizar las lecturas del valor de los

sensores. : tiempo mximo de consumo de servicio web desde el telfono. : tiempo de reconocimiento del mdulo de lectura RFID.

57

4.5 Anlisis al sistema de evacuacin


La variable

Trf id

debe considerarse en caso de que se conecte el mdulo en el

momento de iniciar la aplicacin, caso contrario es igual a 0. Los valores mximos para las variables son: Entonces el tiempo mximo sera:

Tmicro = 20s., Tweb = 2s., Tjson = 10s.

T1 = 20 + 2 + 10 + 2 = 34s.
Esta frmula sirve de igual manera para el sistema de evacuacin montado en un edicio. Se debe considerar que el tiempo de actualizacin de cada lectura de los sensores, no sea muy corto, porque se generara muchos datos que pueden saturar la memoria del servidor, ni tampoco sea tan alto que haga que las alertas lleguen demasiado tarde. Segn la revista online

Means of escape 1 ,

la clasicacin para el

edicio UGTI de la UTPL, es tipo A y el tiempo de evacuacin mnimo recomendado para stas construcciones es 3 minutos, ste valor aumenta de acuerdo al nmero de personal y salidas disponibles. Un valor razonable para la actualizacin de la temperatura en el sistema es 1 minuto.

4.5.2. Etiquetas RFID en la localizacin


La distancia mxima de lectura del mdulo RFID es de 6 cm. al mover el telfono por la maqueta, las lecturas corresponden al sector que muestra el telfono. Se puede ver en la gura 4.3 que la posicin del telfono concuerda con la imagen que presenta en la pantalla.

Figura 4.3:

Lectura de etiquetas RFID para localizacin

1 http://www.means-of-escape.com/articles/68/calculating-an-eective-means-of-escape/

58

4.5 Anlisis al sistema de evacuacin

4.5.3. Alarmas mostradas en el telfono


Para examinar la coherencia entre las imgenes mostradas en el telfono 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 imgenes del servidor y las obtenidas en el telfono.

Figura 4.4:

Alerta generada en el servidor

Figura 4.5:

Alerta vista desde la aplicacin Android

4.5.3.1. Resultados al activar alertas simultneamente


Al detectar cada alerta, el mensaje de evacuacin, de la parte inferior de la aplicacin cambia mostrando la salida disponible para evacuar. Con la activacin de varias alarmas la aplicacin actualiza la ruta de emergencia y el mensaje de evacuacin presenta las salidas disponibles en ese momento. 59

4.5 Anlisis al sistema de evacuacin


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, adems el mensaje de evacuacin en la parte inferior y la lnea que indica la ruta se dirige nicamente hacia las salidas de emergencia.

Figura 4.6:

Aplicacin mvil, situacin de dos alertas activadas

4.5.3.2. Comportamiento del sistema de evacuacin al activarse todas las alarmas


Con la activacin de todas las alarmas de un piso, lo que implica que todas las salidas de evacuacin estn bloqueadas, el sistema recomienda al usuario ubicarse en un sector libre de amenazas y donde se facilite su rescate. La ruta de evacuacin 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 evacuacin y el mensaje dirigen al usuario hasta all.

4.5.4. Comportamiento del sistema de evacuacin con alarmas en diferentes pisos del edicio
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 evacuacin, se actualizan con alarmas generadas en un piso diferente. El objetivo de

60

4.6 Seleccin de tecnologas para el sistema de evacuacin en un edicio

Figura 4.7:

Captura de pantalla de la aplicacin, todas las alertas activadas

estas pruebas es garantizar una ruta de evacuacin segura, de acuerdo a la situacin en todo el edicio. 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 evacuacin enva las noticaciones del piso donde se detecte una alerta. Como se puede ver en la gura 4.8, el mensaje de evacuacin indica que se ha activado una alerta en el piso inferior a pesar de encontrarse en un piso distinto. El sistema tambin actualiza el mensaje de evacuacin. 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 evacuacin recomienda usar nicamente la salida de emergencia.

4.6. Seleccin de tecnologas para el sistema de evacuacin en un edicio


Las pruebas realizadas permiten constatar la funcionalidad eciente del sistema de evacuacin, sin embargo no proporcionan el nmero exacto de etiquetas RFID y sensores. En esta seccin, determinamos las modicaciones en tecnologa utilizada para el sistema de evacuacin puesto en funcionamiento en un edicio, tomando como base los bloques, de la fase experimental, especicados en la metodologa. Presentamos las caractersticas y costo de dichas tecnologas, sin tomar en cuenta el nmero total de elementos, puesto que eso se podra realizar slo en el momento

61

4.6 Seleccin de tecnologas para el sistema de evacuacin en un edicio

Figura 4.8:

Aplicacin mvil, alerta en el piso inferior

de implementar y tomando en cuenta las caractersticas fsicas de la infraestructura y el plan de evacuacin del edicio. En la red de sensores del sistema de evacuacin, consideramos que en un edicio se utiliza mayor variedad de sensores para alertar en situaciones de emergencia, sin embargo sus interfaces de salida son de tipo digital o analgico, por lo que se utilizara el mismo mdulo de acondicionamiento de seales. Los sensores recomendados se detallan a continuacin:

Botones de pnico y emergencia: son los ms comunes en sistemas de


evacuacin y son de accin manual, su interfaz de salida es digital. Existen algunos como, botn de emergencia SS075Q ; normalmente abierto y de montaje supercial, ver gura4.10. El botn de pnico YA01

funciona como interrup-

tor de emergencia o llave de emergencia es de montaje en pared o instalacin de montaje oculto.

Sensores de humo: existen en el mercado varios que incorporan detectores


de humo y termostatos con salidas de voltaje analgico o digital. El detector multisensor XP95 analgico , incorpora un sensor de humo ptico y un sensor de temperatura de termostato cuyas salidas se combinan para dar lugar al

1 http://www.seco-larm.com/DoubleSp.htm 3 http://www.isolse.com.ar/

2 http://www.hkvstar.com/es/item/panic-button-ya-01.html

62

4.6 Seleccin de tecnologas para el sistema de evacuacin en un edicio

Figura 4.9:

Aplicacin mvil, alerta en escaleras del piso inferior

Figura 4.10:

Botn de emergencia SS075Q de la empresa

SECOALARM

valor analgico nal. Los Sensores digitales de humo, usan un LED interno y un fotodiodo en ngulo obtuso. Cuando el humo se introduce en la cmara, el pulso de luz del LED ser dispersado y registrado por el fotodiodo. El voltaje es analizado y un valor analgico es convertido a una seal digital que se transmite al modulo de acondicionamiento de seal. Ver gura 4.13.

Detectores de fuego: 1 detectan tanto, la radiacin ultravioleta, como la


infrarroja emitidas por el fuego. La gura 4.14, muestra un sensor de fuego de la empresa ISOLSE.

El servidor Web conservara las mismas funciones que en el sistema de evacuacin montado en un modelo a escala. La aplicacin mvil Android, debe programarse teniendo en cuenta el nmero de pisos y los planos de evacuacin del edicio.

1 http://deteccion-alarma-contra-incendio.isolse.com.ar/contra-incendios-i.asp

63

4.6 Seleccin de tecnologas para el sistema de evacuacin en un edicio

Figura 4.11:

Botn de pnico YA-01 de la empresa VSTAR

Figura 4.12:

Sensor de humo con salidas analgicas de la empresa ISOLSE

Para el sistema de localizacin RFID, debe considerarse la distancia mxima a la que se encontrara el usuario, el rango de lectura del mdulo y la distancia y cantidad de etiquetas RFID. Los dispositivos RFID que proponemos para el sistema de evacuacin montado en el edicio son:

Etiqueta pasiva RFID de largo alcance CFTU9101: 1 Tiene un rango de


lectura de 10 m. y de escritura de 3m., cumple el estndar ISO18000-6C(EPCGen2) 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 transmisin es de 200 m.,


usa tecnologa TDMA y CDMA, y trabaja en la frecuencia de 915MHz. Su precio unitario est alrededor de $3,00 USD.

html?s=p 2 http://www.alibaba.com/product-gs/272603071/RFID_card_rfid_active_tag_active. html

1 http://www.alibaba.com/product-gs/694545906/long_range_passive_rfid_tag_with.

64

4.6 Seleccin de tecnologas para el sistema de evacuacin en un edicio

Figura 4.13:

Sensor de humo con salidas digitales de la empresa

ISOLSE

Figura 4.14:

Sensor detector de fuego

Mdulo de lectura/escritura RFID de largo alcance GAO216010: Tiene un rango de cobertura de 15 m., cumple con estndares 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 evacuacin del edicio y disponibilidad fsica de la infraestructura, para determinar el tipo y cantidad total de dispositivos que se usara.

65

4.6 Seleccin de tecnologas para el sistema de evacuacin en un edicio

Figura 4.15:

Etiqueta pasiva RFID de largo alcance CF-TU9101

Figura 4.16:

Etiqueta RFID activa modelo YL-702

Figura 4.17:

Mdulo de lectura/escritura RFID de largo alcance

66

5 CONCLUSIONES Y TRABAJO FUTURO


Finalizada la investigacin y cumplidos los objetivos propuestos en el presente proyecto de n de titulacin, exponemos las siguientes conclusiones y recomendaciones.

5.1. Conclusiones
La metodologa adoptada para la fase experimental del sistema de evacuacin, permiti desarrollar y probar el sistema por bloques, facilitando la deteccin de errores y su correccin. El tiempo de actualizacin de las lecturas de los sensores, inuye de manera directa al tiempo total de evacuacin. Para las pruebas se utiliza un valor mximo de espera de una alerta de 34 segundos, en cambio si se implementa el sistema en un edicio se congurara un tiempo de 1 minuto, tomando en cuenta la excesiva cantidad de datos que generaran al funcionar el sistema de manera contina y la generacin oportuna de las alertas. En el servidor Web se desprecian los valores de tiempo de procesamiento de datos, la generacin de los servicios Web y la publicacin de datos en Internet. Por lo que, se podra decir que las rutas de evacuacin, en la aplicacin Android, se actualizan de manera inmediata. Realizados los test de funcionalidad a la aplicacin Android, se la clasica de nivel complejo y cumple con los items para esta clasicacin; garantizando que no presentar errores de ejecucin, ni mensajes de error que incrementen los retrasos. 67

5.1 Conclusiones
El requisito de mayor importancia en una aplicacin mvil de localizacin, es la apariencia grca que le muestra al usuario. Algunas usan una interfaz de realidad aumentada del edicio o modelado 3D, sin embargo, stas opciones tienen que ser lo sucientemente detalladas y claras para que puedan ser comprendidas. Una interfaz 2D, requiere pocos detalles y es mucho ms fcil que el usuario entienda su ubicacin, debido a que en interfaces 3D, no se puede manejar las vistas de los planos completos. La tecnologa RFID brinda una gran ventaja al momento de implementar sistemas de localizacin, puesto que los recursos de infraestructura son mnimos, comparados con sistemas de localizacin para interiores, como WiFi o Bluetooth. Adems el costo es mucho menor. El inconveniente es que todos los telfonos deberan contar con un lector de etiquetas NFC o RFID, que es la tendencia del desarrollo de telfonos inteligentes. En el sistema de localizacin RFID, corresponde la ubicacin de las etiquetas con la posicin mostrada en la aplicacin Android. Para lograrlo se debe considerar el nmero de etiquetas por cada sector y la distancia entre s y hasta el usuario. Del anlisis realizado determinamos que las etiquetas deben colocarse una cada 2 metros como mximo. Garantizando la actualizacin de la posicin del usuario de manera inmediata. El sistema de evacuacin responde correctamente a alarmas activadas simultneamente, incluso si fueran provenientes de pisos diferentes en el edicio. Se implement y prob, en un modelo a escala, un sistema de evacuacin que integra diferentes tecnologas, para mostrar la ruta de evacuacin desde la ubicacin del usuario, en un telfono inteligente. La localizacin se obtiene de etiquetas RFID ledas con un mdulo incorporado al telfono. La actualizacin de rutas de evacuacin es posible con la informacin proporcionada por la red de sensores. Las pruebas del sistema de evacuacin en un modelo a escala sirven para analizar la funcionalidad del sistema, pero no permite armar un presupuesto exacto del montaje para un edicio. Para ello, debe considerarse tambin parmetros externos al sistema, como pueden ser la relevancia de algunos departamentos en el edicio, y las facilidades fsicas para la ubicacin de sensores.

68

5.2 Recomendaciones

5.2. Recomendaciones
Para implementar el sistema de evacuacin en edicios se debe modicar el mdulo de localizacin RFID, usando tecnologa de mayor alcance o con etiquetas 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 localizacin por RFID, elegir el tipo de tecnologa de acuerdo al espacio en el que se va a aplicar, y tomando en cuenta el nmero de etiquetas que puede leer el mdulo a la vez. Para que las pruebas al sistema de evacuacin no lleven demasiado tiempo, se recomienda programar tiempos de lectura y actualizacin, de pocos segundos. El sistema permite variar el nmero de datos recibidos en el servidor con relacin a los que se usara en un sistema para un edicio. Sin embargo, para un sistema real los tiempos deben estar entre valores que permitan la recepcin oportuna de las alerta y valores que eviten saturar la memoria del servidor, por exceso de datos. Se recomienda utilizar una versin completa de los software de programacin, tanto Eclipse como Netbeans, para evitar posibles errores por la ausencia de libreras. La generacin de un servicio WEB en notacin JSON hace que la recepcin y procesamiento de las tramas en el dispositivo mvil sean mas sencillas, puesto que la informacin se recibe como texto plano. Para ubicar los sensores y etiquetas RFID en la maqueta, es necesario conocer la infraestructura del edicio. Dimensionar el nmero de sensores y etiquetas RFID tomando en cuenta los lugares relevantes, como pueden ser, pasillos de mayor auencia, salas de servidores y ocinas administrativas; para garantizar la eciencia del sistema. Como el mdulo de lectura RFID no est registrado por el fabricante del telfono es necesario, en el archivo de los permisos de los puertos del telfono de desarrollo, asignar permisos de lectura y escritura al puerto USB. Las rutas de evacuacin se eligieron en base a la sealtica del edicio, debido a que no se cuenta con un plan de evacuacin.

69

5.2 Recomendaciones
Para las situaciones en las que la alarma se origine en las posibles salidas de emergencia, planteamos como solucin dirigir al usuario a un punto despejado cuya ventana sea de fcil acceso para los organismos de socorro.

70

5.3 Trabajos futuros

5.3. Trabajos futuros


Orientar la aplicacin a personas con capacidades especiales. Por ejemplo; incluir al sistema mensajes de evacuacin tomando en cuenta el tipo de discapacidad del usuario, incorporar alertas sonoras a la aplicacin para ofrecer una ayuda ms completa e integrar el mdulo de conversin de texto a voz, de Android, para que la ruta de evacuacin pueda escucharse. Incluir a la aplicacin la posibilidad de ver la infraestructura en grcos de realidad aumentada, para facilitar la ubicacin al usuario. Adems, crear mapas completos del edicio en 3D para facilitar la navegacin, aunque deberan tener un nivel alto de detalle. Aumentar las funciones de la aplicacin adicionando la informacin de los sensores propios de los Smartphones, como son, acelermetros y magnetmetros, complementando al sistema RFID para que la ubicacin dentro del edicio sea ms precisa. Las rutas y lugares de evacuacin, en futuros desarrollos, deben considerarse en base al plan de evacuacin del edicio. En el telfono podra verse la sealtica completa del edicio y los planos a utilizarse seran los mismos del plan de evacuacin. El sistema de evacuacin podra permitir hacer minera de datos y estudios estadsticos, para implementar inteligencia articial en la actualizacin de las rutas. Dichas rutas tomaran en cuenta la informacin del personal mediante RFID y de los sensores en el edicio. Los datos que se obtendran, por ejemplo, son de sitios de mayor aglomeracin, horas en las que la auencia de personas es mayor, determinar lugares propensos a incendios, sectores con poca movilizacin de personal, etc. Se podra crear una red que comunique todos los sistemas de evacuacin en diferentes edicios, de manera que el cuerpo de bomberos y grupos de rescate tengan acceso a la informacin de estos sistemas, con el n de detectar las alertas de emergencia de manera oportuna en dispositivos mviles o por medio de la aplicacin Web.

71

BIBLIOGRAFA
[1]  Start Developing iOS Apps Today. sed: 29/11/2012. [2] A. Cataln,

https://developer.apple.com/.

Acces-

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 rd 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

http://www.icarte.ca/docs/ SW10-0058-DSiCarte420NFC/RFID&PaymentAdaptorforiPhone4S.
Dynamics,

[6] Microelectronics

http://www.rfidconnect.com/ ProductDetails.aspx?id=7b1a0be9-9cdb-494e-b113-21772efbc5c9,
Technology Inc,

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.
[8] J. Ahn and R. Han,

Dept. of Math and Computer Science, Udine, Italia.

RescueMe: An Indoor Mobile Augmented-Reality Evacuation 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, Turqua, 2012. A MOBILE INDOOR LOCATION BASED GIS APPLICATION. LANDMARC: Indoor Location Sensing Using Active

[10] J. Candy,

British Columbia Institute of Technology, 2010. [11] L. M. NI and Y. LIU,

RFID.

Kluwer Academic Publishers, 2014.

72

BIBLIOGRAFA
[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. Department of Homeland Security, 1 ed., 2010.

[14] K. C. Jorg Baus and C. Kray, University, Denmark. [15] INEC,

A Survey of Map-based Mobile Guides.

Saarland

Reporte anual de estadsticas sobre tecnologas de la informacin y comuniaciones (TIC's 2011). Diciembre 2011.
http://www.nearfieldcommunication. org/about-nfc.html. nfc-signaling.html.

[16]  About Near Field Communication.

Accessed: 28/11/2012.

[17]  NFC Signaling Technologies.

http://www.nearfieldcommunication.org/

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,
cessed: 28/11/2012. [19] w. p. s. LIBERA,

2010. Ac-

RFID:

Tecnologa,
Networks,

aplicaciones
2010.

perspectien:

vas.

Mlaga,

Espaa:

Libera

disponible

http://www.libera.net/productos/libera-rd-library-system. [20] A. Ramrez,

Estudio de la evacuacin de ocupantes y control de humo en ediocio en altura. Universidad Ponticia Comillas, 1 ed., 2012. Promoting Safe Egress and Evacuation for People with Disabilities.

[21] S. M. Michael McGlennon and B. Turner,

National Disability Authority, 1 ed., 2010.

[22] O. A.-M. L. J. Capote, D. Alvear and A. Cuesta, Modelado y simulacin computacional de evacuacin en edicios singulares,

Revista Internacional de Mtodos Numricos para Clculo y Diseo en Ingeniera, vol. 25, pp. 227245,
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 Assisted WiFi Indoor Location System for Adapting to Environmental Dynamics.
National Taiwan University, 2010. 73

BIBLIOGRAFA
[25]  Connecting to a MySQL Database.

http://netbeans.org/kb/docs/ide/

mysql.html.

Accessed: 20/11/2012.

[26]  Web Service. 26/11/2012.

http://en.wikipedia.org/wiki/Web_service.

Accessed:

[27]  Qu benecio le aporta Android a Google.

http://www.elandroidelibre. com/2012/04/que-beneficio-le-aporta-android-a-google.html. Accessed: 28/11/2012.

[28] A. members,

UTI Testing Criteria (UTC) for Android applications V1.1. 2012.

74

ANEXOS

75

ANEXO A Acondicionamiento del dispositivo mvil para funcionamiento con el mdulo de lectura RFID
La conexin entre el dispositivo Android utilizado (Samsung Galaxy Nexus-ICSMaguro) y el mdulo de lectura de tarjetas RFID (Sparkfun 125kHz RFID USB Reader) requiere de una conexin fsica y una conexin lgica. La conexin fsica debe garantizar que el mdulo RFID se conecte como dispositivo perifrico del telfono y reciba el suministro de energa para funcionar. Por otro lado, la conexin lgica debe garantizar que el telfono reciba todas las tramas de datos que el mdulo RFID enva.

A.1. Conexin fsica de los dispositivos


El telfono Android funciona en modo USB-Host , lo que signica que ste es el antrin usb y puede energizar todos los dispositivos que se conecten al puerto en este modo. Android soporta USB host desde la versin 3.0. Sin embargo, el dispositivo no energizar el mdulo conectado al puerto al no ser que se conecte mediante un cable USB tipo OTG . El puerto de salida del mdulo RFID es del tipo mini USB, en cambio el puerto del telfono 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 conexin de los cables desde un usb normal para que funcione en modo otg.

1 http://developer.android.com/guide/topics/connectivity/usb/host.html

pdf

2 Usb

OTG: Usb On-The-Go http://www.usb.org/developers/onthego/USB_OTG_Intro.

76

A.2 Conexin lgica de los dispositivos

Figura A.1:

Cableado para conectores tipo USB normal y USB modo OTG


1

El mdulo de lectura RFID es el RFID Reader ID-20(SEN-08628), adquiridos en la tienda de elementos electrnicos por internet Sparkfun , adems se le integra el mdulo RFID USB para que permita la conexin con otros dispositivos por el puerto serial, cuyo protocolo de comunicacin es FTDI .

Figura A.2:

mini USB.

a) mdulo de lectura ID-20. b)Placa de montaje RFID USB con interfaz

A.2. Conexin lgica de los dispositivos


Los dispositivos FTDI funcionan con sus propios drivers, en el caso del mdulo RFID y el dispositivo mvil el driver es el D2XX que puede ser descargado de la web de los desarrolladores

http://www.ftdichip.com/Drivers/D2XX.htm.En

adicin,

para el sistema operativo Android incluye cdigo para la interface nativa de Java

2 https://www.sparkfun.com/products/8628 3 http://www.ftdichip.com/

77

A.3 Funcionamiento del mdulo RFID conectado al mvil


(JNI) y una clase de Java D2XX (Java class) que permite a las aplicaciones acceder fcilmente al driver D2XX. El cdigo para la JNI y el driver se proveen dentro la librera libftd2xx.jni.so disponible para descargar en la pgina ocial de FTDI seccin Android:

http://www.ftdichip.com/Android.htm.

A.2.1. Instalacin de libreras D2XX JNI


Una ves descargada la librera D2XX, para el sistema operativo Android, se debe instalarla en el dispositivo y ejecutar la aplicacin de prueba del mdulo de lectura RFID. La instalacin de la librera consiste en copiar el archivo dentro de la SDcard del telfono y luego poner la direccin en la cual se copio dentro del cdigo de la aplicacin Java. La librera debe copiarse a la direccin /sdcard/Android/data/com.ftdi.d2xx/libftd2xxjni.so. Se puede copiar directamente al telfono o agregar utilizando la conexin ADB instalada con las conguraciones Android SDK para Windows. Para esto es necesario 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 nmero identicativo del dispositivo. Luego se copia la librera 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 telfono el archivo que controla los permisos de uso del puerto usb es el llamado ueventd.rc, que se encuentra dentro del directorio raz. El permiso que debe cambiarse es en la lnea donde dice: /dev/bus/usb/* 0660 root usb Se debe modicar el nmero 0660 por 0666 para permitir la lectura y escritura a travs del puerto usb.

A.3. Funcionamiento del mdulo RFID conectado al mvil


Para realizar una prueba a la conexin entre los dispositivos, hemos hecho uso de la aplicacin para Android disponible en la web de los fabricantes . Esta aplicacin

1 http://www.ftdichip.com/Drivers/D2XX/D2XXSample/D2XXSample.zip
78

A.3 Funcionamiento del mdulo RFID conectado al mvil


reconoce automticamente los dispositivos conectados y permite recibir y enviar datos a travs del puerto usb.

Figura A.3:

RFID

Captura de pantalla de la aplicacin Android para el mdulo de lectura

En la gura A.3 se ve la aplicacin funcionando y resaltado el cdigo ledo por el mdulo RFID.

79

ANEXO B Cdigo de programacin del microcontrolador


*****************************************************/ #include #include #include #include <mega32.h> <delay.h> <stdlib.h> <stdio.h>

#define LEDs PORTB #define red 0b00000001 #define green 0b00000010 #define yellow 0b00000100 #define xtal 8000000L #define baud 9600 unsigned char sensor[3]; float vin; int i; int a; int Amp_sensor=100; //factor de amplificacin de LM35 int 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 voltage delay_us(10); // Start the AD conversion ADCSRA|=0x40; // Wait for the AD conversion to complete while ((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 ms significativos para la salida*/ /***********canal y parmetros 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; /*leer los 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

Вам также может понравиться