loram: location and remote assistance for motocyclists
Anuncio
L O RAM: L OCATION AND R EMOTE A SSISTANCE FOR M OTOCYCLISTS UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA INGENIERÍA EN INFORMÁTICA PROYECTO FIN DE CARRERA LoRAM: Location and Remote Assistance for Motocyclists Israel Téllez García Septiembre, 2013 UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA Departamento de Tecnologías y Sistemas de Información PROYECTO FIN DE CARRERA LoRAM: Location and Remote Assistance for Motocyclists Autor: Israel Téllez García Director: David Villa Alises Septiembre, 2013 Israel Téllez García Ciudad Real – Spain E-mail: [email protected], [email protected] Teléfono: 660 173 118 Web site: c 2013 Israel Téllez García Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". Se permite la copia, distribución y/o modificación de este documento bajo los términos de la Licencia de Documentación Libre GNU, versión 1.3 o cualquier versión posterior publicada por la Free Software Foundation; sin secciones invariantes. Una copia de esta licencia esta incluida en el apéndice titulado «GNU Free Documentation License». Muchos de los nombres usados por las compañías para diferenciar sus productos y servicios son reclamados como marcas registradas. Allí donde estos nombres aparezcan en este documento, y cuando el autor haya sido informado de esas marcas registradas, los nombres estarán escritos en mayúsculas o como nombres propios. TRIBUNAL: Presidente: Secretario: Vocal: FECHA DE DEFENSA: CALIFICACIÓN: PRESIDENTE Fdo.: SECRETARIO Fdo.: VOCAL Fdo.: Resumen Los accidentes de tráfico constituyen una de las mayores causas de defunción actualmente en nuestro país. Según diversos estudios, la mayor parte de las víctimas mortales en accidentes de tráfico se podría evitar con una intervención rápida (la llamada «hora de oro»). Este hecho ha fomentado el interés de los gobiernos en los sistemas de detección automática de accidentes de tráfico, y tanto es así, que la Comisión Europea ha propuesto hacer obligatoria la incorporación de estos sistemas en los vehículos a partir del 2015 (ver [Eur13]). Los sistemas de detección de accidentes de tráfico consisten en un mecanismo de seguridad reactiva, que permite informar a los servicios de emergencia en el momento en que se produce un accidente. Además, suelen añadir información adicional, como la hora exacta y el lugar en el que se ha producido el suceso, agilizando la respuesta a la hora de intervenir a las víctimas. Sin embargo, este tipo de sistemas suele tener un coste elevado, y están orientados principalmente a vehículos de cuatro ruedas, siendo aún muy escasa su incorporación en motocicletas, por lo que suelen quedar exentas de esa protección. Por otra parte, en los accidentes con motocicleta el problema de localización de las víctimas se ve incrementado, ya que es habitual que aparezcan desplazadas del vehículo, dificultando enormemente las tareas de búsqueda por parte de los servicios de emergencia. Con la idea de aportar una solución práctica a todos estos problemas, se planteó la realización de este proyecto. Con la creación de L O RAM (Location and Remote Assistance for Motocyclists) se espera no solo poder detectar accidentes graves de motocicleta, sino también facilitar la localización de las víctimas en el lugar del accidente. es un sistema distribuido, que consta de tres componentes: uno para el usuario, otro de gestión y otro de rescate. La aplicación de usuario se ejecuta en un smartphone y permite la detección de incidentes y la notificación de éstos al gestor. Por otra parte la aplicación de rescate permite activar elementos luminosos y sonoros en el smartphone del usuario facilitando la localización de la víctima en el lugar del accidente. L O RAM VI Abstract Traffic accidents are a major cause of death in our country today. According to several studies, the majority of fatalities in road accidents could be avoided with prompt intervention. This fact encouraged the government interest in the automatic detection systems for traffic accidents, and so much so, that the European Commission has proposed to compel the incorporation of these systems in vehicles from 2015 (see [Eur13]). The detection systems for traffic accidents are a reactive security mechanism that allows to inform emergency services when an accident occurs. They also tend to add additional information such as the exact time and place in which the event occurred, to thereby improve the speed of intervention to victims. However, these systems often have a high cost, and are oriented mainly for four-wheel vehicles, while is still very low incorporation into motorcycles so they tend to be exempted from such protection. Furthermore, in motorcycle accidents is increased the problem of locating victims, since they are often displaced from the vehicle, making it very difficult search tasks. With the idea of providing a practical solution to all these problems, it raised the completion of this final project. With the creation of L O RAM is expected not only to detect serious motorcycle accidents, but also help locate victims of the crash. L O RAM is a distributed system that consists of three applications, one for user, another for management and another for rescue. The user application runs on a smartphone and allows the detection of incidents and reporting these to manager. Moreover rescue application activates light and sound components in the user application to make it easier to locate victims in the crash site. VII Índice general Resumen VI Abstract VII Índice general VIII Índice de cuadros XII Índice de figuras XIII Índice de listados XV Listado de acrónimos XVI Agradecimientos XVIII 1. Introducción 1 1.1. Sistemas de seguridad de vehículos . . . . . . . . . . . . . . . . . . . . . . 1 1.2. Mecanismos de detección y asistencia en accidentes de tráfico . . . . . . . 2 1.3. Problemática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Antecedentes 5 2.1. Aplicaciones distribuidas . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Arquitectura de objetos distribuidos . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. ZeroC Ice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. El Sistema Operativo Android . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.1. Componentes de una aplicación . . . . . . . . . . . . . . . . . . . 10 2.3.2. Intents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4. Ice for Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.5. Sensores en smartphone con Android . . . . . . . . . . . . . . . . . . . . . 11 VIII 2.6. Sistemas de localización . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.6.1. Localización en Android . . . . . . . . . . . . . . . . . . . . . . . 14 2.7. Sistemas RC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.7.1. Cerberus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.8. Detección automática de accidentes . . . . . . . . . . . . . . . . . . . . . 16 2.8.1. Detección automática de accidentes basada en smartphone . . . . . 17 2.8.2. WreckWatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3. Objetivos 24 3.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.2. Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.2.1. Detección del accidente . . . . . . . . . . . . . . . . . . . . . . . 24 3.2.2. Notificación de incidentes . . . . . . . . . . . . . . . . . . . . . . 25 3.2.3. Asistencia Remota . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2.4. Localización de la víctima . . . . . . . . . . . . . . . . . . . . . . 25 3.2.5. Gestión de datos de incidentes . . . . . . . . . . . . . . . . . . . . 25 3.2.6. Basado en smartphone . . . . . . . . . . . . . . . . . . . . . . . . 26 3.2.7. Estándares libres . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4. Método de trabajo 27 4.1. Metodología de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.1.1. Extreme Programming . . . . . . . . . . . . . . . . . . . . . . . . 27 4.1.2. Test Driven Development . . . . . . . . . . . . . . . . . . . . . . . 29 4.2. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.2.1. Lenguajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.2.2. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.2.3. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5. Arquitectura y Desarrollo 34 5.1. Visión general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.1.1. Módulo de Detección . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.1.2. Módulo de RC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.1.3. Módulo de Gestión de incidentes . . . . . . . . . . . . . . . . . . . 37 5.1.4. Módulo de control de acceso remoto . . . . . . . . . . . . . . . . . 37 5.1.5. Módulo de Consulta . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.1.6. Módulo de Rescate . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.2. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.2.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . 38 5.2.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . 41 5.3. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.4. Proceso de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.4.1. Detección y notificación de incidentes . . . . . . . . . . . . . . . . 43 5.4.2. Solicitud de listado de incidentes . . . . . . . . . . . . . . . . . . . 44 5.4.3. Petición de datos de usuario . . . . . . . . . . . . . . . . . . . . . 45 5.4.4. Petición de localización . . . . . . . . . . . . . . . . . . . . . . . 47 5.4.5. Peticiones de activación y desactivación de actuadores . . . . . . . 48 5.4.6. Peticiones de regulación de actuadores . . . . . . . . . . . . . . . . 50 5.4.7. Filtrado de peticiones a actuadores . . . . . . . . . . . . . . . . . . 51 5.4.8. Almacenamiento de información en Base de Datos (BD) . . . . . . 52 5.4.9. Registro y login de usuarios . . . . . . . . . . . . . . . . . . . . . 53 6. Resultados 66 6.1. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6.2. Costes y recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 6.2.1. Repositorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 7. Conclusiones y trabajo futuro 74 7.1. Objetivos alcanzados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 7.2. Propuestas de trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . 76 7.3. Conclusión personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 A. Manual de usuario 80 A.1. Login y Registro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 A.2. Iniciar ruta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 A.3. Avisar de accidente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 A.4. Cerrar sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 B. Manual de usuario de rescate 85 B.1. Login y Registro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 B.2. Selección de Accidente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 B.3. Proceso de rescate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 B.3.1. Asignación del accidente . . . . . . . . . . . . . . . . . . . . . . . 87 B.3.2. Petición de ubicación . . . . . . . . . . . . . . . . . . . . . . . . . 87 B.3.3. Activación de controles remotos . . . . . . . . . . . . . . . . . . . 88 B.4. Cerrar sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 C. Hello World, Ice for Android 90 C.1. Specification Language for Ice (S LICE) . . . . . . . . . . . . . . . . . . . . 90 C.2. Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 C.3. Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Bibliografía 98 Índice de cuadros 2.1. Sensores compatibles con Android . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Coste económico del hardware empleado . . . . . . . . . . . . . . . . . . 73 6.2. Líneas de código por lenguaje de programación . . . . . . . . . . . . . . . 73 6.3. Líneas de código separadas por componentes del sistema . . . . . . . . . . 73 6.4. Coste económico estimado en recursos humanos . . . . . . . . . . . . . . . 73 XII Índice de figuras 2.1. Arquitectura de objetos distribuidos . . . . . . . . . . . . . . . . . . . . . 6 2.2. Estructura C/S en Ice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Estructura de ejecución de aplicaciones en Android . . . . . . . . . . . . . 9 2.4. Esquema de funcionamiento de eCall (European Commision [Eurb]) . . . . 18 2.5. Estructura de un sistemas de detección de accidentes basado en Smartphone (WreckWatch [WTT+ 11]) . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.6. Diagrama de arquitectura de WreckWatch [WTT+ 11] . . . . . . . . . . . . 20 2.7. Aceleración registrada durante una caída y una frenada brusca [WTT+ 11] . 23 4.1. Modelo de proceso de XP . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.1. Estructura esquematizada de L O RAM . . . . . . . . . . . . . . . . . . . . . 35 5.2. Diagrama de secuencia que representa la comunicación entre módulos . . . 36 5.3. Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.4. Diagrama de secuencia de la notificación de un incidente . . . . . . . . . . 44 5.5. Diagrama de secuencia de la notificación de un incidente . . . . . . . . . . 46 5.6. Diagrama de secuencia de petición de datos de un usuario . . . . . . . . . . 47 5.7. Diagrama de secuencia de la solicitud de localización . . . . . . . . . . . . 49 5.8. Diagrama de secuencia de la activación del altavoz . . . . . . . . . . . . . 50 5.9. Diagrama de secuencia de intento de activación del vibrador con batería baja 52 5.10. Esquema de la base de datos . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.11. Diagrama de secuencia del proceso de login aceptado . . . . . . . . . . . . 54 6.1. Gráfico de los valores máximos de aceleración en valor absoluto para una frenada de emergencia a 30km/h. El eje vertical expresa la fuerza de aceleración experimentada en m/s2 y el eje horizontal expresa el momento de tiempo en décimas de segundo (ds) . . . . . . . . . . . . . . . . . . . . . . 67 6.2. Gráfico de los valores máximos de aceleración en valor absoluto para una frenada de emergencia a 50km/h. El eje vertical expresa la fuerza de aceleración experimentada en m/s2 y el eje horizontal expresa el momento de tiempo en décimas de segundo (ds) . . . . . . . . . . . . . . . . . . . . . . 68 XIII 6.3. Pantalla de log del gestor tras la recepción de un incidente . . . . . . . . . 69 6.4. Pantalla de listado de incidentes . . . . . . . . . . . . . . . . . . . . . . . 69 6.5. Pantalla de datos de incidente . . . . . . . . . . . . . . . . . . . . . . . . . 70 6.6. Captura de pantalla de LoRAM_Rescue mostrando ubicación de la víctima 71 6.7. Pantalla de log del gestor de la activación de los controles . . . . . . . . . . 71 A.1. Pantalla de inicio de sesión . . . . . . . . . . . . . . . . . . . . . . . . . . 80 A.2. Formulario de registro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 A.3. Pantalla de inicio de ruta . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 A.4. Pantalla de trayecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 A.5. Pantalla de confirmación de aviso . . . . . . . . . . . . . . . . . . . . . . 83 A.6. Pantalla de asistencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 A.7. Diálogo de cierre de sesión . . . . . . . . . . . . . . . . . . . . . . . . . . 84 B.1. Error producido durante el inicio de sesión . . . . . . . . . . . . . . . . . . 86 B.2. Pantalla de listado de incidentes . . . . . . . . . . . . . . . . . . . . . . . 86 B.3. Pantalla de datos de incidente con incidente asignado . . . . . . . . . . . . 87 B.4. Error de localización por incidente no asignado . . . . . . . . . . . . . . . 88 B.5. Panel de control remoto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 B.6. Panel de control remoto con controles activos . . . . . . . . . . . . . . . . 89 Índice de listados 2.1. Ejemplo de interfaz en S LICE . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. Ejemplo de obtención de sensor acelerómetro en Android . . . . . . . . . . 12 2.3. Ejemplo de petición de localización en Android con Global Positioning System (GPS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4. Permisos necesarios para uso de GPS en Android . . . . . . . . . . . . . . 15 5.1. Test de integración de la notificación de un incidente . . . . . . . . . . . . 55 5.2. S LICE empleado en la primera iteración . . . . . . . . . . . . . . . . . . . . 56 5.3. Test de integración de la solicitud del listado de incidentes . . . . . . . . . 57 5.4. Cambios realizados en el S LICE de la primera iteración . . . . . . . . . . . 58 5.5. Cambios realizados en el S LICE de la segunda iteración . . . . . . . . . . . 58 5.6. Cambios realizados en el S LICE de la tercera iteración . . . . . . . . . . . . 59 5.7. Test de integración de la solicitud de localización a la víctima . . . . . . . . 60 5.8. Cambios realizados en el S LICE de la cuarta iteración . . . . . . . . . . . . 61 5.9. Cambios realizados en el S LICE de la quinta iteración . . . . . . . . . . . . 62 5.10. Cambios realizados en el S LICE de la sexta iteración . . . . . . . . . . . . . 62 5.11. Test unitario de intento de activación con batería baja . . . . . . . . . . . . 63 5.12. Cambios realizados en el S LICE de la séptima iteración . . . . . . . . . . . 64 5.13. Test de integración de login aceptado . . . . . . . . . . . . . . . . . . . . . 65 C.1. Slice para ejemplo de uso de Ice en Android . . . . . . . . . . . . . . . . . 90 C.2. Cliente de ejemplo de Ice for Android . . . . . . . . . . . . . . . . . . . . 90 C.3. Definición en XML de la interfaz del cliente . . . . . . . . . . . . . . . . . 93 C.4. Servidor de ejemplo de Ice for Android . . . . . . . . . . . . . . . . . . . 93 C.5. Implementación de la interfaz Hello . . . . . . . . . . . . . . . . . . . . . 95 C.6. Definición en XML de la interfaz del servidor . . . . . . . . . . . . . . . . 96 XV Listado de acrónimos LoRAM Location and Remote Assistance for Motocyclists RC Remote Control C/S Cliente-Servidor GPS Global Positioning System CORBA Common Object Request Broker Architecture RMI Remote Method Invocation Ice Internet Communications Engine Slice Specification Language for Ice API Application Programming Interface SO Sistema Operativo XML eXtensible Markup Language URI Uniform Resource Identifier IDE Integrated Development Environment GSM Global System for Mobile Communications ILS Indoor Location Systems RTLS Real Time Location System RFID Radio-Frequency Identification PC Personal Computer SMS Short Message Service SIM Subscriber Identity Module ACN Automatic Crash Notification UI User Interface XP eXtreme Programming TDD Test Driven Development SUT Subject Under Test SDK Software Development Kit XVI BD Base de Datos SGBD Sistema Gestor de Bases de Datos PFC Proyecto Fin de Carrera DGT Dirección General de Tráfico OMS Organización Mundial de la Salud SLOC Source Lines Of Code GNU GNU Is Not Unix Agradecimientos Quisiera aprovechar este pequeño espacio para dar las gracias a todas las personas que de una u otra forma han hecho que sea posible la finalización de estos estudios. En primer lugar, me gustaría dar las gracias a mis padres por creer en mi y darme la oportunidad de estudiar esta carrera, realizando el esfuerzo que sé que han realizado para que esto sea posible. También, agradecer al resto de mis familiares su preocupación constante y todos los consejos que en algún momento me han dado. Debo agradecer también a Blanca el haber estado siempre ahí apoyándome y dándome fuerzas para seguir adelante. A mi amigo y compañero Abraham, gracias por el apoyo y amistad recibido durante todos estos años. Gracias también a todas las personas que he conocido a lo largo de los años de carrera y con los que he compartido tantos buenos momentos, especialmente a Rubén, Alberto, Fran, David y Jesús. También debo agradecerle a David Villa el haberme dado la oportunidad de realizar este proyecto, y el haberme brindado la ocasión de adquirir nuevos y valiosos conocimientos. Por último no puedo olvidar dar las gracias a mis amigos de toda la vida, por su interés y preocupación hacia mí, y por todos los buenos ratos que hemos compartido. Israel Téllez García XVIII A mi familia, novia y amigos Capítulo 1 Introducción E n los accidentes de motocicleta es habitual encontrar problemas para localizar a los motoristas accidentados, ya que estos suelen salir despedidos del vehículo, dificultando las labores de búsqueda y asistencia de las víctimas. En la mayoría de estos accidentes una rápida intervención puede ser vital y puede incluso permitir salvar una vida. Los denominados teléfonos inteligentes o smartphone constituyen una plataforma con múltiples sensores de diversa índole que nos permiten realizar tareas como localización o incluso detectar accidentes. La creciente evolución de estas tecnologías, y el abaratamiento de sus costes, ha hecho posible la aparición de nuevas aplicaciones cada vez más sofisticadas, orientadas tanto a la localización de personas como a la detección de riesgos. La realización de este proyecto pretende hacer uso de estas tecnologías para proporcionar una solución económica a los problemas expuestos. En este capítulo se introducirán los principales conceptos que han intervenido en su realización. 1.1 Sistemas de seguridad de vehículos Desde la aparición de los primeros vehículos a motor su capacidades han ido en aumento, siendo éstos cada vez más potentes y veloces. Este hecho ha supuesto la necesidad de crear mecanismos que garanticen la seguridad y prevengan de posibles accidentes. Las empresas dedicadas a la fabricación de automóviles han ido incorporando en los vehículos cada vez más y mejores tecnologías con el fin de hacer la conducción más segura y reducir el número de accidentes producidos, o en el caso de que estos ocurran, minimizar en la medida de lo posible el número de víctimas mortales. Los sistemas de seguridad de vehículos, se dividen según dos puntos de vista diferentes que abarcan la prevención y la limitación de daños en caso de producirse un accidente, tanto para el vehículo, como para sus ocupantes [Par00]. Estos puntos de vista son los siguientes: Seguridad activa: es la seguridad que nos proporcionan todos los elementos incorporados en el vehículo, incrementando su seguridad durante los desplazamientos, con el fin de disminuir el riesgo de que se produzca un accidente. Los sistemas de seguridad 1 1. I NTRODUCCIÓN activa pueden estar orientados a mejorar la seguridad en diferentes partes del vehículo, como en el motor, la transmisión o los frenos. Entre los mecanismos de seguridad activa encontramos los frenos de disco, sistemas de control de estabilidad (ESP), sistema de control del par motor (ASR) o el sistema de control de frenada (ABS). Seguridad pasiva: es la seguridad que nos proporcionan todos los elementos, que incorporados o no al vehículo, reducen los daños de los ocupantes, en caso de que se produzca el accidente. Entre los mecanismos de seguridad pasiva destacamos el cinturón de seguridad, el airbag o el casco. En los últimos años están apareciendo nuevos sistemas de seguridad basados en detección del entorno. Dichos sistemas están aún poco extendidos y en la mayoría de los casos se presentan como equipamientos opcionales o son solo prototipos. Entre estos nuevos sistemas podemos encontrar sistemas anticolisión como el City Safety de Volvo [Vol12], sistemas de alerta de cambio involuntario de carril como LDWS de Citroen [Cit12] o sistemas de reconocimiento de objetos como ContiGuard [Con11] o EyeSight [Sub12], por destacar algunos. 1.2 Mecanismos de detección y asistencia en accidentes de tráfico Recientemente han surgido un nuevo tipo de sistemas de seguridad para vehículos que podríamos encuadrar en el marco de la seguridad pasiva. Este tipo de sistemas de seguridad detectan mediante sensores cuando se produce un accidente, y notifican este suceso a un centro de emergencias. El interés por este tipo de sistemas ha ido en aumento, llegando hasta el punto de ser obligatoria su incorporación en los vehículos de fabricación nueva, en Europa, a partir del 2015. El funcionamiento de estos sistemas se caracteriza no solo por detectar el accidente, si no también por facilitar la localización de las víctimas. Por ello, suelen incorporar un sistema de posicionamiento, como el GPS, que permita determinar la posición y enviarla al centro de emergencias. Además, pueden añadir información adicional que se considere importante, como la dirección que llevaba el vehículo en la carretera, el estado de vuelco, etc. Entre los sistemas de este tipo podemos destacar OnStar, sobre todo extendido en America, ó eCall, que ha sido el escogido para su uso en Europa. Todos estos sistemas hacen uso de hardware adicional instalado en el vehículo con el fin de detectar el accidente y alertar a emergencias. Sin embargo, los smartphone que encontramos hoy en día, cuentan con las características apropiadas para realizar estas funciones. Como ejemplo de un mecanismo de detección y asistencia basado en smartphone podemos destacar WreckWatch que será estudiado en detalle en la sección 2.8.2 de este documento. 2 1. I NTRODUCCIÓN 1.3 Problemática A pesar de los esfuerzos realizados por los gobiernos, compañías de fabricación de vehículos o instituciones como la Dirección General de Tráfico (DGT)1 , los accidentes siguen apareciendo con frecuencia en las carreteras, constituyendo la octava causa de muerte a nivel mundial según la Organización Mundial de la Salud (OMS)2 , y se prevé que será la quinta para 2030 de no tomar medidas urgentes [Org13]. El problema radica en la localización a tiempo de las víctimas, ya que en muchas ocasiones las víctimas no están en condiciones de avisar del suceso, y pasa cierto tiempo hasta que alguien los localiza y es capaz de avisar a emergencias. En los vehículos de dos ruedas, este problema de localización se ve incrementado, ya que los ocupantes del vehículo suelen salir despedidos y pueden quedar atrapados en algún lugar poco visible, como unos matorrales abruptos. A pesar de que existen diferentes sistemas orientados a detectar accidentes de vehículos y a aportar la ubicación de los ocupantes, los sistemas orientados a vehículos de dos ruedas son muy escasos, y no incorporan mecanismos que permitan realizar la localización de los ocupantes in situ. Todos estos problemas, unidos al alto coste y a las dificultades de instalación, que presentan en algunos casos los sistemas de detección de accidentes disponibles en el mercado, nos llevó a la creación de este trabajo. El objetivo general que se persigue con L O RAM es la creación de un sistema capaz de detectar accidentes de motocicleta y facilitar la localización de las víctimas sobre el lugar del accidente, todo ello haciendo uso exclusivo de las tecnologías incorporadas en un smartphone convencional. 1.4 Estructura del documento La realización de este documento se ha llevado a cabo siguiendo la normativa vigente de la Escuela Superior de Informática de Ciudad Real para la realización de un PFC. La distribución del contenido de este documento por capítulos es la siguiente: Capítulo 1: Introducción En este capítulo se ha mostrado una introducción al ámbito en el que se engloba este trabajo, comentando brevemente la problemática existente. Capítulo 2: Antecedentes El capítulo de antecedentes realiza un estudio sobre los conceptos y tecnologías implicadas en el desarrollo del proyecto. 1 2 http://www.dgt.es/ http://www.who.int/es/ 3 1. I NTRODUCCIÓN Capítulo 3: Objetivos En este capítulo se presenta el objetivo general y los distintos objetivos específicos que se persiguen con la realización del PFC. Capítulo 4: Método de trabajo A lo largo de este capítulo se expone la metodología de desarrollo empleada, y se muestran las herramientas utilizadas en la realización de este trabajo. Capítulo 5: Arquitectura y Desarrollo En este capítulo se muestra la división del sistema, detallando cada una de las partes que lo forman. También se define el listado de requisitos, y se expone el proceso de desarrollo por iteraciones seguido durante la realización del proyecto. Capítulo 6: Resultados A lo largo de este capítulo se analizan los resultados obtenidos con la ejecución del sistema, y los costes derivados de su realización. Capítulo 7: Conclusiones y Trabajo futuro El capítulo de conclusiones y propuestas muestra en qué grado han sido alcanzados los objetivos marcados. También se exponen algunas propuestas de trabajo futuro y se finaliza con una valoración personal sobre lo que ha supuesto la realización de este trabajo. 4 Capítulo 2 Antecedentes E ste capítulo tiene como finalidad explicar al lector los distintos componentes y tecnologías que han tenido lugar en el desarrollo de este proyecto fin de carrera. Debido a la escasa existencia de sistemas similares a L O RAM, basaremos el estudio del estado del arte en mostrar los diferentes aspectos que han tenido lugar para su desarrollo. 2.1 Aplicaciones distribuidas Una aplicación distribuida es aquella en la que existen diferentes componentes, los cuales pueden ser ejecutados en distintas plataformas conectadas a una misma red. La comunicación mas habitual es la que presenta la arquitectura de dos niveles Cliente-Servidor (C/S), aunque podemos encontrar arquitecturas con una división de más niveles. Con el término distribución nos referimos a software construido por varias partes, donde a cada una se le asigna un conjunto específico de responsabilidades dentro del sistema. Para poder realizar una separación física del sistema, se debe tener clara la separación lógica del mismo. Así podemos distinguir entre separación lógica «capas» y física «niveles». La arquitectura de una aplicación distribuida, según su funcionalidad, presenta tres grupos de elementos: Capa de servidor: se encarga de recibir peticiones de acceso a servicios o a datos y de suministrar esta información al solicitante. Capa de negocio: gestiona los procesos internos y el acceso a los datos. Capa de presentación: constituye los mecanismos necesarios para hacer posible la interación con el usuario. A la hora de realizar una aplicación distribuida es importante tener en cuenta varios aspectos como la topología de la red, concurrencia o seguridad, ya que será necesario controlar los tiempos de respuesta y proporcionar mecanismos que impidan accesos no autorizados. 2.2 Arquitectura de objetos distribuidos Una arquitectura de objetos distribuidos [Som05] está compuesta por objetos que proveen servicios a través de una interfaz que ellos mismos facilitan. A diferencia de las arquitec5 2. A NTECEDENTES 6 turas C/S no existe una distinción lógica entre el proveedor y el receptor del servicio (ver figura 2.1). Figura 2.1: Arquitectura de objetos distribuidos Un middleware conocido como intermediario de peticiones de objetos será el encargado de proporcionar los servicios necesarios para realizar la comunicación entre objetos. Además dicho middleware permitirá a los objetos ser añadidos o eliminados del sistema. Existen varias alternativas hoy en día que se ajustan a esta arquitectura. Así tenemos middleware orientados a objetos como CORBA o RMI por citar algunos. A continuación pasamos a estudiar ZeroC Ice por ser el escogido para la realización de este proyecto. 2.2.1 ZeroC Ice El middleware I CE (Internet Communications Engine) [VMA12] desarrollado por ZeroC, Inc.1 , nos permite realizar una comunicación de objetos distribuidos. Este middleware está diseñado para soportar varios lenguajes de programación como C, Java o Python entre otros. Además esta disponible para múltiples plataformas entre las que se encuentran GNU/Linux, Windows o Android. Todo esto lo convierte en una opción muy interesante a la hora de crear un sistema distribuido de objetos, dada su amplia capacidad de adaptación. En I CE podemos destacar las siguientes ventajas: Al utilizar la misma implementación para todos los lenguajes no se añade complejidad al desarrollo de un proyecto multi-lenguaje. Los detalles de configuración de las comunicaciones son completamente ortogonales al desarrollo del software. Presenta una interfaz sencilla, en la que el significado de las operaciones se deduce fácilmente. 1 http://www.zeroc.com 2. A NTECEDENTES 7 Para realizar una comunicación entre dos partes de una aplicación una debe asumir el rol de cliente y la otra el de servidor2 . La parte que asuma el papel de cliente solicitará servicios mediante la invocación a métodos de objetos remotos, y la parte con el rol de servidor proporcionara servicios como respuesta a las solicitudes de los clientes. En la figura 2.2 se muestra el aspecto de esta estructura en I CE. Figura 2.2: Estructura C/S en Ice Para comprender el funcionamiento de I CE se necesitan conocer una serie de conceptos que detallaremos en las siguientes líneas. Objeto En I CE un objeto es una entidad conceptual que tiene un tipo, una identidad e información de direccionamiento. De forma específica podemos caracterizarlo por los siguientes puntos: Es una entidad en el espacio de direcciones remoto o local capaz de responder a las peticiones de los clientes. Un único objeto I CE puede ser instanciado en un único servidor o de manera redundante, en múltiples servidores. Cada objeto tiene una o mas interfaces. Una interfaz es una colección de operaciones soportadas por un objeto. Una operación tiene cero o mas parámetros y un valor de retorno. Parámetros y valores de retorno tienen un tipo específico, y los parámetros además tienen una determinada dirección. 2 Estos roles pueden ser intercambiados entre las distintas partes durante la comunicación 2. A NTECEDENTES Un objeto I CE tiene una interfaz principal diferenciada del resto. Además, puede proporcionar cero o más interfaces alternativas excluyentes, conocidas como facets. Cada objeto tiene una identidad de objeto única que lo distingue del resto de objetos. Proxy Cuando hablamos de un proxy en I CE nos referimos a un representante local de un objeto (generalmente remoto) en el espacio de direcciones del cliente. I CE soporta varios tipos de proxies para cubrir diferentes situaciones: Proxies textuales, la información asociada se representa como una cadena. Proxies directos, encapsulan una identidad de objeto junto con la dirección asociada a su servidor. Proxies indirectos, pueden proporcionar sólo la identidad de un objeto, o bien pueden especificar una identidad junto con un identificador de adaptador de objetos. Proxies fijos, están asociados a una conexión en particular. El proxy contiene un manejador de conexión. Sirviente Un sirviente es el componente de la parte del servidor encargado de proporcionar el comportamiento asociado a la invocación de operaciones. Se trata de una instancia de una clase registrada en el núcleo de ejecución del servidor como sirviente para uno o varios objetos. Las operaciones de la interfaz del objeto I CE se corresponden con los métodos de esta clase, que son los encargados de proporcionar el comportamiento de dichas operaciones. Un único objeto distribuido puede tener múltiples sirvientes, pero también un sirviente puede encarnar uno o varios objetos. La diferencia radica en que si un sirviente encarna a un único objeto, la identidad de este objeto estará implícita en el sirviente, pero si el sirviente encarna varios objetos, el sirviente mantendrá la identidad del objeto con cada solicitud y así podrá decir que objeto encarnar. Slice El lenguaje S LICE (Specification Language for Ice) constituye el mecanismo de abstracción fundamental para la separación de las interfaces de objetos de sus implementaciones. S LICE establece un contrato entre el cliente y el servidor en el que se describen los tipos de objetos e interfaces utilizados por una aplicación. Esta descripción es independiente del lenguaje de implementación, por lo que no importa si el cliente está escrito en el mismo lenguaje que el servidor. En el listado de código 2.1 se muestra un ejemplo de interfaz en S LICE. 8 2. A NTECEDENTES 1 2 3 4 5 9 module Example { interface Hello { void puts ( string message ) ; }; }; Listado 2.1: Ejemplo de interfaz en S LICE Una descripción más amplia de este lenguaje la podemos encontrar en el manual de I CE [Zer11]. Language Mappings Se conoce por language mappings a las reglas que rigen la forma en que cada construcción S LICE se traduce a un lenguaje de programación específico. Estas reglas son simples y regulares, haciendo innecesaria la lectura del código generado para utilizar la API que se genera. 2.3 El Sistema Operativo Android Android3 es un Sistema Operativo (SO) basado en Linux propiedad de la empresa Google y apollado por la Open Handset Alliance. Fue diseñado para trabajar sobre diferentes dispositivos (Tablets, móviles, reproductores multimedia, ...) y actualmente se encuentra en la versión 4.2 «Jelly Bean». En Android las aplicaciones se programan en Java, y son empaquetadas en paquetes «.apk». Cada aplicación se ejecuta en un proceso independiente al que se le asocia una máquina virtual conocida como Dalvik [Anda]. En la figura 2.3 podemos ver un esquema sobre como se ejecutan las aplicaciones en Android. Figura 2.3: Estructura de ejecución de aplicaciones en Android 3 http://www.android.com 2. A NTECEDENTES Este tipo de ejecución presenta importantes ventajas, como por ejemplo, si una aplicación se bloquea, el resto del sistema no se verá afectado y su máquina virtual podrá ser reiniciada. El sistema podrá gestionar la carga de aplicaciones en tiempo real, decidiendo cuales permanecerán en memoria y cuales serán eliminadas. Además cada aplicación será la encargada de gestionar sus propios datos decidiendo que información ofrecer en cada momento. 2.3.1 Componentes de una aplicación Los componentes nos ayudan a definir el comportamiento global de una aplicación en Android. Cada uno de ellos constituye una entidad propia y desempeña un papel específico. En Android cada uno de los componentes definidos por una aplicación podrá ser utilizado por otras aplicaciones. Esto es posible gracias a que no se define un punto único de entrada a la aplicación, a diferencia de otros sistemas donde debe existir un «main». Los componentes de una aplicación Android se pueden clasificar en cuatro tipos con diferentes propósitos y ciclos de vida. Activities Una Activity representa una pantalla con una interfaz de usuario. Las aplicaciones pueden estar compuestas de varias activities, pero sólo una de ellas será la cargada al iniciar la aplicación, considerada activity «principal». En algunas ocasiones, una activity puede estar compuesta por fragments. Un fragment representa una porción de la interfaz de usuario en una activity, de modo que se pueden combinar múltiples fragment para formar una activity. Para hacer uso de este componente se necesita la API level 11 de Android. Services Un servicio es un componente sin interfaz de usuario que se ejecuta en segundo plano «background». Son similares a los servicios presentes en otros sistemas, como por ejemplo los demonios en Linux. Otros componentes como las Activities pueden iniciar estos servicios o unirse a alguno en ejecución. Content providers Gestionan un conjunto de datos de aplicación compartidos. Estos datos pueden estar almacenados en una base de datos SQLite, en la web, o en cualquier otro lugar de almacenamiento persistente al que pueda acceder la aplicación. A través del proveedor de contenidos (content provider) otras aplicaciones podrán consultar o modificar los datos dependiendo de los permisos que se le otorguen. Android nos ofrece algunos proveedores de contenidos, como por ejemplo el que gestiona la información de contacto del usuario o la agenda, aunque también podemos crear nuestro propio content provider y ofrecerlo al sistema. 10 2. A NTECEDENTES Broadcast receivers Un broadcast receiver es un componente sin interfaz de usuario que reacciona a los anuncios broadcast del sistema. Estos anuncios nos informan de que la batería está baja, que se ha capturado una imagen, etc. Las aplicaciones de usuario también pueden iniciar anuncios broadcast para informar de algún evento a otras aplicaciones. En la práctica las aplicaciones pueden tener varios broadcast receiver. Cada uno de ellos deberá implementarse como una subclase de BroadcastReceiver, y cada mensaje de broadcast le llegará como un objeto Intent. 2.3.2 Intents Un Intent es un mensaje asíncrono que nos permite activar otros componentes, ya sean de la misma aplicación que lo solicita o de otra. Los componentes que nos permite activar son los de los tipos Activities, Services o Broadcast receivers. Para las Activities y Services, un intent define la acción a realizar y puede especificar una Uniform Resource Identifier (URI) de datos necesarios. Para los Broadcast receivers el intent simplemente define el tipo de broadcast que quiere recibir. 2.4 Ice for Android Ice for Android [Zera] presenta una solución para crear aplicaciones distribuidas orientadas a objetos para plataformas móviles que usan el SO Android. Soporta las mismas APIs que Ice for Java lo que facilita la reutilización y la experiencia. Para mejorar la productividad ZeroC ha creado Slice2Java, un plug-in de Eclipse4 que automatiza la traducción de los ficheros Slice y gestiona el código resultante generado. El uso de este IDE se debe a la estrecha integración que tiene con las herramientas de desarrollo ofrecidas por Android. Para descargar e instalar este plug-in podemos consultar la siguiente dirección http://www.zeroc.com/eclipse.html. En el Anexo C podemos encontrar un ejemplo sencillo sobre el uso de I CE en Android. 2.5 Sensores en smartphone con Android Un smartphone o teléfono inteligente, es un teléfono móvil que incorpora un SO y una tecnología más compleja que dota al teléfono de más funciones de conectividad y capacidades de cómputo más avanzadas. Los smartphone incorporan una serie de sensores, cada vez más amplia, que nos permiten realizar aplicaciones capaces de detectar determinadas circunstancias, y realizar una serie de acciones. El SO Android da soporte a tres grandes categorías de sensores [Andd]: 4 http://www.eclipse.org 11 2. A NTECEDENTES Sensores de movimiento: miden fuerzas de rotación y aceleración sobre los tres ejes. Sensores ambientales: miden parámetros ambientales como la temperatura del aire, la presión, la iluminación y la humedad. Sensores de posición: miden la posición física del dispositivo. En el cuadro 2.1 podemos ver la lista completa de sensores compatibles con Android. En Android el framework que nos permite acceder a los sensores forma parte del paquete android.hardware. Este framework nos permite determinar el tiempo de ejecución de los sensores en el dispositivo, así como determinar las capacidades de cada sensor, como su alcance máximo, requisitos de energía y resolución. Para usar un sensor en Android primero es preciso identificarlo, por lo que crearemos una instancia de SensorManager y después obtendremos la lista de sensores del dispositivo mediante una llamada a getSensorList(). A este método podremos indicarle si deseamos obtener la lista completa de sensores «TYPE_ALL» o solo los de un tipo específico, usando la constante adecuada. También podemos obtener un sensor de un tipo específico llamando al método getDefaultSensor(), lo que nos devolverá un sensor predeterminado para el tipo indicado o null si no existe un sensor para ese tipo. Finalmente para obtener los datos del sensor debemos registrar un SensorEventListener para el sensor específico. En el listado 2.2 se muestra como crear una clase que obtenga un sensor acelerómetro y se registre para obtener cambios en él. 1 public class A c ce l e ro m e te r S en s o r implements S en s o r Ev e n tL i s te n e r { 3 4 private SensorManager sM ; private Sensor sA ; 6 7 8 public A c ce l e ro m e te r S en s o r ( Context ctx ) { sM = ( SensorManager ) ctx . getSystemService ( Context . SENSOR_SERVICE ) : sA = sM . getDefaultSensor ( Sensor . TY PE _A CC EL ER OME TE R ) ; sM . registerListener ( this , sA , SensorManager . S E N SO R _ D EL A Y _N O R MA L ) ; 10 11 } 16 @Override public final void onA ccurac yChang ed ( Sensor sensor , int accuracy ) { // Hacer algo si se produce un cambio de precision en el sensor } 18 19 20 21 @Override public final void onSensorChanged ( SensorEvent event ) { // Hacer algo si el sensor recoge un nuevo valor } 13 14 15 22 } Listado 2.2: Ejemplo de obtención de sensor acelerómetro en Android 12 2. A NTECEDENTES 13 Sensor Tipo Descripción Usos comunes TYPE_ACCELEROMETER HW Detección de movimiento. TYPE_AMBIENT_TEMPERATURE HW TYPE_GRAVITY SW/HW TYPE_GYROSCOPE HW TYPE_LIGHT HW TYPE_LINEAR_ACCELERATION SW/HW TYPE_MAGNETIC_FIELD HW TYPE_ORIENTATION SW TYPE_PRESSURE HW Mide la fuerza de aceleración en m/s2 que se aplica a un dispositivo en los tres ejes (X, Y, Z), incluida la fuerza de gravedad. Mide la temperatura ambiente en grados Celsius (0 C) Mide la fuerza de la gravedad en m/s2 que se aplica a un dispositivo en los tres ejes (X, Y, Z). Mide la frecuencia de rotación de un dispositivo en rad/s alrededor de cada uno de los tres ejes (X, Y, Z). Mide la iluminación en lux (lx). Mide la fuerza de aceleración en m/s2 que se aplica a un dispositivo en los tres ejes (X, Y, Z), excluyendo la fuerza de gravedad. Mide el campo geomagnético en los tres ejes (X, Y, Z) en µT . Mide los grados de rotación que un dispositivo hace alrededor de los tres ejes (X, Y, Z). Mide la presión del aire en hPa o mbar. TYPE_PROXIMITY HW TYPE_RELATIVE_HUMIDITY HW TYPE_ROTATION_VECTOR SW/HW Mide la proximidad de un objeto en cm respecto a la pantalla de un dispositivo. Mide la humedad relativa del ambiente en porcentaje ( %). Mide la orientación de un dispositivo, proporcionando los tres elementos del vector de rotación. Comprobar temperatura del aire. Detección de movimiento. Detección de rotación. Control de brillo de la pantalla. Supervisión de la aceleración en un solo eje. Creación brújula. de una Determinar la posición del dispositivo. Supervisión de los cambios de presión en el aire. Posición del teléfono durante una llamada. Supervición de la humedad absoluta y relativa. Detección de movimiento y rotación. Cuadro 2.1: Sensores compatibles con Android (A NDROID D EVELOPERS [Andd]) 2. A NTECEDENTES Como se puede observar en el listado 2.2 la interfaz SensorEventListener requiere la implementación de los métodos onAccuracyChanged() y onSensorChanged(). El primero nos indica un cambio en la precisión del sensor, y el segundo un nuevo valor recogido por el sensor. 2.6 Sistemas de localización Los sistemas de localización [dlSdlIO09] son aquellos que nos permiten determinar la posición geográfica de un objeto móvil o inmóvil, mediante una serie de tecnologías de posicionamiento. Para que la localización sea posible es preciso contar con un sistema de referencia que nos permita determinar una posición sobre un plano. De forma general, el sistema más extendido es el sistema de coordenadas geográficas, que se basa en dos coordenadas (latitud y longitud) para determinar la posición de un punto sobre la superficie terrestre. Según las tecnologías empleadas para realizar la localización podemos diferenciar entre dos tipos de sistemas de localización, basándonos en el alcance de su ámbito de actuación: outdoor (exteriores): Son usados para localización en grandes áreas geográficas. En cuanto a las tecnologías empleadas encontramos sistemas basados en satélite como el GPS (Estados Unidos), GALILEO (Unión Europea), o basados en redes celulares de largo alcance como GSM (Global System for Mobile Communications). indoor (Interiores): Están destinados a localización en pequeñas áreas geográficas, o para interiores de edificios. Los ILS (Indoor Location Systems) se utilizan principalmente para implantar sistemas Real Time Location System (RTLS) mediante el uso de tecnologías inalámbricas de corto alcance como Wi-Fi, Bluetooth, Radio-Frequency Identification (RFID) o Zigbee. 2.6.1 Localización en Android La localización en Android [Andc] se realiza mediante el paquete android.location5 , que proporciona las APIs necesarias para determinar la ubicación geográfica del usuario. Cuando se desarrolla una aplicación para determinar la ubicación en Android se pueden emplear dos mecanismos: (Global Positioning System)6 : es el más preciso, pero conlleva un enorme gasto de batería y solo funciona en entornos outdoor. GPS Network Location Provider: hace uso de antenas celulares y señales Wi-Fi. Proporciona información tanto indoor como outdoor, pero en áreas interurbanas es poco preciso. 5 6 http://developer.android.com/reference/android/location/package-summary.html http://www.gps.gov/ 14 2. A NTECEDENTES Para obtener la ubicación de un usuario en Android primero debemos solicitar al sistema una instancia del servicio LocationManager. Posteriormente, debemos indicar a este servicio que deseamos recibir actualizaciones de ubicación, para lo que deberemos hacer una llamada a requestLocationUpdates() pasándole un objeto LocationListener. Este LocationListener deberá ser implementado definiendo una serie de métodos que el LocationManager llama cuando cambia la ubicación del usuario. En el listado 2.3 se muestra un ejemplo de petición de localización mediante GPS con un intervalo de 500ms entre actualizaciones de localización. En este ejemplo se recoge la latitud y longitud, pero no se hace nada con ellas. 1 2 3 Context ctx = g e t A p p l i c a t i o n C o n t e x t () ; LocationManager lM ; LocationListener lL ; 5 lM =( LocationManager ) ctx . getSystemService ( Context . LOCATION_SERVICE ) ; 7 8 9 10 11 lL = new LocationListener () { public void onL ocatio nChang ed ( Location location ) { double lat = location . getLatitude () ; double lon = location . getLongitude () ; } 13 public void on Pr ov id er Di sa bl ed ( String provider ) {} 15 public void onP rovide rEnabl ed ( String provider ) {} 17 18 public void onStatusChanged ( String provider , int status , Bundle extras ) {} 20 }; 22 lM . r e q u e s t L o c a t i o n U p d a t e s ( LocationManager . GPS_PROVIDER , 500 , 0 , lL ) ; Listado 2.3: Ejemplo de petición de localización en Android con GPS Para que sea posible la utilización de la localización GPS es necesario añadir el permiso adecuado en el fichero AndroidManifest.xml (ver listado 2.4). 1 2 3 4 < manifest ... > < uses - permission android:name = " android . permission . A C C E S S _ F I N E _ L O C A T I O N " / > </ manifest > Listado 2.4: Permisos necesarios para uso de GPS en Android 2.7 Sistemas RC Los sistemas RC (Remote Control) son aquellos que nos permiten controlar a distancia uno o varios dispositivos que pueden estar dotados de una serie de sensores y actuadores. En 15 2. A NTECEDENTES estos sistemas intervienen dos partes: una que envía órdenes y otra que las recibe y actúa en consecuencia. Por lo que tenemos una comunicación entre ambas emisor/receptor. La parte que envía las órdenes contendrá un panel de control para permitir activar componentes actuadores o modificar su comportamiento. También puede incluir alertas o indicadores que nos permitan conocer el estado de algún sensor. Por otro lado la parte que recibe las ordenes estará compuesta por una serie de sensores y actuadores a los que tendrá acceso. Cuando reciba una petición se pondrá en contacto con estos para realizar la acción necesaria. Existe una amplia gama de sistemas destinados al control remoto de dispositivos. Estos pueden ir desde algo tan cotidiano como el mando a distancia de una televisión o un coche teledirigido, hasta sistemas más complejos que nos permitan controlar un PC o un smartphone a distancia. 2.7.1 Cerberus En cuanto a sistemas RC orientados a smartphone podemos destacar Cerberus7 . Cerberus [pla] es un app disponible para Android cuya funcionalidad esta orientada a la recuperación de terminales Android perdidos o robados. Permite el control remoto del dispositivo de dos formas diferentes: Mediante Internet accediendo desde la página web de Cerberus. Mediante mensajes de texto SMS. La aplicación cuenta con una función conocida como «SIM Checker» que nos informa del nuevo número que tendría el teléfono en el caso de que la tarjeta SIM sea cambiada, de modo que la manipulación del dispositivo mediante mensajes SMS siga siendo posible. El control remoto de Cerberus permite realizar una gran variedad de acciones en el dispositivo, entre las que podemos destacar algunas como la localización del dispositivo, activación de una alarma, grabación de audio con el micrófono o la obtención de las últimas llamadas realizadas o recibidas. 2.8 Detección automática de accidentes El tiempo que transcurre desde que se produce un accidente hasta el momento en que la víctima es localizada y atendida, es fundamental para que la intervención de los servicios de socorro tenga éxito. Por ello, es importante reducir este tiempo el máximo posible con el fin de minimizar las consecuencias del accidente en los heridos. Una de las formas de reducir este tiempo de respuesta es mediante el uso de los sistemas ACN (Automatic Crash Notification). Estos sistemas son capaces de detectar cuando se 7 https://www.cerberusapp.com/ 16 2. A NTECEDENTES produce un accidente y de alertar al personal de emergencia de dicho accidente. Uno de los sistemas ACN más famosos es OnStar. En [LPFF08] se realiza un estudio sobre como los ACN pueden ayudar a reducir la mortalidad en accidentes de tráfico. OnStar [OnS] es un sistema ACN perteneciente a la empresa americana General Motors LLC. Este sistema proporciona servicios como respuesta automática ante choques, navegación y asistencia en carretera. Su sistema de respuesta automática ante choques consta de una serie de sensores colocados en el vehículo que permiten detectar un choque y alertar a un centro de asesoramiento. A continuación si el usuario solicita ayuda o no contesta se le enviará un equipo de emergencias a su localización calculada mediante GPS. Además, el vehículo puede transmitir información importante sobre la colisión, como la dirección y el número de impactos, o el estado de vuelco del vehículo. Aunque OnStar es uno de los sistemas más destacados, existen otros sistemas similares, que incluyen ACN. Podemos nombrar algunos como Mercedes-Benz Tele Aid, Ford’s VEMS/RESCU system y BMW Assist. Recientemente, la Comisión Europea8 ha propuesto hacer obligatoria la incorporación del sistema eCall, a partir del 2015, en todos los vehículos de fabricación nueva. El comunicado de prensa puede verse en [Eur13]. El sistema eCall supone una alternativa en Europa al sistema OnStar mostrado anteriormente. Básicamente su funcionamiento es el mismo, salvo que eCall viene programado para realizar un llamada al número de emergencia europeo 112 en caso de accidente. Esta llamada también puede ser realizada manualmente con un botón que incorpora y que podría ser pulsado por un testigo del accidente [Eura]. En la imagen de la figura 2.4 podemos ver un esquema de su funcionamiento. 2.8.1 Detección automática de accidentes basada en smartphone Los sistemas ACN como OnStar presentan el inconveniente de no estar disponibles en todos los coches, además de ser caros de equipar en vehículos antiguos. Sin embargo, los smartphone gracias a la amplia variedad de sensores que incorporan (acelerómetro, GPS, etc.), nos brindan la oportunidad de crear sistemas capaces de detectar un accidente e informar de forma rápida a los servicios sanitarios. Además permiten mantener una conexión persistente a Internet lo que les permite transmitir datos de forma continua para informar de cualquier problema que se detecte. La figura 2.5 nos muestra el funcionamiento de este tipo de sistemas. Como se observa en la figura, se distinguen tres acciones básicas realizadas por el sistema: 1. Mediante los sensores del smartphone se detecta un posible accidente de trafico. 2. Mediante una conexión de datos 3G el teléfono transmite la información relativa al accidente a un servidor. 8 http://ec.europa.eu/index es.htm 17 2. A NTECEDENTES Figura 2.4: Esquema de funcionamiento de eCall (European Commision [Eurb]) 3. El servidor procesa la información del accidente y realiza las acciones que considere oportunas. Los sistemas de detección automática de accidentes basados en smartphone presentan importantes ventajas con respecto a los basados en vehículo, como son el acceso a la tecnología o el precio de ésta, sin embargo presentan la desventaja de los falsos positivos. El problema de los falsos positivos rara vez aparece en sistemas basados en vehículo, ya que estos cuentan con sensores capaces de detectar los daños físicos en el vehículo, o la activación de mecanismos de emergencia en el coche, como por ejemplo el airbag. Por otro lado podemos contrarrestar el efecto de los falsos positivos haciendo uso de información adicional, como señales acústicas antes y después del accidente o las fuerzas de aceleración registradas. A continuación se muestran las principales ventajas que podemos encontrar en los sistemas basados en smartphone con respecto a los sistemas de abordo instalados en los vehículos [WTT+ 11]: Pueden medir de una forma más precisa las fuerzas experimentadas por las víctimas, ya que el dispositivo suele estar situado en su bolsillo. 18 2. A NTECEDENTES Figura 2.5: Estructura de un sistemas de detección de accidentes basado en Smartphone (WreckWatch [WTT+ 11]) El coste de un smartphone es relativamente bajo, y su uso esta muy extendido. Se evita tener que instalar hardware adicional en el vehículo. Reducción de la complejidad del software de mantenimiento. Posibilidad de ampliar capacidades de procesamiento y almacenamiento a través de servicios basados en cloud. Por otro lado, los sistemas basados en smartphone presentan varias desventajas a tener en cuenta: Consumen una cantidad significativa de batería. La fuerza de impacto captada por el smartphone se ve reducida por los sistemas de seguridad del vehículo. Una avería en el teléfono ocasionada por un impacto puede impedir la notificación del accidente. El software de los sensores está controlado por el SO del smartphone. Esto quiere decir que una actualización en dicho software podría dejar obsoleta la detección de accidentes. Las pruebas de calidad se hacen difíciles debido a los falsos positivos. 19 2. A NTECEDENTES 2.8.2 WreckWatch WreckWatch [WTT+ 11] es un sistema de detección automática de accidentes de tráfico basado en smartphone. El sistema graba todos los datos posibles referentes a los sucesos que podrían originar un accidente. En concreto realiza un registro de la trayectoria, velocidad y fuerzas de aceleración sobre un vehículo que está siendo conducido y durante un accidente. El sistema también es capaz de alertar a los servicios de emergencia de un accidente, añadiendo imágenes y vídeos realizados por testigos que se encuentren en el lugar del suceso. Arquitectura El sistema presenta una arquitectura C/S, donde el cliente ha sido desarrollado para su ejecución en entornos Android. La información se transmite del cliente al servidor mediante operaciones estándar HTTP POST (ver figura 2.6). Figura 2.6: Diagrama de arquitectura de WreckWatch [WTT+ 11] El cliente se compone de una serie de Activities (ver sección 2.3.1) para la cartografía, pruebas y carga de imágenes. También presenta servicios en segundo plano para la detección de accidentes mediante la consulta constante de los sensores del sistema, como el acelerómetro o el GPS. La aplicación permite modificar la frecuencia de rastreo de los sensores, con el fin de reducir los consumos de batería, y la recopilación de datos del teléfono, para obtener información de interés, como los contactos que se deben avisar en caso de emergencia. El servidor esta desarrollado utilizando Java/MySQL con Jetty y Spring Framework. Proporciona un servicio de recogida de datos, y un mecanismo para la comunicación con los servicios de emergencia y familiares de la víctima. Permite a los sistemas clientes el en- 20 2. A NTECEDENTES 21 vío de características del accidente y presenta varias interfaces, como un mapa de Google y servicios web XML/JSON, para acceder a esta información. Modelo formal de detección de accidente En la creación de un modelo formal de detección de accidentes basado en smartphone, con una precisión aceptable, es importante hacer frente a dos problemas importantes: Detectar el accidente sin la medición directa de datos de impacto de sensores de a bordo instalados en el vehículo. Examinar la posibilidad de falsos positivos. Para hacer frente a estos problemas el sistema WreckWatch realiza un muestreo continuo de varios sensores, atendiendo a unos umbrales de filtrado que pretenden predecir cuando sucede un accidente. El modelo empleado por el sistema para explorar el estado del vehículo es el siguiente: γ =< φ, Tφ , ρ, Tρ , β, , Sφ , Sρ , Sβ , Mφ , Mρ , Mβ , M > (2.1) Donde: φ: variable de aceleración que indica la aceleración máxima registrada por el teléfono en cualquier dirección. Sφ : lapso de tiempo desde que un evento de aceleración establece un valor para φ hasta que la variable es reiniciada. ρ: variable binaria de evento de sonido que indica si un evento de sonido mayor que Mρ dBs se ha producido. Mediante un estudio se ha establecido que 140dBs es un buen valor para Mρ . Sρ : lapso de tiempo que se mantendrá a nivel 1 la variable ρ después de registrar un evento de sonido superior a Mρ dBs. β: variable de velocidad umbral que toma valor uno si el vehículo ha estado viajando a más de M βmph. Sβ : lapso de tiempo que se mantendrá el valor 1 para la variable β después de que el vehículo deje de viajar por encima de Mβ mph. : distancia recorrida desde la última vez que la variable β cambiará de 1 a 0. Mφ : aceleración mínima en Gs para que un solo evento de aceleración active la detección de accidentes. 2. A NTECEDENTES 22 Mρ : decibelios mínimos requeridos para que un evento acústico active la variable ρ. Mβ : velocidad mínima, en millas por hora, que el dispositivo debe detectar para activar el sistema de detección de accidentes. M : distancia máxima en metros que el dispositivo puede desplazarse a una velocidad más baja que Mβ , antes de que el sistema de detección de accidentes sea desactivado. La función de detección de accidente evalúa a 1 si un accidente es detectado o 0 en caso contrario. Ev : γ → {0, 1} (2.2) La detección de accidente se establece de la siguiente forma: Ev(γ) = 1 + αρ ≥ MT r ∧ (β == 1) si( < M ) ∧ Mφφ + αρ ≥ MT r 0 en otros casos 1 si φ Mφ (2.3) Donde: α: es un factor ajustable que se aplica al evento de sonido para indicar su importancia en la detección del accidente. MT r : es el umbral para la detección del accidente. Como se abstrae de la fórmula, el sistema reconocerá un accidente mediante dos posibles escenarios: en el primero, el sistema registra un evento de aceleración y sonido con una escala alta mientras el vehículo se esta moviendo con una velocidad superior a Mβ , y en el segundo se produce una aceleración y un evento de sonido habiendo recorrido una distancia inferior a M desde la última vez que se activó Mβ , con este escenario se intenta detectar si el vehículo es golpeado mientras esta detenido. Evaluación de falsos positivos WreckWatch basa su sistema de detección de accidentes en mediciones de aceleración y sonidos, por lo que se enfrenta a falsos positivos derivados de ambas mediciones. En esta sección mostraremos los casos que se consideraron como causantes de falsos positivos en la creación de este sistema y los análisis realizados para determinar su importancia. 2. A NTECEDENTES En cuanto a los casos que provocan falsos positivos relacionados con los valores del acelerómetro, los casos considerados son: la caída accidental del smartphone dentro del vehículo, o la realización de una frenada de emergencia que no de lugar a accidente. Los resultados obtenidos de los ensayos realizados por WreckWatch se muestran en la figura 2.7. Como se observa, en ninguno de los dos casos se sobrepasa el umbral establecido de 4G por lo que se considera poco probable que estas situaciones den lugar a un falso positivo. Figura 2.7: Aceleración registrada durante una caída y una frenada brusca [WTT+ 11] Por otro lado, se consideraron seis casos que podrían causar falsos positivos relacionados con la medición de sonido, entre los que se tenían en cuenta la radio, el ruido de los ocupantes del vehículo o el de la carretera. Este estudio demostró que el smartphone no era capaz de detectar niveles de sonido superiores a 145 dB por lo que la medición de los niveles de sonido podría dar lugar a la aparición de falsos positivos. Sin embargo, esta medida nos es útil para mejorar la percepción de accidentes, ya que si se registra una aceleración que se encuentre ligeramente por debajo del umbral, pero que presentan niveles altos en la percepción de sonido, podríamos tratar el caso también como un accidente. 23 Capítulo 3 Objetivos E n esta sección se mostrarán los objetivos tanto principales como específicos que se persiguen con la realización de este proyecto, con el fin de dar a conocer al lector el alcance al que se pretende llegar con la realización del mismo. 3.1 Objetivo general El objetivo principal de L O RAM es la creación de un sistema capaz de detectar posibles accidentes de motocicleta e informar de dichos accidentes. Además pondrá los medios necesarios para la localización de la posible víctima y facilitará una serie de mecanismos de interación que permitan recabar la mayor cantidad de información posible para conocer la posición y el estado en el que se encuentra dicha víctima. A partir de este objetivo principal se definen una serie de subobjetivos funcionales específicos que serán detallados a continuación. 3.2 Objetivos específicos En este apartado se mostrarán los distintos objetivos específicos que han sido marcados para el desarrollo de L O RAM. 3.2.1 Detección del accidente Este objetivo nos indica que el sistema debe ser capaz de detectar un accidente de motocicleta con un grado de exactitud razonable. Para cumplirlo, el sistema solo podrá hacer uso de las tecnologías existentes en el smartphone de la víctima, por lo que utilizará sensores como el acelerómetro, medición de niveles de sonido u otros mecanismos que le permitan detectar una posible colisión o caída. La detección del accidente presenta el problema de los falsos positivos, por lo que habrá que lidiar con ellos para obtener buenos resultados en el cumplimiento de este objetivo. 24 3. O BJETIVOS 3.2.2 Notificación de incidentes Los incidentes detectados por el sistema, deberán ser notificados a una entidad externa al smartphone de la víctima para su almacenamiento, y posterior tratamiento por el personal de emergencia, con el fin de comprobarlos y ofrecer asistencia, en caso de que sea necesaria. La notificación de estos incidentes se llevará a cabo mediante el uso de una arquitectura de eventos, en la que el smartphone de la víctima es visto como el publicador de esta comunicación y la entidad externa que gestiona las incidencias como el subscriptor. 3.2.3 Asistencia Remota El sistema deberá estar dotado de un módulo RC que permita la manipulación remota de una serie de actuadores localizados en el smartphone de la víctima (altavoz, vibrador, luz, ...) con el fin de poder comprobar el estado en el que se encuentra y facilitar su localización in situ. Este mecanismo se hace necesario, ya que en algunas ocasiones la víctima de un accidente de motocicleta queda desplazada del lugar del accidente, y esto dificulta su localización. Por otro lado, deberá existir un módulo de rescate, que contará con un panel de control, para manipular de forma remota los actuadores soportados por smartphone de la víctima. Este panel permitirá al personal de emergencias activar y desactivar estos actuadores, así como modificar ciertos parámetros de estos, como el volumen de sonido o frecuencia de vibración, por poner algún ejemplo. 3.2.4 Localización de la víctima Este objetivo, nos indica que deberemos contar con los mecanismos apropiados, para poder determinar la localización precisa de la víctima. Para la realización de este cometido, se deberá hacer uso exclusivo de los mecanismos presentes en un smartphone corriente. Ya que será necesaria una localización bastante precisa y orientada a exteriores, lo más factible será usar una localización basada en satélite, como GPS. Además, el hecho de que en la mayoría de los casos, sea necesario realizar la localización en puntos interurbanos, refuerza esta decisión, ya que otras tecnologías, como GSM, están más orientadas a núcleos urbanos. 3.2.5 Gestión de datos de incidentes Deberemos contar con los medios adecuados para recoger y almacenar las incidencias que se produzcan, de forma que posteriormente sea posible una explotación y consulta de estos datos de forma sencilla. Este objetivo, pone de manifiesto la importancia de almacenar la mayor cantidad de datos posibles con relación a un incidente, como la fecha y hora exacta o las posibles causas del mismo, haciendo uso de las estructuras apropiadas, para que su consulta sea rápida y eficiente. Así, el uso de una BD será bastante apropiado para el cumplimiento de este objetivo. 25 3. O BJETIVOS 3.2.6 Basado en smartphone Debido a la gran movilidad que se precisa para el correcto funcionamiento del sistema, y con el fin de reducir costes en la realización del mismo, se marca como objetivo la implementación de la aplicación del usuario y la del personal de los servicios de emergencia sobre plataformas móviles, como tablet o smartphone. Actualmente, los smartphone presentan una gran variedad de tecnologías, como sensores, sistemas de localización, conexiones inalámbricas, etc, lo que los hace atractivos para la realización de este sistema. Además, el acceso a este tipo de dispositivos es asequible, por lo que están ampliamente extendidos entre la población. 3.2.7 Estándares libres El desarrollo del sistema se realizará haciendo uso de estándares y software libre. Con este objetivo, se pretende facilitar la adaptación a otras plataformas, u otros sistemas que pudieran trabajar en colaboración con este. Además de este modo se facilitan las posibles expansiones futuras, así como adaptaciones a nuevas versiones del SO Android. 26 Capítulo 4 Método de trabajo E n este capítulo se explicará al lector la metodología de desarrollo empleada para la realización de este proyecto. Se mostrarán también las herramientas, tanto hardware como software, utilizadas en la realización del mismo. 4.1 Metodología de trabajo La realización de este proyecto suponía hacer frente a una serie de dificultades durante su desarrollo, ya que los requisitos del sistema no estaban del todo claros al inicio, podían ser cambiantes y a pesar de tener una idea clara de lo que se pretendía hacer, se suponía imposible prever todos los requisitos inicialmente. Todo ello dificultaba realizar un cálculo a priori del alcance del proyecto, por lo que se optó por hacer uso de una metodología ágil. La metodología de desarrollo finalmente escogida para la realización de L O RAM ha sido XP (eXtreme Programming), ya que hace especial énfasis en la adaptabilidad a los cambios durante la fase de análisis y desarrollo. 4.1.1 Extreme Programming [Bec02] es una metodología ágil de desarrollo de software creada por Kent Beck. Esta metodología tiene como objetivo entregar al cliente el software que necesita en el momento que lo necesita, respondiendo a los requerimientos cambiantes de los clientes incluso en las fases finales del ciclo de vida del desarrollo. Otro objetivo que presenta XP es potenciar el trabajo en equipo, de modo que tanto los clientes como los jefes de proyecto y desarrolladores, estén involucrados en el desarrollo. XP La metodología XP define cuatro variables para los proyectos de software: costo, tiempo, calidad y ámbito. De estas cuatro variables solo tres de ellas podrán ser establecidas por actores externos al grupo de desarrollo, mientras que la cuarta deberá ser establecida por el equipo de desarrollo, en función del valor de las anteriores. se basa en una serie de valores que deben ser maximizados en todo proyecto para alcanzar el éxito [Welb]. XP 27 4. M ÉTODO DE TRABAJO 28 Simplicidad: Se debe realizar de la forma más sencilla posible únicamente lo que se nos pide. Se irán dando pequeños pasos hacia los objetivos marcados, corrigiendo los fallos que vayan apareciendo sobre la marcha. Comunicación: La comunicación entre todas las partes es importante durante todo el proceso para evitar errores en el desarrollo. Retroalimentación: Se realizan iteraciones cortas en las que se presenta un software funcional al cliente. De este modo se minimizan los problemas derivados de errores en la comprensión de los requisitos. Honestidad: Ser honestos sobre las estimaciones y afrontar los problemas que se presenten sin miedo a desechar trabajo realizado. Con el fin de maximizar estos valores, XP establece una serie de reglas y prácticas que deben ser realizadas. Estas reglas pueden ser agrupadas en cinco tipos [Wela]: Planificación, gestión, diseño, codificación y pruebas. En la figura 4.1 podemos ver un modelo visual de los procesos que intervienen en XP. Figura 4.1: Modelo de proceso de XP A continuación se muestran en detalle las reglas y prácticas indicadas por XP según la división anteriormente citada. Planificación. Se comienza recopilando «historias de usuario» para describir la funcionalidad del software. A continuación el usuario asigna una prioridad a cada «historia de usuario» y el equipo de desarrollo evalúa el tiempo que será necesario para la realización de cada una. El proyecto se divide en iteraciones y se planifica el comienzo de cada una de las iteraciones. Gestión. Se asigna al equipo un espacio de trabajo y se establece un ritmo sostenido. Se realiza una reunión entre los miembros al inicio de cada día para medir la velocidad en la que avanza el proyecto, y poder compartir problemas y soluciones que vallan surgiendo. Diseño. Se hace especial hincapié en la simplicidad y en la utilización de metáforas con el fin de facilitar la comprensión rápida del código, por ello se utilizan nombres claros 4. M ÉTODO DE TRABAJO y descriptivos que no requieran de documentación extra. Para reducir riesgos se crean soluciones «spike» y se utiliza la recodificación (refactoring) siempre que sea posible. Codificación. La disponibilidad del cliente es requerida durante todo el proyecto, por lo que se necesita que pase a formar parte del grupo. Se hace uso de estándares y se realiza una programación dirigida por las pruebas (ver sección 4.1.2). También se establece una programación por pares, es decir, dos personas trabajan juntas en el mismo ordenador con el fin de evitar errores. Además, estos grupos tendrán libertad para cambiar el código que sea necesario, ya que se establece una propiedad colectiva del código. Las integraciones se realizan a menudo, aunque solo una pareja puede realizar integraciones a la vez. Pruebas. Las pruebas son uno de los conceptos más importantes en XP. Para cada módulo deben existir sus correspondientes pruebas unitarias, que deberán ser pasadas en su totalidad antes de la publicación de dicho módulo. Para la corrección de errores se deberán escribir pruebas que permitan verificar que el error ha sido resuelto. Finalmente se deberán realizar pruebas de aceptación en base a las historias de usuario, y serán los usuarios los encargados de verificar que los resultados de dichas pruebas son los esperados. 4.1.2 Test Driven Development La metodología XP incluye como técnica de diseño e implementación TDD (Test Driven Development) [BBG+ 10]. Uno de los objetivos principales que se persigue al diseñar software con esta técnica, es la de implementar solo las funciones exactas que el cliente precisa y ninguna más, de este modo se evita desarrollar funcionalidades que nunca serán usadas. Otro objetivo que se presenta, es la minimización del número de defectos que llegan en la fase de producción al software. Además se propone una producción de software modular que este preparada para el cambio y sea altamente reutilizable. La utilización correcta de TDD como técnica de diseño conlleva la aplicación del algoritmo TDD, que consiste en la realización de los tres siguientes pasos: Escribir el test o especificación del requisito. Implementar el código adecuado según ese test. Refactorizar para hacer mejoras y eliminar duplicidad. El primero de este pasos consiste en expresar en forma de código el requisito. De este modo podemos entender inicialmente un test como un ejemplo o especificación. Para escribir el test debemos pensar primero en un comportamiento del SUT (Subject Under Test) bien definido y en como comprobaríamos que, efectivamente, hace lo que le pedimos. Una vez tenemos el ejemplo escrito, debemos escribir únicamente el código necesario para que el test sea pasado con éxito. Durante esta tarea nos surgirán dudas sobre distintos 29 4. M ÉTODO DE TRABAJO comportamiento del SUT ante distintas entradas, pero debemos contener el impulso inicial de codificarlas sobre la marcha, y limitarnos a anotar esas dudas para futuras especificaciones. La refactorización consiste en modificar el diseño de modo que el comportamiento permanezca intacto. Para ello, revisamos el código, incluido el de los test, en busca de líneas duplicadas y prestando atención en que se cumplan los principios de diseño establecidos. Con todo esto aplicamos la refactorización oportuna. 4.2 Herramientas En este apartado se mostrarán las distintas herramientas, tanto hardware como software, que han intervenido en la elaboración de L O RAM. 4.2.1 Lenguajes Para la elaboración de este proyecto ha sido necesaria la utilización de varios lenguajes de programación. A continuación se muestra la lista completa de todos ellos: Java Lenguaje de programación orientado a objetos, desarrollado por Sun Microsystems (actualmente propiedad de Oracle Corporation1 ). Este lenguaje se utiliza para el desarrollo de los módulos de la aplicación que se ejecutan bajo Android debido a la alta integración que existe entre este SO y Java. Python Lenguaje de programación interpretado, desarrollado por Guido van Rossum [Foua]. Este lenguaje se usa para el código del módulo de gestión y para la implementación de los test de sistema. Slice Lenguaje similar a C creado por ZeroC para definir las interfaces de los objetos y poder separar estas de la implementación de dichos objetos. 4.2.2 Hardware Para el desarrollo de L O RAM se ha empleado un equipo de sobremesa, usado principalmente para la realización del código de la aplicación y los test. Este equipo cuenta con las siguientes características: R Intel CoreTM 2 Quad CPU Q6600(2.40GHz x 4). 6GB RAM. 1TB Disco Duro. 1 http://www.oracle.com 30 4. M ÉTODO DE TRABAJO También ha sido necesaria la utilización de un smartphone para realizar algunas pruebas sobre la plataforma de destino de algún módulo de la aplicación. Las características del smartphone usado son las siguientes: HTC Desire. Qualcomm Snapdragon QSD8250 1GHz. 576MB RAM. 512MB ROM, microSD 4GB. GPS, acelerómetro, Wi-Fi(802.11b/g), Bluetooth 2.1. Versión de Android 2.2.2 Froyo. 4.2.3 Software En el desarrollo de este proyecto han intervenido diferentes herramientas y bibliotecas software. A continuación se detallarán todas ellas, explicando brevemente para que han sido utilizadas. Sistema operativo: Debian Se ha empleado Debian 7.0 (wheezy) 64-bit con núcleo Linux 3.0.0-1-amd64, instalado en el equipo de sobremesa indicado en la sección 4.2.2, como SO principal para la realización de este proyecto. Android El SO empleado en el smartphone ha sido Android 2.2.2 (Froyo) por ser la ultima versión actualizada por HTC para este dispositivo. Software de desarrollo: GNU Emacs Editor de texto extensible perteneciente al proyecto GNU [Sta]. Este editor se ha usado como IDE para la programación en Python de los test y del módulo de gestión. También ha sido usado para redactar la documentación del proyecto. La versión usada ha sido GNU Emacs 23.4.1. Eclipse multiplataforma empleado para el desarrollo de los módulos de la aplicación que se ejecutan en Android [Foub]. La versión utilizada ha sido 3.7.2 (Indigo), a la que se le han añadido los plugins ADT Plugin y Slice2Java para la integración con Android y I CE respectivamente. IDE ZeroC Ice Middleware de comunicación orientado a objetos creado por ZeroC Inc [Zerb]. Se ha 31 4. M ÉTODO DE TRABAJO utilizado I CE para realizar la comunicación entre los distintos módulos de la aplicación. La versión usada ha sido la 3.4. Android SDK Kit de desarrollo de software para Android [Andb]. Nos ha permitido desarrollar los módulos de la aplicación para Android, así como depurarlos y probarlos en un emulador. Se ha empleado la versión 21 de este Software Development Kit (SDK). JUNIT Framework integrado en Eclipse para la realización de test en Java [jt]. Se ha empleado para realizar los test unitarios de los módulos implementados para Android. La versión empleada ha sido JUNIT 4. Nose Herramienta para facilitar la realización de pruebas en Python [Nos]. La versión usada ha sido la 1.1.2. python-doublex Framework de dobles de prueba para python creado por David Villa [Vil]. Se ha utilizado para la realización de los test unitarios e integración que verifican el comportamiento del sistema. Mockito Framework de dobles de prueba para Java [Kac]. Se ha utilizado, junto con Junit, para la realización de las pruebas unitarias, de los componentes del sistema implementados para Android. La versión empleada ha sido la 1.9. Documentación y gráficos: LATEX Lenguaje de marcado para la composición de documentos de texto [CLM+ 03]. Se ha utilizado para realizar esta memoria. BibTeX Herramienta para dar formato a listas de referencias en documentos escritos en LATEX. Usado para crear las referencias de este documento. Dia Programa para dibujar diagramas estructurados. Se ha utilizado en su versión 0.97.2 para crear los diagramas que aparecen en algunas figuras de este documento. Gimp Programa de manipulación de imágenes de GNU. Usado en su versión 2.8 para crear los gráficos que aparecen en algunas de las figuras de este proyecto. 32 4. M ÉTODO DE TRABAJO Control de versiones: Mercurial Sistema de control de versiones distribuido [O’S]. Este sistema ha sido usado junto a un repositorio que se encuentra en el servidor de alojamiento Bitbucket2 . 2 https://bitbucket.org/ 33 Capítulo 5 Arquitectura y Desarrollo E ste capítulo mostrará la arquitectura que presenta el sistema L O RAM. Primero se comenzará explicando a grandes rasgos la estructura del sistema, para posteriormente profundizar en cada una de los módulos que lo forman, aplicando un enfoque descriptivo basado en una aproximación top-down. Después de mostrar como está dividido el sistema y de detallar cada una de sus partes, se definirán los requisitos funcionales, así como las distintas iteraciones que se han llevado a cabo para obtener cada uno de los prototipos. 5.1 Visión general La visión general del sistema atiende primeramente a su distribución, ya que se trata de un sistema distribuido, que se encuentra dividido en tres componentes, cada uno de ellos pensado para su ejecución sobre un tipo de plataforma específico. Los tres componentes distribuidos en los que se divide el sistema son los siguientes: Aplicación de usuario. Aplicación del sistema de gestión Aplicación del servicio de emergencias La visión general de la estructuración de L O RAM la podemos ver en la figura 5.1. Como se observa en la figura cada una de estas partes esta dividida a su vez en varios módulos. Por un lado la Aplicación de usuario es la parte del sistema creada para interactuar con el usuario. Esta parte está pensada para trabajar sobre una plataforma tipo smartphone, por ello se diseñó para explotar los recursos que facilita dicha plataforma. En esta parte encontramos dos módulos del sistema, uno de ellos destinado a la detección de los posibles accidentes (ver sección 5.1.1) y otro módulo RC (ver sección 5.1.2) que permite la interacción con el dispositivo para conocer el estado de algún sensor o permitir la activación de un actuador. Estos módulos al igual que el resto de módulos de la aplicación se mostrarán en detalle mas adelante. Por otro lado, tenemos la parte de la aplicación destinada a ser usada por los servicios de emergencia. La plataforma para la cual está pensada la ejecución de esta parte es de tipo 34 5. A RQUITECTURA Y D ESARROLLO Figura 5.1: Estructura esquematizada de L O RAM tablet o smartphone. Esta parte presenta también dos módulos, uno para conocer la existencia de incidentes producidos (ver sección 5.1.5) y otro para poder interactuar con el dispositivo de la víctima y de este modo hacer más sencilla su localización (ver sección 5.1.6). En el centro de la comunicación entre estas dos partes se encuentra el sistema de gestión. Esta parte del sistema está pensada para su ejecución en un PC, preferiblemente de tipo servidor, con capacidad para explotar bases de datos. Esta parte consta de dos módulos, uno encargado de recibir los posibles incidentes y almacenarlos debidamente (ver sección 5.1.3) y otro que permite la interacción con un usuario que ha informado de incidente (ver sección 5.1.4). Además, el primero de estos módulos aceptará peticiones de los servidores de emergencias para comprobar los incidentes provocados. Para facilitar la comprensión del proceso de comunicación entre módulos puede verse el diagrama de secuencia de la figura 5.2. En este diagrama se representa una detección de accidente, y se solicita al smartphone de la víctima la activación del altavoz, y posteriormente su desactivación. Se considera que la valoración de petición que realiza el módulo de control de acceso remoto se evalúa como positiva. A continuación pasamos a mostrar más detalladamente cada uno de estos módulos, profundizando en la funcionalidad que aportan al sistema. 5.1.1 Módulo de Detección Para comenzar hablaremos del módulo de detección de accidentes. Como se observa en la figura 5.1 este módulo pertenece a la Aplicación de usuario, es decir, se ejecutará en el smartphone del usuario al que pretendemos dar asistencia, y que por consiguiente estará en ejecución durante el transcurso del viaje. 35 5. A RQUITECTURA Y D ESARROLLO Figura 5.2: Diagrama de secuencia que representa la comunicación entre módulos La funcionalidad principal de este módulo es la de detectar posibles incidentes que se produzcan durante la conducción, como colisiones o caídas, e informar debidamente de ellas para que puedan ser comprobadas. El módulo, al estar ubicado en el smartphone, hace uso de los sensores de que dispone este para realizar su cometido. Inicialmente el usuario arranca la aplicación con este módulo desconectado, y será cuando el usuario advierta de que se encuentra en ruta cuando entre en funcionamiento. Al activarse el módulo se registra un «listener» para el acelerómetro del teléfono, de modo que cada vez que se produzca un cambio en algún valor de los tres ejes de coordenadas (x, y, z) este sea recogido y analizado. 5.1.2 Módulo de RC El siguiente módulo que analizaremos será el módulo de RC. Este módulo a igual que el anterior se ejecuta en el smartphone del usuario al que proporcionamos asistencia durante el viaje. El objetivo principal que se persigue con este módulo es el de poder controlar remotamente ciertos aspectos del teléfono del usuario, como activar el altavoz para que reproduzca un sonido, encender la luz de la cámara trasera o el vibrador. Además este módulo nos permite conocer el estado de ciertos sensores, como el nivel de batería para que sea tenido en cuenta por el sistema, así como la ubicación en que se encuentra según el sistema de posicionamiento GPS. 36 5. A RQUITECTURA Y D ESARROLLO Cuando el sistema de detección capta un posible incidente y avisa de él, a su vez pone en funcionamiento este módulo con el fin de que sea posible la interacción y localización de la víctima. 5.1.3 Módulo de Gestión de incidentes El módulo de gestión de incidentes lo podemos encontrar en la parte del sistema que hemos nombrado anteriormente como Aplicación del sistema de gestión. Como ya se anticipó, este módulo está pensado para su ejecución en una plataforma tipo PC, que deberá ser capaz de recibir y procesar varias peticiones de forma simultánea. Con la ejecución de este módulo se consigue gestionar y almacenar de forma eficiente todos los incidentes de que informan los distintos usuarios, recogiendo datos relevantes de cada uno de ellos. También recibe las peticiones de los servicios de emergencias en la que solicitan conocer los incidentes que tiene registrados, y permite la asignación de un determinado incidente a un componente del servicio de emergencias. La gestión de incidentes se encuentra en constante funcionamiento, preparada para recibir en cualquier momento un incidente. Cuando esto se produce, el incidente es recogido y almacenado en una BD gestionada por un SGBD (Sistema Gestor de Bases de Datos) MySQL. 5.1.4 Módulo de control de acceso remoto Al igual que el módulo anterior, se encuentra en el sistema de gestión. Su objetivo consiste en comprobar el estado en el que se encuentra el dispositivo que ha informado de un incidente y atendiendo a esto, filtrar las peticiones de acceso remoto que soliciten los servicios de emergencia para este dispositivo, es decir, actúa como intermediario de la comunicación entre el dispositivo del usuario y los servicios de emergencia. Para que se entienda más claramente, pensemos en una situación en la que el smartphone que ha indicado un incidente se encuentra al 25 % de su nivel de batería, y los servicios de emergencia solicitan la activación del vibrador y la posición GPS, este módulo podría decidir que solo se realizará la solicitud de posición, con el fin de preservar la batería del dispositivo. El módulo de control de acceso remoto actúa como un servicio, que permanece a la espera de alguna solicitud. Cuando un programa de servidor de emergencias solicita la interacción con algún componente del smartphone del usuario, este módulo comprueba en su BD si dicho usuario ha indicado algún incidente recientemente, y comprueba que exista una asociación entre este usuario y el servicio de emergencias solicitante. En tal caso, realiza una consulta al dispositivo interrogándolo para conocer que mecanismos tiene disponibles, y su estado de batería. Una vez que tiene esta información, aplica un filtro a las solicitudes del servicio de emergencia con el fin de preservar el estado de la batería del teléfono. 37 5. A RQUITECTURA Y D ESARROLLO 5.1.5 Módulo de Consulta Este módulo pertenece a la parte del sistema dedicada al uso de los servicios de emergencias. Tiene como finalidad permitir a los servicios de emergencia consultar los incidentes que son notificados al módulo de gestión de incidentes. Cuando un usuario de los servicios de emergencia ejecuta la aplicación, este módulo realiza una petición al servidor de gestión para obtener la lista de incidentes producidos. Dicha lista será cargada en pantalla, y el usuario de los servicios de emergencia podrá indicar mediante pulsación en la lista que incidente desea atender. 5.1.6 Módulo de Rescate Al igual que el módulo de consulta, este módulo se encuentra en la Aplicación del servicio de emergencias. Ya que su uso es necesario en el lugar del accidente, está pensado para una plataforma tipo smartphone o tablet, dada la gran movilidad que se requiere. El objetivo de este módulo es el de facilitar el rescate de la víctima, aportando la mayor cantidad posible de información sobre su estado y localización. Además, si es posible, nos permitirá la comunicación con dicha víctima, de modo que nos pueda aportar algún dato extra referente a su estado o localización. Después de que el usuario de los servicios de emergencia seleccione el incidente que desea atender, se le cargará este módulo. El módulo consta de un panel con una serie de controles que permiten la activación de diferentes actuadores en el teléfono (luz, vibrador, altavoz, ...). Cada uno de estos actuadores cuenta con unos elementos reguladores que permiten modificar su comportamiento, como por ejemplo modificar el volumen del altavoz. Este panel también cuenta con unos elementos de visualización que nos permiten conocer alguna información relevante, como los datos personales de la víctima, los números a avisar en caso de accidente o información resultado de la activación de un control, como por ejemplo la localización GPS. 5.2 Requisitos En esta sección se listarán los requisitos tanto funcionales como no funcionales recogidos para el desarrollo del sistema objeto del presente proyecto. Para cada uno de estos requisitos se indicará su descripción y una prioridad que distinguirá entre requisito obligatorio o requisito deseable según corresponda. Además se justificará de forma breve porqué se considera de una prioridad u otra. 5.2.1 Requisitos funcionales En este apartado se van a definir los requisitos funcionales, numerando cada uno de ellos para que sea más fácil una gestión de los mismos. 38 5. A RQUITECTURA Y D ESARROLLO Requisito funcional 1. El usuario deberá registrarse para hacer uso del sistema, indicando sus datos personales, así como su número de teléfono y el número que deberá ser avisado en caso de emergencia. Este requisito se establece como obligatorio, ya que sin la realización de este registro el usuario no podrá acceder al sistema. Además, los datos del registro serán muy útiles en el caso de una emergencia. Requisito funcional 2. Los servicios de emergencias deberán, también, registrarse en el sistema. Este requisito es obligatorio, ya que sin él, los servicios de emergencia no podrán acceder a su parte correspondiente del sistema, y no se podrá tener un control sobre los servicios de emergencias con los que cuenta el sistema para realizar los rescates. Requisito funcional 3. Los usuarios registrados en el sistema podrán «loguearse»1 mediante el uso de un correo electrónico y una contraseña. Se trata de requisito obligatorio, ya que controla el acceso al sistema. Requisito funcional 4. El personal de los servicios de emergencias registrados en el sistema podrán «loguearse» mediante el uso de un identificador único y una contraseña. Este requisito, también se considera como obligatorio, ya que controla los accesos a la parte del sistema destinada a los servicios de emergencia, evitando el uso inapropiado del sistema. Requisito funcional 5. Tanto los usuarios como el personal de los servicios de emergencia podrán abandonar el sistema, mediante un cierre de sesión. Se considera un requisito obligatorio, ya que se debe poder abandonar la sesión siempre que se quiera para evitar que una persona haga uso de la sesión de otra sin su consentimiento. Requisito funcional 6. El sistema permitirá al usuario poder ver los datos que introdujo en su registro. La prioridad de este requisito funcional es deseable, ya que no interfiere en el funcionamiento normal del sistema. Requisito funcional 7. Se permitirá, al usuario, modificar los datos introducidos en su registro al sistema. Este requisito se considera deseable, ya que si bien no juega un papel fundamental en el funcionamiento básico del sistema, si que resulta útil contemplar la posibilidad de que el usuario tenga que modificar algún dato, bien sea por que cometió un error en el registro, o por que dicho dato necesita ser actualizado. Requisito funcional 8. El sistema debe ser capaz de detectar un accidente con un margen de error aceptable. Consideramos que se trata de un requisito obligatorio, ya que este requisito define una de las características más importantes de todo el sistema. Requisito funcional 9. El usuario debe poder indicar de forma manual si ha tenido un incidente y requiere asistencia. Este requisito se considera de prioridad obligatoria, ya que de este modo podremos solventar un problema no detectado por el sistema por cualquier tipo de fallo hardware o software que se pudiera producir. 1 Termino usado para referirnos al proceso de acceso a un sistema mediante identificación. 39 5. A RQUITECTURA Y D ESARROLLO Requisito funcional 10. El usuario debe poder contar con un periodo de tiempo para cancelar un incidente detectado por el sistema, antes de que este sea notificado. La prioridad de este requisito es obligatoria, ya que de este modo podemos subsanar posibles errores debidos a falsos positivos que pudieran surgir en la detección de un accidente por parte del sistema detección. Requisito funcional 11. El personal de los servicios de emergencia debe poder listar los incidentes que han sido notificados al sistema. Este requisito es obligatorio ya que los servicios de emergencia son los encargados finales de atender los incidentes, y para ello se requiere que estén informados debidamente de los mismos. Requisito funcional 12. El personal de los servicios de emergencias debe poder modificar el estado de un incidente, para saber si se encuentra sin asignar, asignado o si ya esta resuelto. Este requisito es de prioridad obligatoria, ya que de este modo se facilita la distribución del personal de los servicios de emergencias, de modo que no queden incidentes sin resolver, mientras que en otros sobra asistencia. Requisito funcional 13. El personal de los servicios de emergencias debe poder visualizar los datos de la víctima. Consideramos que se trata de un requisito obligatorio ya que para realizar una buena asistencia será preciso conocer ciertos datos de la víctima, como por ejemplo el número que dicha víctima desea que sea avisado en caso de emergencia. Requisito funcional 14. El personal de los servicios de emergencia debe poder conocer en todo momento la localización exacta de la víctima. Nos encontramos ante un requisito fundamental del sistema, ya que sin él no se podrá realizar un rescate eficiente. Es por eso que este requisito es de carácter obligatorio. Requisito funcional 15. El sistema debe permitir la activación y desactivación de ciertos actuadores en el smartphone de la víctima para facilitar la localización in situ. Se considera un requisito obligatorio, ya que define uno de los objetivos principales marcados por este proyecto (ver capítulo 3) que es el de poder controlar remotamente ciertos aspectos del dispositivo. Requisito funcional 16. El sistema debe permitir modificar de forma remota la forma en que trabajan los actuadores. Este requisito se considera deseable, ya que si bien sería apropiado contar con un mecanismo que nos permita adaptar los actuadores a una situación determinada, no podemos considerar que se trate de un factor determinante en el funcionamiento del sistema en su conjunto. Requisito funcional 17. El sistema debe contar con un mecanismo de filtrado de las peticiones realizadas a un dispositivo por los servicios de emergencias. La prioridad de este requisito se considera deseable, ya que este filtrado no interviene en el funcionamiento básico del sistema, pero sin embargo es muy recomendable poder contar con 40 5. A RQUITECTURA Y D ESARROLLO un mecanismo que proteja el dispositivo del usuario de un abuso de peticiones por parte del personal de los servicios de emergencias que pudiera consumir la batería del dispositivo, dejándolo inservible para el sistema. 5.2.2 Requisitos no funcionales A parte de los requisitos funcionales mencionados en la sección 5.2.1, el sistema cuenta con algún requisito no funcional que debemos mencionar. En este apartado mostraremos los requisitos no funcionales que se han tenido en cuenta en el desarrollo del sistema. Requisito no funcional 1. Las aplicaciones de usuario y servicios de emergencia deberán estar orientadas a plataformas móviles como tablet o smartphone. Consideramos este requisito no funcional como obligatorio, ya que es necesario que estas partes del sistema puedan ser transportadas, la primera para detectar el accidente y la segunda para facilitar la comunicación y localización de la víctima en caso de accidente. Requisito no funcional 2. El SO para las aplicaciones de usuario y servicios de emergencia será Android. Este requisito se considera deseable, ya que se podría hacer uso de otro SO, pero se ha escogido Android por lo ampliamente extendido que está entre los smartphone, y por la facilidad de acceso a las APIs de desarrollo y a la documentación. Requisito no funcional 3. Se deberán utilizar estándares y software libre para la realización de todo el sistema. Se considera un requisito deseable, ya que de este modo resultarán más sencillas de realizar las posibles expansiones futuras. 5.3 Casos de uso De acuerdo a los requisitos estudiados en la sección 5.2 de este capítulo, se ha creado el modelo de casos de uso apropiado para el sistema que se pretende desarrollar. La representación de este modelo puede ser vista en la figura 5.3 mediante el correspondiente diagrama de casos de uso. 5.4 Proceso de desarrollo En este apartado se mostrarán las distintas iteraciones que han tenido lugar en el desarrollo de este proyecto. Los test y algunos de los diagramas que se mostrarán, harán referencia a la versión final del software, ya que dichos productos han sufrido cambios debido a diferentes procesos de refactorización a lo largo del desarrollo. En el proceso de desarrollo se persiguió el contar con un prototipo de la aplicación extremo a extremo desde un primer momento, y después, sobre este, añadir progresivamente las funcionalidades que fueran siendo necesarias, hasta alcanzar un grado de satisfacción aceptable con el producto. Los tests utilizados los podemos dividir en dos tipos: 41 5. A RQUITECTURA Y D ESARROLLO Figura 5.3: Diagrama de Casos de Uso Test unitarios Son los test que tienen como objetivo probar el correcto funcionamiento de cada uno de los módulos de la aplicación por separado. El lenguaje utilizado para realizar estos test unitarios ha sido Python o Java, dependiendo de la localización del módulo en el sistema. Para los módulos del bloque de gestión se ha empleado Python por ser el lenguaje empleado en este bloque de la aplicación, mientras que para los módulos referentes a los bloques del agente y de rescate ha sido Java. Test de integración Estos test pretenden probar el correcto funcionamiento del sistema en su conjunto. Para la realización de estos test, el lenguaje empleado ha sido Python por su sencillez y rapidez a la hora de realizar este tipo de test. Además para facilitar la labor de las pruebas de integración se han realizado dobles de prueba, de modo que todos los componentes se encuentren escritos en el mismo lenguaje a la hora de realizar las pruebas. 42 5. A RQUITECTURA Y D ESARROLLO 5.4.1 Detección y notificación de incidentes Análisis y diseño La aplicación que se pretende realizar debe contar con un sistema capaz de detectar un accidente que se produzca durante un trayecto en carretera. Para ello, lo primero que debemos identificar es el momento en que el usuario inicia la ruta, para desde ese momento activar los dispositivos necesarios para la detección. El proceso de detección debe estar formado por uno o varios sensores que informen a un centinela de cualquier irregularidad, para de este modo centralizar dicho proceso. La activación del centinela y sus sensores asociados se realizará en el momento en que el usuario indique el comienzo de una nueva ruta. Finalmente, si el centinela detecta algún tipo de incidente, procederá al envío de dicho incidente, con su información asociada, a un gestor, el cual almacenará de manera apropiada el incidente para su posterior tratamiento y difusión. Además, antes de realizar el envío, se dejará un tiempo en el cual el usuario podrá cancelar el envío del incidente. Implementación La realización de esta funcionalidad conlleva la creación de dos módulos, uno de ellos destinado a la detección de incidentes, y otro destinado a la gestión de incidentes. En el test de integración mostrado en el listado 5.1, puede apreciarse como se realiza el proceso de comunicación entre estos dos módulos. El test consiste en la comunicación de un incidente desde el centinela del módulo de detección al módulo de gestión de incidentes. Para la detección se ha creado la clase Sentry, que una vez que fue llevada a la aplicación del smartphone, se transformó en un servicio Android de ejecución en segundo plano. Este servicio es lanzado cuando el usuario pulsa un botón, presente en una Activity, con el que indica el comienzo de una nueva ruta en carretera (ver figura A.3). Para la realización de los mecanismos de detección de Sentry, inicialmente se implementó el mecanismo más simple, que consistía en la pulsación de un botón de alerta por parte del usuario. Más tarde, con la realización del módulo sobre Android, se reforzó con la creación de la clase MotionSensor, que haciendo uso del acelerómetro del teléfono detecta las fuerzas de aceleración experimentadas, y comprueba que no sobrepasen un límite. Para este cometido, el límite ha sido fijado en 3G, ya que es el empleado en la activación de los airbag, y por ello resulta apropiado. Una vez que un incidente es detectado, Sentry lanza una Activity que muestra una barra de progreso, conectada a un temporizador de cuenta atrás, y un botón que permite cancelar el envío del incidente (ver figura A.5). Si el temporizador llega a cero, el incidente será enviado al gestor. 43 5. A RQUITECTURA Y D ESARROLLO Por otro lado, en el módulo de gestión de incidentes se ha creado la clase Incident con el fin de almacenar toda la información referente al incidente, y la clase IncidentManager, destinada a gestionar los incidentes que se produzcan permitiendo informar de ellos, cambiar su estado y consultarlos de forma apropiada. La notificación del incidente se realizará mediante una llamada a la función notifyIssue de la clase IncidentManager en la que se le suministrará la información referente al incidente, así como la víctima del mismo y un proxy al centinela de la víctima para poder comunicarse con la víctima y realizar ciertas acciones. La figura 5.4 muestra, mediante un diagrama de secuencia, un escenario normal de notificación de un incidente, detectado por el sensor de movimiento. Se entiende que dicho sensor ha recibido un evento del acelerómetro, con una fuerza superior a 3G, antes de realizar la notificación al centinela. Figura 5.4: Diagrama de secuencia de la notificación de un incidente El S LICE que muestra las interfaces precisas para la realización de esta primera iteración se muestra en el listado 5.2. 5.4.2 Solicitud de listado de incidentes Análisis y diseño El personal de rescate encargado de atender los incidentes que sean detectados y notificados al gestor, necesitará un mecanismo de consulta de todos ellos, para poder escoger cuál debe atender en cada momento. La realización de esta acción se producirá bajo demanda de alguien perteneciente al personal de rescate, y por lo general, será la primera acción que realice al entrar al sistema. como resultado, la persona perteneciente al personal de emergencias recibirá un listado de todos los incidentes que han sido previamente registrados y almacenados en el sistema. 44 5. A RQUITECTURA Y D ESARROLLO Implementación Esta funcionalidad implica la utilización del módulo creado anteriormente para la gestión de incidentes, aunque añadiéndole una nueva funcionalidad, y la creación de un nuevo módulo destinado a realizar consultas al gestor. La comunicación entre estos módulos queda plasmada en el test de integración del listado de código 5.3. Este test analiza la realización de una solicitud del listado completo de incidentes registrados, por parte del módulo de consulta. Inicialmente, con motivo de simplificar las primeras etapas del desarrollo, los datos referentes a los distintos incidentes notificados eran almacenados en memoria mediante estructuras de datos, por lo que el proceso de búsqueda y envío de los mismos era relativamente sencillo, y se realizaba mediante la función listIncidents de la clase IncidentManager. Posteriormente, se creó una base de datos para almacenarlos (véase 5.4.8), y parte del proceso de búsqueda se relegó a la clase Incident, contando ésta con los recursos necesarios para realizar las consultas relacionadas con incidentes, sobre la BD. Por otro lado, el módulo de consultas, antes de la realización de la aplicación en Android, estaba formado por la clase QuerySystem, que al realizar el cambio a la plataforma móvil, fue transformado en la activity ShowIncidentsActivity (ver figura B.2). Dicha activity se presenta al iniciar la aplicación de los servicios de emergencia, y realiza una petición del listado de incidentes a IncidentManager. Como resultado de esta petición obtiene una IncidentsList que adapta para su representación en un ListView de Android. El diagrama de secuencia correspondiente al proceso de solicitud del listado de incidentes por el personal de rescate, puede verse en la figura 5.5. En dicha figura no aparece el proceso de búsqueda y extracción de los incidentes de la BD, ya que se entiende que corresponde a las primeras etapas, en las que se almacenaban en estructuras de datos. A continuación se muestra, como queda el S LICE de definición de las interfaces que intervienen una vez realizada esta iteración. (Ver listado 5.4). 5.4.3 Petición de datos de usuario Análisis y diseño En esta iteración, se puso de manifiesto la necesidad de conocer los datos de un usuario que ha notificado un incidente. De este modo, un usuario perteneciente al rescate, podría consultar dichos datos y realizar una asistencia más eficiente, como por ejemplo realizando una llamada de teléfono para conocer el estado de la víctima. Para ello, será necesaria la creación de un formulario de registro, en el que el usuario introduzca sus datos, y estos queden almacenados. En el caso de que el usuario deba notificar un incidente, estos datos serán enviados. Finalmente, será necesario un mecanismo de consulta de dichos datos, cuando un usuario de rescate lo requiera. 45 5. A RQUITECTURA Y D ESARROLLO Figura 5.5: Diagrama de secuencia de la notificación de un incidente Implementación La realización de esta funcionalidad ha sufrido muchos cambios durante el desarrollo, debido a labores de refactorización. Inicialmente, no llevó a la creación de ningún nuevo módulo, pero posteriormente, esta funcionalidad junto con otras, llevó a la creación de un nuevo módulo dedicado a la gestión de usuarios. El listado de código del S LICE 5.5, muestra los cambios realizados conforme a este punto. Como se observa, aún no se ha tenido en cuenta la creación del gestor de usuarios, y lo que se ha hecho ha sido añadir la función getUserData a la interfaz de gestión de incidentes. Esta función, en iteraciones posteriores, pasará a una interfaz distinta destinada a los procesos de gestión de usuarios. Además, se ha añadido la clase UserData, para recoger los datos del usuario, y enviar un objeto de este tipo en el momento de realizar una notificación de incidente. Con respecto a los cambios en el código. Inicialmente se crearon las estructuras de datos necesarias para almacenar los datos de los usuarios en el gestor, pero después de añadir el sistema de base de datos, se creó la clase User que permite el tratamiento de la información de los usuarios en la base de datos. Por otro lado, en el módulo de consulta se añadió una función para la obtención de los datos de una víctima determinada. Esta funcionalidad fue llevada al sistema Android con la creación de la activity IncidentDataActivity (ver figura B.3), que mostraba toda la información de un incidente y de su víctima, una vez seleccionado dicho incidente en la lista inicial creada en la iteración anterior (véase 5.4.2). 46 5. A RQUITECTURA Y D ESARROLLO En la figura 5.6, se muestra el diagrama de secuencia de un caso normal de solicitud de datos de un usuario, por parte de alguien del personal de emergencias. Antes de este proceso, se entiende que algún usuario ha notificado un incidente, y que el usuario de emergencia está visualizando la lista de incidentes, obtenida en 5.4. Figura 5.6: Diagrama de secuencia de petición de datos de un usuario 5.4.4 Petición de localización Análisis y diseño Llegados a este punto, el siguiente paso es dotar al sistema de un mecanismo capaz de localizar a la víctima. Este proceso se puede dividir en dos partes: una primera en la que se obtiene la posición de la víctima, y otra, en la que se representa sobre un mapa mediante geoposicionamiento. El primer proceso, se debe realizar mediante el uso del GPS para obtener la latitud y longitud, correspondiente a la localización de la víctima. Para ello, se deberá aportar un mecanismo de activación del GPS, en el momento de iniciar una nueva ruta, si este no esta activo aún. El segundo proceso, requiere de un mecanismo de consulta de los valores obtenidos por el GPS desde la aplicación del rescatador. Una vez obtenidos estos valores, se precisará la representación de un punto sobre un mapa para facilitar el proceso de búsqueda. Implementación En esta iteración se necesitará la creación de tres nuevos módulos, uno de ellos destinado a aportar los servicios de control remoto, otro destinado a las funciones de rescate (para lo cual realiza peticiones sobre el anterior), y un último módulo que realiza el control de acceso a estos servicios. 47 5. A RQUITECTURA Y D ESARROLLO Los cambios realizados con respecto a la versión del S LICE de la iteración anterior, pueden verse en el listado 5.6. En este listado de código se observa la creación de tres nuevas interfaces: una destinada a la manipulación de las opciones disponibles en el GPS, otra destinada a gestionar los componentes RC y una tercera para aportar el control de acceso al tratamiento de estos componentes. Además, se ha añadido una clase para definir las peticiones de acceso al GPS y otra para definir la posición obtenida. La comunicación entre el módulo de control de acceso y el módulo RC queda explicada en el test de integración 5.7, que fue realizado para esta iteración, aunque como ya se comentó al principio de esta sección, el test mostrado corresponde a la versión obtenida después de los sucesivos procesos de refactorización. En el test, se observa como el SUT, realiza la llamada a la interfaz RCManager para obtener el acceso al GPS, y una vez lo obtiene le solicita la localización. En el proceso de desarrollo de esta iteración, se crearon las clases que implementan las interfaces del S LICE en sus respectivos módulos. Además, se ha creado la función getRemoteControl en la clase IncidentManager, que permite obtener un objeto RemoteControl apropiado para el manejo de un determinado incidente. En cuanto a la parte de esta iteración que se ejecuta en Android. Por un lado tenemos la clase GPSI, que además de ser la definición de la interfaz GPS, implementa la interfaz de Android LocationListener que permite obtener los cambios en la localización captados por el GPS. Por el lado del rescatador, se creó una activity para la asistencia. Esta activity se dividió en fragments (ver sección 2.3.1), donde uno de ellos se destinó al proceso de mostrar los datos del incidente (realizado anteriormente en la iteración de la sección 5.4.3) y otro al geoposicionamiento de la víctima (ver figura 6.6). El geoposicionamiento se realizó mediante un SupportMapFragment. Este consiste en un tipo especifico de fragment, que permite la manipulación de los mapas de GoogleMaps. De este modo se pudo representar un mapa y dibujar un punto de localización sobre él. En el diagrama de secuencia de la figura 5.7, se muestra el proceso de solicitud de localización de una víctima por parte de los servicios de emergencia. En este diagrama se ha obviado el proceso de obtención del RCManager de la víctima, ya que se reduce a una simple petición al centinela de la víctima. Además se considera que antes de este proceso, la víctima ha enviado un incidente. 5.4.5 Peticiones de activación y desactivación de actuadores Análisis y diseño En esta iteración se realizarán los mecanismos necesarios para poder interactuar con la víctima de un incidente. 48 5. A RQUITECTURA Y D ESARROLLO Figura 5.7: Diagrama de secuencia de la solicitud de localización Para realizar este proceso, primero deberemos comprobar que los actuadores a los que se desea dar servicio están disponibles en el dispositivo. Además, se deben crear las funciones necesarias para indicar al hardware la activación y desactivación de dichos actuadores. En la parte del rescatador, se deberá facilitar un panel, que permita la activación y desactivación de los actuadores, una vez seleccionado un incidente. Además, se deberá poder conocer el estado en el que se encuentran los actuadores en todo momento. Implementación Esta iteración hará uso de los módulos creados en el paso anterior añadiéndoles nuevas funcionalidades. El listado de código 5.8 muestra los cambios producidos en el S LICE con respecto a la iteración anterior. Se han añadido interfaces para los distintos actuadores con las acciones de activar o desactivar. También se han añadido dos tipos nuevos de «request», uno para cada una de las acciones citadas. Para la implementación de esta iteración, se han añadido las funciones activate y deactivate a la clase RemoteControl creada en la iteración anterior. Además se han añadido las funciones necesarias al RCManager para la obtención de los objetos que regulan el funcionamiento de los actuadores. En Android se han creado las clases SpeakerI, LampI y VibratorI, cada una encargada de facilitar la interacción con el actuador correspondiente del dispositivo físico. Estas clases además suponen la implementación de las interfaces del S LICE, de manera que aportan la comunicación con los actuadores. 49 5. A RQUITECTURA Y D ESARROLLO Por la parte de la aplicación del equipo de rescate, se ha añadido un nuevo fragment a la activity AssistanceActivity. Este nuevo fragment presenta un panel de control, donde se permite la activación y desactivación de los actuadores de la víctima, y se muestra el estado en que se encuentran cada momento (ver figura B.5). El proceso de activación de un actuador puede verse en el diagrama de secuencia de la figura 5.8. En este diagrama se muestra la activación del altavoz de la víctima desde la aplicación de rescate. El proceso para activación del resto de actuadores sería análogo al mostrado en la figura, y el proceso de desactivación de cualquiera de los actuadores sería muy similar cambiando el tipo de «request». Figura 5.8: Diagrama de secuencia de la activación del altavoz 5.4.6 Peticiones de regulación de actuadores Análisis y diseño Para poder adecuar el comportamiento de los actuadores a cada situación, se planteó crear un sistema de regulación de ciertos aspectos de su comportamiento, como por ejemplo el volumen del altavoz o el grado de luminosidad de la linterna. Para realizar esta funcionalidad, se requiere comprobar las posibilidades de modificación que presentan los componentes físicos, y aportar las funciones necesarias para realizar la modificación de estos comportamientos. El siguiente paso será servir estas funciones de forma remota para que puedan ser usadas por los servicios de emergencias. Y finalmente se deberá crear un panel con los controles necesarios para modificar el valor de las variables que regulan el comportamiento de estos componentes. Implementación La realización de esta iteración no ha supuesto la creación de nuevos módulos, y la variación en cuanto al S LICE de la versión anterior ha sido mínima. Los cambios en el S LICE han 50 5. A RQUITECTURA Y D ESARROLLO consistido en añadir las funciones de configuración a las interfaces de comunicación de cada actuador, y la creación de tres nuevas clases para adaptar las peticiones de activación de cada actuador. Estas nuevas clases heredan de la clase ActivationRequest definida en la iteración anterior. Los cambios realizados en el S LICE pueden verse en el listado 5.9. En cuanto a la implementación del código en el agente, los cambios producidos han sido la incorporación de la función configure a cada uno de los componentes actuadores. Esta función recibe los valores nuevos que deben ser establecidos en la configuración del actuador, y realiza los cambios oportunos. En la parte del gestor, se ha modificado el comportamiento de la función activate de la clase RemoteControlI, para que realice la configuración apropiada del actuador antes de su activación. Por último, en la aplicación de rescate se han añadido componentes reguladores al panel de control, para fijar los valores de configuración que se desean establecer para cada componente actuador. El proceso de configuración se realiza en el momento de la activación del actuador. 5.4.7 Filtrado de peticiones a actuadores Análisis y diseño Con el fin de preservar la batería del smartphone de la víctima, se creará un filtro de peticiones, de forma que se reserve la batería para las tareas más importantes del rescate. El primer paso será crear un mecanismo que permita la lectura del nivel de la batería en el dispositivo del usuario. Después, se crearán los medios necesarios para permitir la lectura de la batería desde el gestor. Finalmente, se creará en el gestor un componente que acceda a esta lectura y realice el filtrado de peticiones según algún criterio. Implementación El desarrollo de esta iteración no ha supuesto la creación de nuevos módulos a la aplicación, sin embargo se ha añadido nueva funcionalidad al módulo RC y al de control de acceso creados en pasos previos del desarrollo. El listado 5.10 muestra los cambios que han sido necesarios en el S LICE. Se observa la creación de la nueva interfaz Battery y el mecanismo de obtención de esta a través de RCManager. El proceso de implementación comenzó con la creación de test unitarios que permitieran definir el comportamiento de filtrado. En el listado de código 5.11 se muestra un test unitario que define el comportamiento que se realiza ante una petición de activación del vibrador con un nivel de batería bajo. Ante esta situación se espera una respuesta negativa por parte del controlador de acceso. 51 5. A RQUITECTURA Y D ESARROLLO Los test realizados exigieron la creación de la clase BatteryI para acceder a la batería física del smartphone y realizar las lecturas de nivel. Además, en el manager se creó la clase AccessControl para realizar las peticiones remotas a la clase BatteryI, y según el valor obtenido permitir o denegar la activación de un actuador. El diagrama de secuencia de la figura 5.9, muestra un intento de activación del vibrador, denegado por el control de acceso, con motivo de un nivel de batería bajo en el dispositivo de la víctima. Figura 5.9: Diagrama de secuencia de intento de activación del vibrador con batería baja 5.4.8 Almacenamiento de información en BD Análisis y diseño En este punto del desarrollo se hizo necesario contar con mecanismos de persistencia que permitieran almacenar los datos obtenidos por la aplicación en una BD. Después de pensar en la información que era necesario almacenar, se diseñó la base de datos que permitía almacenar dicha información, atendiendo a las relaciones entre los datos. En la figura 5.10 se muestra el diagrama entidad relación que muestra el diseño de la base de datos creada. Una vez realizada la base de datos, se deberá crear los mecanismos de acceso a ella que nos permitan realizar las operaciones de inserción, modificación, eliminación y búsqueda de los datos. 52 5. A RQUITECTURA Y D ESARROLLO Figura 5.10: Esquema de la base de datos Implementación La realización de esta iteración afecta únicamente a la aplicación de gestión (LoRAM_Management), ya que para las aplicaciones de ambos extremos debe ser transparente el modo en que se almacena la información. La implementación se ha realizado creando un broker en python, que haciendo uso de la biblioteca MySQLdb, accede a una base de datos MySQL. Además se han añadido métodos para la persistencia en las clases Incident y User. 5.4.9 Registro y login de usuarios Análisis y diseño La iteración consiste en realizar un control centralizado de usuarios que acceden al sistema, para de esta forma regular los accesos y controlar las personas que están conectadas en cada momento y los permisos de que disponen. Para realizar este acción se deben aportar formularios de login y registro en las aplicaciones de usuarios. También sera necesario que el gestor aporte funciones que permitan la conexión y registro de usuarios de forma remota. Además, será conveniente contar con un mecanismo de sesión que permita mantener los datos de los usuarios conectados. Implementación La realización de esta iteración ha supuesto la creación de un nuevo módulo para realizar la gestión de usuarios. También se han producido modificaciones en el módulo de gestión de incidentes, ya que antes realizaba alguna tarea de gestión de usuarios y ahora quedará relegada al nuevo módulo. En el S LICE se han producido los cambios mostrados en el listado de código 5.12. Como se observa, se ha creado una interfaz para la gestión de usuarios, y ahora la solicitud de los datos de usuario se realiza desde esta interfaz. Además se ha añadido la clase RescuerData que representa los datos del usuario de rescate. 53 5. A RQUITECTURA Y D ESARROLLO Para la creación de esta funcionalidad se han realizado varios test de integración que representan las diferentes situaciones de comunicación entre módulos que se pueden dar. En el test 5.13 se muestra la comprobación de un login aceptado por el gestor. A parte de este test se crearon otros para definir el resto de situaciones posibles en el login y en el registro de usuarios. La implementación ha requerido la creación de las clases UserManagerI y Rescue, en el nuevo módulo creado para la gestión de usuarios, y la clase User, creada con anterioridad, ha sido trasladada también a este módulo. En Android ha sido necesaria la realización de las activities LoginActivity (Ver figura A.1) y RegisterActivity (ver figura A.2) tanto en la aplicación de rescate como en la de usuario, para presentar los formularios de login y registro respectivamente. El proceso de login puede verse en detalle en el diagrama de secuencia de la figura 5.11, donde se muestra la comunicación con el broker de la base de datos. Figura 5.11: Diagrama de secuencia del proceso de login aceptado 54 5. A RQUITECTURA Y D ESARROLLO 1 2 3 4 5 7 8 def test _noti fy_iss ue ( self ) : # Given email = " foo@example . com " user = Stub () user . email = email s e r v a n t I n c i d e n t M a n a g e r = Mimic ( Spy , IncidentManagerI ) incidentManager = self . adapter_add ( IncidentManagerPrx , servantIncidentManager ) 12 with Mimic ( Stub , UserManagerI ) as servant : servant . ge tI nc id en tMa na ge r ( email , ANY_ARG ) . returns ( incidentManager ) manager = self . adapter_add ( UserManagerPrx , servant ) 14 15 time = TimeC (10 , 20 , 30) date = DateC (25 , 5 , 2013) 17 18 19 with Stub () as datesChanger : datesChanger . o b t a i n T i m e T o T i m e s t a m p ( ANY_ARG ) . returns ( time ) datesChanger . o b t a i n D a t e T o T i m e s t a m p ( ANY_ARG ) . returns ( date ) 21 22 23 24 sut = LoRAM_Agent ( manager ) sut . connected = True sut . user = user sut . datesChanger = datesChanger 26 27 28 sut . startRoute () servantSentry = Mimic ( Stub , S e n t ry C o mm u n ic a t or I ) sut . sentry . communicator . proxy = self . adapter_add ( SentryCommunicatorPrx , servantSentry ) 30 31 32 # When timer = sut . alert () timer . expire () 34 35 # Then sentryExpected = sut . sentry . communicator . proxy issueExpected = IssueC ( time , date , IssueType . A le rt Bu tt on Pr es se d ) assert_that ( s e r v a n t I n c i d e n t M a n a g e r . notifyIssue , \ called () . with_args ( email , sentryExpected , issueExpected , ANY_ARG ) ) 10 11 36 37 38 Listado 5.1: Test de integración de la notificación de un incidente 55 5. A RQUITECTURA Y D ESARROLLO 1 module LoRAM { 3 enum IssueType { DetectedFall , DetectedCollision , Motion , AlertButtonPressed , UnknownIssue }; 5 6 class int int int }; Date { day ; month ; year ; class int int int }; Time { hour ; minute ; second ; 7 8 9 11 12 13 14 15 class Issue { Time timeIss ; Date dateIss ; IssueType typeIss ; }; 17 18 19 20 21 interface S en try Co mm un ic at or { void solveIncident () ; }; 23 24 25 interface IncidentManager { void notifyIssue ( string user , S en tr yC om mu ni ca to r * sentry , Issue iss ) ; }; 27 28 29 31 }; Listado 5.2: S LICE empleado en la primera iteración 56 5. A RQUITECTURA Y D ESARROLLO 1 2 3 4 5 7 8 def t es t _ l is t _ in c i de n t s ( self ) : # Given nif = " 11223344 a " password = " 1234 " rescuer = RescuerDataC ( nif , " name " , " surname1 " , " surname2 " , 123456789 , 10) s e r v a n t I n c i d e n t M a n a g e r = Mimic ( Spy , IncidentManagerI ) incidentManager = self . adapter_add ( IncidentManagerPrx , servantIncidentManager ) 14 with Mimic ( Stub , UserManagerI ) as servant : servant . loginRescuer ( nif , password , ANY_ARG ) . returns ( True ) servant . g e t L o g g e dR e s c u e r D a t a ( nif , ANY_ARG ) . returns ( rescuer ) servant . ge tI nc id en tMa na ge r ( nif , ANY_ARG ) . returns ( incidentManager ) manager = self . adapter_add ( UserManagerPrx , servant ) 16 sut = LoRAM_Rescue ( manager ) 18 # When sut . loginRescuer ( nif , password ) sut . querySystem . showIncidents () 10 11 12 13 19 20 23 24 # Then assert_that ( s e r v a n t I n c i d e n t M a n a g e r . listIncidents , called () . with_args ( rescuer . nif , \ 25 Listado 5.3: Test de integración de la solicitud del listado de incidentes 57 5. A RQUITECTURA Y D ESARROLLO 1 module LoRAM { 3 enum StateType { NoAllocate , Allocated , Resolved , UnknownState }; 5 6 7 8 9 10 11 12 13 class IncidentData { int idIncident ; string victim ; Date dateIncident ; Time timeIncident ; StateType state ; IssueType typeIncident ; int rescueTeam ; }; 15 sequence < IncidentData > IncidentsList ; 17 18 interface IncidentManager { void notifyIssue ( string user , S en tr yC om mu ni ca to r * sentry , Issue iss ) ; IncidentsList listIncidents ( string rescuer ) ; }; 19 20 22 }; Listado 5.4: Cambios realizados en el S LICE de la primera iteración 1 module LoRAM { class UserData { string email ; string name ; string surname1 ; string surname2 ; int phone ; int numAA ; }; 3 4 5 6 7 8 9 10 interface IncidentManager { void notifyIssue ( UserData user , S en tr yC om mu ni ca to r * sentry , Issue iss ) ; IncidentsList listIncidents ( string rescuer ) ; UserData getUserData ( string email ) ; }; 12 13 14 15 16 18 }; Listado 5.5: Cambios realizados en el S LICE de la segunda iteración 58 5. A RQUITECTURA Y D ESARROLLO 1 module LoRAM { 3 4 5 exception GenericError { string reason ; }; 7 exception ActuatorOff extends GenericError {}; exception N o t A v a i l a b l e Ac t u a t o r extends GenericError {}; exception NotExistRCModule extends GenericError {}; 8 9 11 enum LocationType { GPSType , NETWORKType }; 13 class Location { double latitude ; double longitude ; }; 14 15 16 class LocationRequest { LocationType locType ; long t ime Be tw ee nU pd at es ; long d i s t a n c e C h a n g e F o r U p d a t e s ; }; 18 19 20 21 22 interface GPS { bool isEnable () ; Location getLocation () throws ActuatorOff ; void configure ( long timeBetweenUpdates , long distanceChangeForUpdates ); }; 24 25 26 27 28 interface RCManager { GPS * getGPS () throws N o t A v a i l a b l e A c t u a t o r ; }; 30 31 32 interface S en try Co mm un ic at or { RCManager * getRCManager () throws NotExistRCModule ; void solveIncident () ; }; 34 35 36 37 interface RemoteControl { Location getLocation ( LocationRequest request ) throws NotAvailableActuator , ActuatorOff ; }; 39 40 41 42 interface IncidentManager { void notifyIssue ( string email , S en tr yC om mu ni ca to r * sentry , Issue iss ) ; IncidentsList listIncidents ( string nif ) ; UserData getUserData ( string email ) ; RemoteControl * getRemoteControl ( string email ) ImposibleConnectWithUser ; 44 45 46 47 48 }; 50 52 }; Listado 5.6: Cambios realizados en el S LICE de la tercera iteración 59 5. A RQUITECTURA Y D ESARROLLO 1 2 3 4 5 6 7 def t e s t _ g e t _ v i c t i m _ l o c a t i o n ( self ) : # Given request = Stub () request . locType = LocationType . GPSType request . ti me Be tw een Up da te s = 15000 request . d i s t a n c e C h a n g e F o r U p d a t e s = 0 location = LocationC (25 , 42.2) 11 with Mimic ( Spy , GPSI ) as servantGPS : servantGPS . getLocation ( ANY_ARG ) . returns ( location ) gps = self . adapter_add ( GPSPrx , servantGPS ) 13 14 15 with Mimic ( Spy , RCManagerI ) as servantRCManager : servantRCManager . getGPS ( ANY_ARG ) . returns ( gps ) rcManager = self . adapter_add ( RCManagerPrx , servantRCManager ) 17 18 19 with Mimic ( Stub , S en tr yC o m mu n i ca t o rI ) as servantSentry : servantSentry . getRCManager ( ANY_ARG ) . returns ( rcManager ) sentry = self . adapter_add ( SentryCommunicatorPrx , servantSentry ) 21 22 with Stub () as accessControl : accessControl . i s S u i t a b l e G e t L o c a t i o n ( ANY_ARG ) . returns ( True ) 24 sut = RemoteControlI ( sentry ) 26 sut . accessC = accessControl 28 29 # When test1 = sut . getLocation ( request ) 31 32 33 34 # Then assert_that ( servantRCManager . getGPS , called () ) assert_that ( servantGPS . getLocation , called () ) assert_that ( test1 , is_ ( location ) ) 9 10 Listado 5.7: Test de integración de la solicitud de localización a la víctima 60 5. A RQUITECTURA Y D ESARROLLO 1 module LoRAM { 3 enum ActuatorType { TypeSpeaker , TypeLamp , TypeVibrator , TypeLocation }; 5 6 7 8 class Activ ation Reques t { Time timeReq ; Time duration ; ActuatorType typeReq ; }; 9 11 12 13 14 class D e a ct i v at i o nR e q ue s t { Time timeReq ; ActuatorType typeReq ; }; 16 17 18 19 interface Speaker { void turnOn () ; void turnOff () ; }; 21 22 23 24 interface Lamp { void turnOn () ; void turnOff () ; }; 26 interface Vibrator { void turnOn () ; void turnOff () ; }; 27 28 29 interface RCManager { Speaker * getSpeaker () throws N o t A v a i l a b l e A c t u a t o r ; Lamp * getLamp () throws N o t A v a i l a b l e A c t u a t o r ; Vibrator * getVibrator () throws N o t A v a i l a b l e A c t u a t o r ; GPS * getGPS () throws N o t A v a i l a b l e A c t u a t o r ; }; 31 32 33 34 35 36 interface RemoteControl { void activate ( Acti vation Reque st request ) throws NotAvailableActuator , NotSuitable ; void deactivate ( D e a cti v at i o n Re q u es t request ) ; Location getLocation ( LocationRequest request ) throws NotAvailableActuator , ActuatorOff ; }; 38 39 40 41 42 43 45 }; Listado 5.8: Cambios realizados en el S LICE de la cuarta iteración 61 5. A RQUITECTURA Y D ESARROLLO 1 module LoRAM { 3 enum Level { High , Medium , Low }; 5 6 7 8 class S p e a k e r A c t i v a t i o n R e q u e s t extends Act ivatio nReque st { float volume ; float rate ; }; 10 11 12 class L a m p A c t i v a t i o n R e q u e s t extends Act ivatio nReque st { Level brightness ; }; 14 class V i b r a t o r A c t i v a t i o n R e q u e s t extends Act ivatio nReque st { Level frequency ; }; 15 16 interface Speaker { void turnOn () ; void turnOff () ; void configure ( float volume , float rate ) ; }; 18 19 20 21 22 interface Lamp { void turnOn () ; void turnOff () ; void configure ( Level brightness ) ; }; 24 25 26 27 28 interface Vibrator { void turnOn () ; void turnOff () ; void configure ( Level frequency ) ; }; 30 31 32 33 34 35 }; Listado 5.9: Cambios realizados en el S LICE de la quinta iteración 1 module LoRAM { 3 4 5 interface Battery { float getLevel () ; }; 7 interface RCManager { Speaker * getSpeaker () throws N o t A v a i l a b l e A c t u a t o r ; Lamp * getLamp () throws N o t A v a i l a b l e A c t u a t o r ; Vibrator * getVibrator () throws N o t A v a i l a b l e A c t u a t o r ; GPS * getGPS () throws N o t A v a i l a b l e A c t u a t o r ; Battery * getBattery () ; }; 8 9 10 11 12 13 15 }; Listado 5.10: Cambios realizados en el S LICE de la sexta iteración 62 5. A RQUITECTURA Y D ESARROLLO 1 2 3 def t e s t _ a c t i v a t i o n _ w i t h _ l o w _ b a t t e r y ( self ) : # Given self . levelLow = 15 5 6 with Stub () as self . battery : self . battery . getLevel () . returns ( self . levelLow ) 8 sut = AccessControl ( self . battery ) 13 vibratorOn = True lampOn = False speakerOn = False actuatorsOn = [ speakerOn , lampOn , vibratorOn ] 15 16 # When test = sut . isS ui ta bl eA ct iv at e ( actuatorsOn ) 18 # Then assert_that ( test , is_ ( False ) ) 10 11 12 19 Listado 5.11: Test unitario de intento de activación con batería baja 63 5. A RQUITECTURA Y D ESARROLLO 1 module LoRAM { exception exception exception exception 3 4 5 6 class RescuerData { string nif ; string name ; string surname1 ; string surname2 ; int phone ; int team ; }; 8 9 10 11 12 13 14 15 interface UserManager { bool login ( string email , string password ) throws UserNotFound ; bool loginRescuer ( string nif , string password ) throws UserNotFound ; void logout ( string identification ) ; void register ( UserData user , string password ) throws Use rAlrea dyExis ts ; void registerRescuer ( RescuerData user , string password ) throws Use rAlrea dyExis ts ; UserData getL oggedU serDat a ( string email ) throws UserNotLogged ; RescuerData g e t L o g g e d R e s c u e r D a t a ( string nif ) throws UserNotLogged ; IncidentManager * g et In ci de nt Man ag er ( string identification ) throws AccessDenied ; }; 17 18 19 20 21 22 23 24 25 26 30 UserNotFound extends GenericError {}; UserNotLogged extends GenericError {}; AccessDenied extends GenericError {}; UserA lread yExist s extends GenericError {}; }; Listado 5.12: Cambios realizados en el S LICE de la séptima iteración 64 5. A RQUITECTURA Y D ESARROLLO 1 2 3 4 5 def t es t _ l og i n _a c c ep t e d ( self ) : # Given email = " foo@example . com " password = " 1234 " user = UserDataC ( email , " name " , " surname1 " , " surname2 " , 123456789 , 987654321) 7 8 9 10 with Mimic ( Spy , UserManagerI ) as servant : servant . login ( email , password , ANY_ARG ) . returns ( True ) servant . g etLogg edUser Data ( email , ANY_ARG ) . returns ( user ) manager = self . adapter_add ( UserManagerPrx , servant ) 12 sut = LoRAM_Agent ( manager ) 14 15 # When sut . login ( email , password ) 17 18 # Then assert_that ( servant . login , called () . with_args ( email , password , ANY_ARG ) ) assert_that ( sut . connected , is_ ( True ) ) assert_that ( servant . getLoggedUserData , called () . with_args ( email , ANY_ARG ) ) assert_that ( sut . user , is_ ( user ) ) 19 20 21 Listado 5.13: Test de integración de login aceptado 65 Capítulo 6 Resultados E n este capítulo se muestran los resultados obtenidos de un análisis sobre posibles errores debidos a falsos positivos, y se estudia la aplicación en funcionamiento sobre un escenario ficticio, donde se observan los comportamientos ante esta situación de prueba. También se realiza una estimación del coste que ha supuesto la realización del proyecto, y se determina el tiempo empleado en llevarlo a cabo. 6.1 Resultados En esta sección se realiza un análisis sobre el proceso de detección, y se analizan los resultados obtenidos en un ensayo realizado para intentar determinar las causas que pueden provocar falsos positivos. Posteriormente se muestra los pasos realizados en una prueba real de la aplicación, y se indican los comportamientos obtenidos por ésta. Análisis previo Una de las principales dificultades que existía a la hora de realizar la aplicación, era la de ser capaz de detectar un accidente lidiando con el problema de los falsos positivos. Para la detección, se optó por hacer uso del acelerómetro integrado en el teléfono, pero entonces apareció la dificultad de determinar un umbral adecuado que nos permitiera saber en qué situación estamos ante un accidente de tráfico. Ya que no se contaba con los medios apropiados para recrear impactos y poder realizar un cálculo del umbral adecuado, se decidió estudiar tecnologías similares para comprobar en que valor se solía establecer dicho umbral. Así, se comprobó que en otros sistemas en los que es preciso detectar un accidente, como es el caso del airbag, este valor se establecía en 3G. Sin embargo todos los sistemas que se encontraron estaban orientados a vehículos automóviles, por lo que no se sabía como afectarían los falsos positivos en una motocicleta, que cuenta con otras condiciones, como un alto grado de vibración. Posteriormente se realizó un estudio sobre los casos que eran potencialmente propensos a ser considerados como falsos positivos. Dado que la aplicación solo se activa cuando se indica el inicio de una ruta, estos casos debían ser estudiados en el momento en que nos 66 6. R ESULTADOS 67 encontramos sobre la motocicleta. La causa principal que se consideró era la de realizar una parada de emergencia. Para la realización de la prueba se usó un ciclomotor tipo scooter y un smartphone HTC Desire. La captura de los datos se ha realizado con la app de Android Accelerometer Monitor1 . Los resultados obtenidos al realizar una parada de emergencia a 30km/h y 50Km/h se muestran en los gráficos de las figuras 6.1 y 6.2 respectivamente. 18 16 14 m/s2 12 10 8 6 4 0 20 40 60 ds 80 100 120 Figura 6.1: Gráfico de los valores máximos de aceleración en valor absoluto para una frenada de emergencia a 30km/h. El eje vertical expresa la fuerza de aceleración experimentada en m/s2 y el eje horizontal expresa el momento de tiempo en décimas de segundo (ds) Estos gráficos representan los valores absolutos máximos de aceleración en m/s2 captados en las frenadas de emergencia de los dos casos representados. Para la creación de estos gráficos se ha usado la herramienta Octave2 . Como se puede observar en los gráficos, en ninguno de los casos se alcanza ni de lejos el valor umbral de 3G, por lo que podemos decir que las frenadas de emergencia no serán causa de falsos positivos. Detección y envío del accidente Dada la imposibilidad de probar la aplicación en su entorno real, por motivos obvios, se ha optado por representar un escenario alternativo que nos pueda ayudar a probar la aplicación, sin la necesidad de que se produzca un accidente real. Para la realización de esta prueba ha 1 2 https://play.google.com/store/apps/details?id=com.lul.accelerometer http://www.gnu.org/software/octave/ 6. R ESULTADOS 68 16 14 m/s2 12 10 8 6 4 0 50 100 150 200 250 ds Figura 6.2: Gráfico de los valores máximos de aceleración en valor absoluto para una frenada de emergencia a 50km/h. El eje vertical expresa la fuerza de aceleración experimentada en m/s2 y el eje horizontal expresa el momento de tiempo en décimas de segundo (ds) sido necesario adaptar el valor umbral de detección de accidente fijándolo en poco mas de 1G (15m/s2 ), para de este modo evitar la detección inmediata, a la vez que se tiene un valor lo suficientemente pequeño como para que pueda ser creado mediante un movimiento de mano. La prueba ha consistido en realizar un movimiento brusco con la mano, mientras se sostiene un smartphone HTC Desire con la aplicación de usuario activa, y una vez que se ha indicado el inicio de una ruta. Al realizar esta prueba, el teléfono ha experimentado una aceleración de 17,65m/s2 que es superior al valor fijado como limite, por lo que ha considerado que estamos ante un accidente y ha procedido a mostrar la pantalla de confirmación (ver figura A.5). Transcurrido el tiempo necesario para la confirmación, la aplicación ha notificado del accidente a la aplicación de gestión, la cual ha registrado el accidente y lo ha almacenado en la base de datos. En el log de la figura 6.3 podemos ver como el gestor ha recibido un incidente del usuario «[email protected]». Búsqueda y asignación del accidente Una vez realizado el paso anterior la aplicación del usuario ha activado un servicio que nos permitirá comunicarnos con el smartphone de forma remota para solicitarle diversas acciones. 6. R ESULTADOS 69 Figura 6.3: Pantalla de log del gestor tras la recepción de un incidente Mediante el uso de otro teléfono, esta vez un LG L5, con la aplicación de rescate instalada, hemos iniciado sesión con un usuario de rescate valido y se nos ha mostrado la ventana con el listado de accidentes (ver figura 6.4), en este caso solo uno. Tras seleccionar este accidente se nos muestra una ventana con tres pestañas. En la pestaña activa encontramos toda la información relacionada con el accidente que se acaba de detectar, así como los datos de la víctima (ver figura 6.5). Si intentamos pulsar en la pestaña «localización» o en «controles» nos encontramos con el mensaje que nos indica que previamente debemos tener asignado dicho accidente (ver figura B.4). Figura 6.4: Pantalla de listado de incidentes 6. R ESULTADOS 70 Figura 6.5: Pantalla de datos de incidente La asignación del accidente seleccionado la realizamos en la pestaña «Datos incidente», en la cual aparece en la parte inferior un botón que nos permite asignarnos el accidente (ver figura B.3). Localización de la víctima Para finalizar la prueba, una vez realizada la asignación indicada en el paso anterior, procedemos a pulsar en la pestaña «localización». En esta ocasión se nos muestra un mapa con un punto dibujado sobre él, que representa la localización de la víctima (ver figura 6.6). Esto nos permitiría ir a la zona indicada para tratar de localizarla. No obstante, una vez allí podríamos tener dificultades para encontrarla, por lo que realizaremos la activación del altavoz y la linterna. La activación de los componentes que nos facilitaran la localización in situ, la hemos realizado desde la pestaña «controles». Una vez que indicamos la activación de estos componentes, la pantalla de la aplicación de rescate ejecutada por el LG nos muestra que estos componentes se encuentran activos (ver figura B.6), mientras que en la aplicación de usuario ejecutada por el HTC comienza a sonar una alarma y se enciende la luz de la cámara. En la figura 6.7 podemos ver el log mostrado por el gestor durante este proceso. 6.2 Costes y recursos En esta sección se mostrarán los costes estimados, tanto materiales como de recursos humanos, en la realización de este proyecto. Además se realizará una estimación del tiempo empleado en llevarlo a cabo. Aunque la idea del proyecto surgió mucho antes, la realización del mismo comenzó en septiembre de 2012, y se han contabilizado 40 semanas empleadas para su desarrollo, con 6. R ESULTADOS Figura 6.6: Captura de pantalla de LoRAM_Rescue mostrando ubicación de la víctima Figura 6.7: Pantalla de log del gestor de la activación de los controles una dedicación media de 8 horas al día durante 5 días a la semana. Entre el tiempo dedicado al proyecto, debemos incluir también, el tiempo invertido al inicio del desarrollo en estudiar las diversas tecnologías y herramientas que han intervenido, como Android o I CE. A continuación se realiza un cálculo aproximado del coste que ha supuesto los recursos hardware utilizados en la realización de este proyecto. En el cuadro 6.1 puede verse el desglose de estos componentes con el coste estimado. En esta tabla solamente se ha tenido en cuenta el precio de cada componente, sin indicar otros gastos, como consumo eléctrico o desgaste de material. 71 6. R ESULTADOS Por otra parte los recursos y herramientas software utilizadas han sido software libre, por lo que no han supuesto ningún incremento en los costes derivado del uso de licencias privativas. El número de líneas de código totales empleadas por lenguaje de programación puede verse en el cuadro 6.2, este cuadro además incluye las líneas de código destinadas a las pruebas. La división por componentes del sistema, de estas líneas de código, puede verse en el cuadro 6.3. La realización de la estimación del coste que ha supuesto el proyecto, en cuanto a recursos humanos, puede verse en el cuadro 6.4. Para crear este cuadro se ha usado la herramienta SLOCCount que nos ha permitido calcular el tamaño del proyecto en SLOC (Source Lines Of Code) y realizar una estimación del esfuerzo según el modelo COCOMO. En esta estimación no se ha tenido en cuenta el esfuerzo realizado en la creación de esta memoria. 6.2.1 Repositorio El proyecto completo, incluido el código y la documentación, se encuentra almacenado en bitbucket.org3 . La descarga del proyecto puede realizarse en un terminal con la siguiente orden: 1 $ hg clone https :// bitbucket . org / arco_group / pfc . loram El repositorio se encuentra organizado de la siguiente forma: db: Contiene el código sql de creación de la base de datos empleada por el sistema. doc: Contiene los ficheros .tex y .bib que forman esta memoria y el anteproyecto de este trabajo. src: Contiene todo el código del sistema dividido por componentes. test: Contiene todos los test creados para la realización de este proyecto, divididos en unitarios y de integración. 3 https://bitbucket.org/ 72 6. R ESULTADOS 73 Recurso Precio/Unidad Unidades Precio Equipo sobremesa Smartphone HTC Smartphone LG 980.00 e 199.00 e 129.00 e 1 1 1 TOTAL: 980.00 e 199.00 e 129.00 e 1308.00 e Cuadro 6.1: Coste económico del hardware empleado Lenguaje No líneas Python Java XML Slice Pruebas 1064 3304 1306 179 2112 Cuadro 6.2: Líneas de código por lenguaje de programación Componente Lenguaje No líneas LoRAM Agent Java XML Python Pruebas Python Slice Pruebas Java XML Python Pruebas 1798 530 143 510 850 179 1277 1506 776 71 325 LoRAM Management LoRAM Rescue Cuadro 6.3: Líneas de código separadas por componentes del sistema Concepto Valor Total lineas físicas de código fuente Estimación del esfuerzo de desarrollo, Personas-Año (Personas-Mes) Estimación de la planificación, Años (Meses) Promedio de desarrolladores estimados (Esfuerzo/Planificación) Coste total estimado para el desarrollo (salario medio = 20.000 e/año) 8298 1.84 (22.14) 0.68 (8.11) 2.73 88.551 e Cuadro 6.4: Coste económico estimado en recursos humanos Capítulo 7 Conclusiones y trabajo futuro E n este capítulo se analiza el trabajo realizado en la elaboración de este proyecto, mostrando en que grado han sido alcanzados los objetivos marcados al comienzo de su desarrollo. Además se expondrán distintas propuestas de trabajo futuro que podrían mejorar y extender la funcionalidad del sistema desarrollado. 7.1 Objetivos alcanzados En esta sección se analizarán los objetivos expuestos en el capítulo 3, mostrando la forma en que han sido resueltos y el grado de satisfacción alcanzado con cada uno de ellos. Comenzamos recordando que el objetivo principal del proyecto era crear un sistema capaz de detectar accidentes de motocicleta e informar de dichos accidentes, y que además debía aportar mecanismos para realizar la localización de la víctima. Podemos decir sobre este objetivo, que ha sido cubierto en su totalidad con la realización de un sistema distribuido formado por tres componentes diferentes, donde dos de ellos están pensados para su ejecución en un sistema empotrado tipo smartphone, haciendo uso de los recursos que nos brindan este tipo de plataformas. Por otra parte, debemos recordar que a parte de este objetivo principal, existían una serie de objetivos específicos que detallaban de una forma más concisa lo que se esperaba del sistema. A continuación se muestra como se han afrontado estos objetivos específicos. Detección del accidente Este objetivo pretendía dotar al sistema de la capacidad de detectar de forma automática un accidente de tráfico, haciendo uso exclusivo de las capacidades del smartphone. Este objetivo se ha llevado a cabo mediante la realización de un módulo, que haciendo uso del acelerómetro del teléfono, realiza mediciones constantes de las fuerzas de aceleración experimentadas, y comprueba que no superen un umbral establecido en 3G, ya que esta demostrado que este valor es el adecuado para medir un impacto en accidente de tráfico. De esta forma, se asegura que no se produzcan falsos positivos, pero no se puede asegurar que se detecte la totalidad de los accidentes producidos. Notificación de incidentes Con este objetivo se pretendía hacer llegar los incidentes detectados a una entidad ex74 7. C ONCLUSIONES Y TRABAJO FUTURO terna que los almacenará. Para ello, se ha creado una arquitectura de objetos distribuida (véase 2.2) usando el middleware I CE, donde uno de los componentes de la comunicación es un smartphone y el otro un PC. Además se ha añadido un timer, que permite durante un periodo de tiempo cancelar el envío si fuera necesario. Asistencia remota Este objetivo pretendía que el sistema contará con un mecanismo de control remoto, sobre el teléfono de la persona que ha sufrido el accidente, con el fin de facilitar la localización in situ. Para satisfacer este objetivo, se han creado objetos distribuidos que dan acceso al manejo de varios actuadores en el smartphone. Por otro lado, se ha creado un panel en otra aplicación Android que accede a estos objetos permitiendo la manipulación de los actuadores. Localización de la víctima Con este objetivo se pretendía contar con los medios apropiados para determinar la localización de la víctima, con el fin de poder enviar un equipo de rescate al lugar indicado. Como se indicó anteriormente, el proceso de localización se ha realizado mediante el uso del sistema de localización GPS, del que disponen hoy en día todos los teléfonos inteligentes. Para el envío de la posición, expresado en latitud y longitud, se han empleado objetos distribuidos accesibles desde la aplicación de rescate. Sin embargo, mostrar estos valores al usuario de rescate, no resultaba adecuado para determinar el lugar en que se encontraba la víctima, por lo que se optó por hacer uso de GoogleMaps para representar estos valores sobre un mapa. Gestión de datos de incidentes Este objetivo recalcaba la necesidad del almacenamiento de los datos de incidentes de forma ordenada, para poder realizar consultas eficientes. Para ello, inicialmente se usaron estructuras de datos, pero posteriormente se diseñó y creó una BD que no solo almacenaba los datos de los incidentes, si no también el de los usuarios. El acceso a esta base de datos se realiza a través de un broker y el SGBD escogido ha sido MySQL. Basado en smartphone Este objetivo pretendía que el sistema fuera desarrollado para su ejecución en dispositivos tipo smartphone. Por ello se ha optado por crear las aplicaciones que requerían movilidad para su ejecución en el SO Android. Estándares libres Por último, se nos presentaba este objetivo, que pretendía que la realización del proyecto fuera llevada a cabo mediante el uso de software libre. Por ello se centro su desarrollo para los sistemas operativos GNU/Linux y Android, y se emplearon herramientas y bibliotecas libres en la creación del proyecto. 75 7. C ONCLUSIONES Y TRABAJO FUTURO 7.2 Propuestas de trabajo futuro La realización del proyecto mostrado en la presente memoria, ha supuesto la creación de un sistema de detección y asistencia en accidentes de tráfico, que a pesar de cumplir con todos los objetivos marcados, es susceptible de mejoras en cada una de las partes que forman su estructura. En esta sección se realizará un estudio de esas mejoras dividiéndolas según la parte del sistema a que correspondan. Las posibles mejoras en la aplicación de usuario serían las siguientes: Mejora del sistema de detección El sistema de detección juega un papel fundamental en el funcionamiento de L O RAM. Sin embargo, la realización de un sistema de detección realmente eficiente, que sea capaz de detectar cualquier posible incidente que se produzca por leve que sea, es una tarea ardua y que sobrepasaba los límites fijados en este proyecto. Por esta razón, se propone como trabajo futuro la mejora del sistema de detección, añadiendo a las lecturas del acelerómetro la recogida de valores de otros sensores, y la realización de un estudio, que permita determinar que condiciones deben darse para que el sistema considere que estamos ante un accidente. Alguno de los valores a tener en cuenta para ayudar a la detección de accidentes pueden ser: los cambios bruscos de velocidad, que podrían ser calculados con la ayuda del GPS, o las variaciones en la inclinación de la motocicleta, calculados mediante un acelerómetro o nivel electrónico. Mejora de la asistencia remota Los controles que ofrece actualmente el sistema para dar asistencia remota, están bastante limitados, y todos ellos están centrados en facilitar la búsqueda del accidentado en el lugar del suceso. Por ello, se propone como posible mejora añadir otro tipo de controles que permitan obtener alguna información sobre el estado de la víctima de forma remota. Por ejemplo, se podría añadir a la aplicación un cardiógrafo, para poder obtener una medida del ritmo cardiaco de la víctima, antes de desplazarse al lugar del accidente. Además, se podrían añadir otras funciones de cara a facilitar la búsqueda del accidentado, como la realización de vídeos o fotografías del lugar. Envío de incidentes por SMS La aplicación actualmente, solo permite el envío de incidentes mediante Internet. En ocasiones puede que el usuario no disponga de tarifa de datos, o que la tenga limitada. Por ese motivo, se propone que se permita adicionalmente el envío de incidentes por SMS, cuando la comunicación por Internet falle. En cuanto a la aplicación del sistema de gestión, las mejoras que podríamos considerar son las siguientes: Creación de una aplicación web para administrar el gestor Actualmente la aplicación no cuenta con una interfaz capaz de realizar labores de 76 7. C ONCLUSIONES Y TRABAJO FUTURO administración sobre el gestor y los datos que recoge. Sobre este aspecto, se propone la creación de una aplicación web para llevar a cabo estas tareas. La aplicación debería permitir gestionar los usuarios, equipos de rescate, rescatadores e incidentes, llevando un control sobre las asignaciones que se realizan. Así mismo debería ser capaz de realizar informes que puedan resultar interesantes, como que zonas son mas propensas a accidentes o cuantos incidentes ha notificado un usuario en un periodo de tiempo. De este modo, se podrían crear estadísticas y realizar una distribución más eficiente del personal de rescate, por ejemplo. Optimización del filtrado de peticiones El filtrado de peticiones consiste en un mecanismo creado con el fin de preservar la batería durante la búsqueda de una persona accidentada. Actualmente este filtrado atiende únicamente al nivel de la batería y al número de actuadores activos. Como trabajo futuro se propone optimizar este filtrado añadiendo otros factores, como el tipo de actuador que se pretende conectar, y dotarlo de capacidades para dar prioridad a ciertos actuadores sobre otros, desconectando alguno si fuera preciso. Mejora de la recogida logs Hasta ahora la generación de logs se realiza para las tareas más básicas, y no recoge demasiada información sobre los sucesos que acontecen. Se propone mejorar la recogida de estos logs añadiendo la mayor cantidad posible de información detallada sobre cada suceso, además de mejorar la forma en que se presentan. Finalmente, la aplicación del servicio de emergencias acepta las siguientes mejoras futuras: Añadir opciones de filtrado en la búsqueda de incidentes Actualmente, cuando un rescatador solicita la búsqueda de incidentes, todos los incidentes sin resolver son enviados y mostrados al rescatador. Cuando el número de estos incidentes es elevado esto supondrá trabajar con un volumen grande datos, dificultando no solo el envío, si no también la localización del incidente adecuado. Por ello, se propone como trabajo futuro proporcionar opciones de filtrado que permitan restringir los incidentes que se desean obtener. Una posible búsqueda podría ser por cercanía a una determinada zona, o por tiempo trascurrido desde que sucedió el incidente. Creación de un sistema de alertas Siempre que un usuario de rescate desea proporcionar asistencia a las víctimas de un accidente, necesita consultar el listado de accidentes y seleccionar uno de la lista. Como trabajo futuro, se propone la creación de un sistema de alertas, que permita a la aplicación de rescate ser avisada en el momento de producirse un accidente. Esto podría realizarse en Android mediante el uso del sistema de notificaciones. 77 7. C ONCLUSIONES Y TRABAJO FUTURO 7.3 Conclusión personal La realización del PFC sirve para afianzar los conocimientos adquiridos durante toda la carrera, ya que supone una oportunidad para poner en práctica todos los conceptos adquiridos durante los años de formación. Por ello representa un paso fundamental en la formación de un ingeniero, donde se pone de manifiesto no solo los conocimientos de que dispone, si no también su capacidad para adquirir nuevos conocimientos para resolver un problema. Con este proyecto se han adquirido nuevos conocimientos que o bien por la elección de asignaturas o por otros motivos no se habían adquirido durante la carrera. Entre estos conocimientos cabe destacar el aprendizaje de una nueva metodología de desarrollo y su puesta en práctica, con todo lo que esto supone. Además, se han adquirido conocimientos como la comunicación con objetos distribuidos mediante el uso del middleware I CE o el aprendizaje del lenguaje Python, que ha permitido agilizar el proceso de realización de pruebas que exigía la metodología. Con la creación de L O RAM no se pretende dar una solución definitiva a un problema tan importante como es la detección de un accidente y la localización de las víctimas, simplemente se pretende mostrar una posible forma de dar solución a este problema con un coste reducido. Por último, destacar la experiencia enriquecedora de haber trabajado en temas de actualidad, como es la programación móvil, y la satisfacción de haber completado un trabajo de ingeniería aunando los conocimientos adquiridos. 78 ANEXOS Anexo A Manual de usuario E l siguiente manual de usuario pretende mostrar todas las funcionalidades básicas de la aplicación. Se detallará el modo de acceso, así como el proceso que se debe seguir para que la aplicación nos proporcione asistencia en carretera. A.1 Login y Registro Al iniciar la aplicación se nos mostrará la ventana de «login» o inicio de sesión (ver figura A.1). Para acceder a la aplicación es necesario tener una cuenta registrada en el sistema. Figura A.1: Pantalla de inicio de sesión Si ya disponemos de una cuenta, simplemente tendremos que introducir nuestro correo electrónico y contraseña, y pulsar en el botón «enviar». Si por el contrario, aún no disponemos de una cuenta en el sistema, deberemos primero crearla pulsando en el enlace denominado «registrarse». Acto seguido se nos mostrará la pantalla con el formulario de registro (ver figura A.2) que deberemos cumplimentar debidamente para crear la cuenta. 80 A. M ANUAL DE USUARIO 81 Figura A.2: Formulario de registro Si se produce algún error, tanto al crear la cuenta como al iniciar sesión, el sistema nos mostrará un mensaje indicándonos de que se trata, y nos marcará los campos que lo han producido para que procedamos a modificarlos. A.2 Iniciar ruta Una vez que hemos accedido al sistema se nos mostrará la pantalla de inicio de ruta (ver figura A.3). Desde aquí podemos indicar al sistema que nos disponemos a iniciar un trayecto en carretera. Al pulsar el botón «iniciar ruta», si anteriormente habíamos activado la utilización de satélites GPS en el teléfono, el sistema activará el servicio interno de detección de accidentes y nos mostrará la pantalla A.4, desde la cual podemos indicar un accidente de forma manual, o dar por finalizado el trayecto. Si no habíamos activado la utilización de satélites GPS con anterioridad, al pulsar sobre el botón «iniciar ruta» se nos mostrarán las opciones de ubicación del teléfono, permitiéndonos activarlo en este momento1 . A.3 Avisar de accidente Un aviso de accidente se puede producir de dos formas: Automáticamente, producido por el sistema de detección. Manualmente, indicado expresamente por el usuario de la aplicación. 1 Debido a la nueva política de seguridad de Android no se permite la manipulación directa de los ajustes, por lo que estos deben ser modificados manualmente A. M ANUAL DE USUARIO 82 Figura A.3: Pantalla de inicio de ruta Figura A.4: Pantalla de trayecto Si se produce un aviso de accidente por cualquiera de estos dos medios, antes de que el accidente sea notificado al gestor deberá pasar por un proceso de confirmación, en el cuál el usuario tiene la ultima palabra sobre si debe ser enviado o no. La figura A.5 muestra la pantalla de confirmación. Si se muestra esta pantalla, y el usuario considera que el aviso no debe ser notificado, podrá cancelarlo pulsando el botón «cancelar aviso», y si por el contrario desea que sea enviado de inmediato, puede indicarlo pulsando el botón «confirmar aviso». A. M ANUAL DE USUARIO 83 Figura A.5: Pantalla de confirmación de aviso Si finalmente el accidente es confirmado, el sistema lanzará un servicio interno que permitirá la manipulación de las funciones remotas disponibles en el teléfono, con el fin de facilitar el rescate. Además, la aplicación mostrará al usuario la pantalla de asistencia (ver figura A.6), permitiéndole dar por finalizada esta si lo cree conveniente. No obstante, la finalización de la asistencia también podrá ser indicada de forma remota por el personal de rescate. Figura A.6: Pantalla de asistencia A. M ANUAL DE USUARIO Una vez que se ha dado por terminada la asistencia, ya sea de forma remota o indicado por el usuario, la aplicación volverá a la pantalla de inicio de ruta mostrada en la figura A.3. A.4 Cerrar sesión Para finalizar correctamente el uso de la aplicación, se debe realizar el proceso de cierre de sesión. De este modo, indicamos al gestor que dejamos de usar la aplicación, por lo que este podrá liberar nuestros datos de memoria aliviando su carga. El cierre de sesión se realiza desde la pantalla de inicio de ruta. Para realizarlo, debemos pulsar la tecla «atrás» presente en todos los smartphone, y el programa nos mostrará el cuadro de dialogo que se observa en la figura A.7. Si pulsamos aceptar la aplicación indicará al gestor nuestra salida del sistema. Figura A.7: Diálogo de cierre de sesión 84 Anexo B Manual de usuario de rescate A continuación se muestran las funcionalidades de la aplicación destinada al uso del personal de rescate. Se detallará el modo de acceso, así como los pasos ha seguir para realizar un rescate usando la aplicación. B.1 Login y Registro Al iniciar la aplicación del usuario de rescate, se nos muestra una pantalla de «login» similar a la mostrada en la aplicación de usuario (ver figura A.1), pero en lugar del correo electrónico, se nos solicitará el NIF. Para tener acceso a la aplicación, será necesario contar con una cuenta de usuario de rescate previamente registrada. Si disponemos de una cuenta de usuario de rescate, solo tendremos que introducir el número de NIF y la contraseña, y pulsar el botón «enviar», para tener acceso al sistema de rescate. De no tener aún una cuenta de usuario rescatador, podremos realizar el registro pulsando en el enlace «registrarse» de la pantalla inicial. A continuación se mostrará la pantalla con el formulario de registro de usuario de rescate, que deberemos rellenar para crear la cuenta. Durante el proceso de login o registro, pueden aparecer errores en la información introducida, de ser así, se nos mostrará un mensaje indicando el error correspondiente y el campo en el que se ha producido (ver figura B.1) Si el error producido consiste en que se intenta iniciar sesión con un usuario inexistente, la aplicación nos mostrara directamente la pantalla de registro, con el nombre del usuario rellenado con el valor que previamente habíamos introducido. B.2 Selección de Accidente Al acceder al sistema, se nos cargará un listado con los accidentes recientes que están aún sin resolver (ver figura B.2). Esta pantalla cuenta con un botón «actualizar» para que podamos recargar la vista de incidentes en cualquier momento, y poder comprobar si han entrado nuevos. 85 B. M ANUAL DE USUARIO DE RESCATE Figura B.1: Error producido durante el inicio de sesión Figura B.2: Pantalla de listado de incidentes Para comprobar los datos de un incidente debemos pulsar sobre él en la lista. De este modo se nos cargará la vista de asistencia, donde podremos consultar tanto los datos del incidente, como los de la víctima. B.3 Proceso de rescate Una vez que hemos seleccionado el incidente que deseamos atender se nos mostrará la vista de asistencia. Esta vista cuenta con tres pestañas en la parte superior, desde las que podremos realizar las acciones oportunas para realizar el rescate. Las pestañas que aparecen en la vista de asistencia son las siguientes: Datos incidente 86 B. M ANUAL DE USUARIO DE RESCATE Localización Controles A continuación mostraremos las acciones que podemos realizar en estas pestañas. B.3.1 Asignación del accidente La asignación del accidente se realiza desde la pestaña «datos incidente». Esta pestaña nos permite consultar todos los datos de la víctima y del accidente que estamos tratando. Si el incidente no esta asignado a ningún grupo de rescate, podremos indicar al sistema que deseamos asignarnos el incidente pulsando sobre el botón que aparece en la parte inferior «asignarse el incidente». Una vez que hemos indicado al sistema la asignación, aparecerá entre los datos del incidente nuestros número de grupo de rescate en rojo, como asignado al incidente, y el botón de asignación aparecerá deshabilitado (véase B.3). Figura B.3: Pantalla de datos de incidente con incidente asignado B.3.2 Petición de ubicación Para solicitar la ubicación de la víctima debemos ir a la pestaña «localización». Esta pestaña nos muestra un mapa de Google Maps1 , con un punto indicando la ubicación actual de la víctima. Para que sea posible obtener la ubicación de la víctima, debemos tener el incidente a tratar previamente asignado. De no ser así se nos mostrará un mensaje advirtiéndonos de esta necesidad (ver figura B.4). En el caso de que no sea posible obtener la ubicación de la víctima, bien por problemas con la señal GPS, como por otras causas, se nos mostrará en la pantalla un mensaje advirtiéndonos de esta situación. 1 https://maps.google.es 87 B. M ANUAL DE USUARIO DE RESCATE Figura B.4: Error de localización por incidente no asignado B.3.3 Activación de controles remotos La tercera pestaña de la vista de asistencia, nos presenta una serie de controles que pueden ser activados en el teléfono de la víctima, para facilitar su localización en el lugar del accidente (ver figura B.5). Figura B.5: Panel de control remoto Al igual que ocurría al obtener la localización, para que podamos hacer uso del panel de control, necesitamos que previamente el usuario de rescate tenga asignado el incidente. Además de los botones de activación, el panel presenta una serie de reguladores, que nos permiten manipular el comportamiento de los actuadores, antes de activarlos. 88 B. M ANUAL DE USUARIO DE RESCATE La pantalla de control además nos muestra información sobre el estado, apagado o encendido, de cada actuador, en la figura B.6, se nos muestra la aplicación con el altavoz y la luz encendidos. Figura B.6: Panel de control remoto con controles activos B.4 Cerrar sesión La aplicación de usuario de rescate, al igual que la de usuario normal, debe ser cerrada correctamente. Por ello se debe realizar el proceso de cierre de sesión, para indicar al gestor que abandonamos el sistema. En el caso de esta aplicación, el cierre de sesión se realiza desde la pantalla del listado de incidentes. Para realizarlo, debemos pulsar la tecla «atrás» y el programa nos mostrará un cuadro de dialogo, similar al mostrado en la aplicación de usuario al cerrar sesión (ver figura A.7). Si pulsamos aceptar la aplicación indicará al gestor que hemos abandonado el sistema. 89 Anexo C Hello World, Ice for Android E l siguiente código es un ejemplo sencillo o lo que podríamos denominar «hello world» sobre el uso de I CE en Android. Este código muestra una estructura C/S en la que las dos partes que intervienen en la comunicación, están desarrolladas sobre la plataforma Android. También se mostrará el código S LICE que define las interfaces de comunicación entre ambas partes. Para que la comunicación sea posible, además se deberán asignar permisos para el uso de Internet en el Manifest del cliente y el servidor: <uses-permission android:name=“android.permission.INTERNET”/> C.1 S LICE El ejemplo cuenta con una sola interfaz llamada «Hello», que esta compuesta por una única función encargada de enviar un mensaje sin esperar ningún valor de retorno. 1 2 3 4 5 module Example { interface Hello { void puts ( string message ) ; }; }; Listado C.1: Slice para ejemplo de uso de Ice en Android C.2 Cliente El cliente cuenta con una única activity (ver sección 2.3.1) formada por un cuadro de texto y un botón. Al pulsar el botón se realiza una llamada a la función «puts» indicando como cadena de entrada la obtenida del cuadro de texto. En el listado C.2 puede verse el código asociado a la activity y en C.3 la definición en XML de su interfaz de usuario. 1 package israel . androidclient ; 3 import Example . HelloPrx ; import Example . HelloPrxHelper ; 4 90 C. H ELLO W ORLD , I CE FOR A NDROID 12 import import import import import import import import 14 public class MainActivity extends Activity { 5 6 7 8 9 10 11 16 17 19 20 22 23 24 25 27 28 29 31 32 33 34 35 36 37 android . os . Bundle ; android . os . Build . VERSION ; android . app . Activity ; android . view . Menu ; android . view . View ; android . view . View . OnClickListener ; android . widget . Button ; android . widget . EditText ; private Ice . Communicator _broker ; private HelloPrx _hello ; private EditText _txvMessage ; private Button _btnSend ; @Override protected void onCreate ( Bundle s av ed In st an ce Sta te ) { super . onCreate ( s av ed Ins ta nc eS ta te ) ; setContentView ( R . layout . activity_main ) ; // Activity controllers _txvMessage = ( EditText ) findViewById ( R . id . txvMessage ) ; _btnSend = ( Button ) findViewById ( R . id . btnSend ) ; // Communication setting if ( VERSION . SDK_INT == 8) { // android . os . Build . VERSION_CODES . FROYO (8) // // Workaround for a bug in Android 2.2 ( Froyo ) . // // See http :// code . google . com / p / android / issues / detail ? id =9431 // java . lang . System . setProperty ( " java . net . preferIPv4Stack " , " true " ) ; java . lang . System . setProperty ( " java . net . p r ef e r IP v 6 Ad d r es s e s " , " false " ) ; 39 40 41 } 43 i n i t i a l i z e C o m m u n i c a t o r () ; 45 _hello = this . createProxy () ; 47 // Controllers setting _btnSend . s et On Cl ic kLi st en er ( new OnClickListener () { 48 91 C. H ELLO W ORLD , I CE FOR A NDROID @Override public void onClick ( View v ) { String message = _txvMessage . getText () . toString () ; _hello . puts ( message ) ; } 49 50 51 52 53 }) ; 54 55 } 57 @Override public boolean o n Cr e a te O p ti o n sM e n u ( Menu menu ) { // Inflate the menu ; this adds items to the action bar if it is present . getMenuInflater () . inflate ( R . menu . activity_main , menu ) ; return true ; } 58 59 60 61 62 64 65 66 @Override public void onDestroy () { super . onDestroy () ; if ( _broker != null ) { try { _broker . destroy () ; } catch ( Ice . LocalException e ) { e . printStackTrace () ; } } 68 69 70 71 72 73 74 75 76 } 78 private void i n i t i a l i z e C o m m u n i c a t o r () { try { _broker = Ice . Util . initialize () ; } catch ( Ice . LocalException e ) { e . printStackTrace () ; } catch ( Exception e ) { System . err . println ( e . getMessage () ) ; } } 79 80 81 82 83 84 85 86 88 89 90 91 private HelloPrx createProxy () { // replace IP with the server ’s IP address String s = " hello -t : tcp -h 192.168.1.10 -p 10000 " ; Ice . ObjectPrx base = _broker . stringToProxy ( s ) ; return HelloPrxHelper . checkedCast ( base ) ; 93 94 } 92 C. H ELLO W ORLD , I CE FOR A NDROID 95 } Listado C.2: Cliente de ejemplo de Ice for Android 1 2 3 4 5 6 7 < LinearLayout xmlns:android = " http: // schemas . android . com / apk / res / android " xmlns:tools = " http: // schemas . android . com / tools " a n d r o i d : l a y o u t _ w i d t h = " match_parent " a n d r o i d : l a y o u t _ h e i g h t = " match_parent " a nd r o i d: o r ie n t at i o n = " vertical " android:gravity = " center " tools:context = " . MainActivity " > < EditText android:id = " @ + id / txvMessage " a n d r o i d : l a y o u t _ w i d t h = " wrap_content " a n d r o i d : l a y o u t _ h e i g h t = " wrap_content " and roid:i nputTy pe = " text " android:text = " @string / hello_world " / > < Button android:id = " @ + id / btnSend " a n d r o i d : l a y o u t _ w i d t h = " wrap_content " a n d r o i d : l a y o u t _ h e i g h t = " wrap_content " android:text = " @string / btnSend " / > 9 10 11 12 13 14 15 16 17 18 19 21 </ LinearLayout > Listado C.3: Definición en XML de la interfaz del cliente C.3 Servidor En la parte del servidor además de la activity C.4 necesitamos implementar la interfaz «Hello» C.5 definida en el fichero S LICE. La activity cuenta con un botón que al ser pulsado muestra en un visor de texto el último mensaje recibido. En el listado C.6 se muestra el fichero XML que define la User Interface (UI). 1 package israel . androidserver ; 3 import import import import import import import import import 4 5 6 7 8 9 10 11 Example . HelloPrx ; android . os . Bundle ; android . os . Build . VERSION ; android . app . Activity ; android . view . Menu ; android . view . View ; android . view . View . OnClickListener ; android . widget . Button ; android . widget . TextView ; 93 C. H ELLO W ORLD , I CE FOR A NDROID 13 public class MainActivity extends Activity { 16 private Ice . Communicator _broker ; private Ice . ObjectAdapter _adapter ; 18 private HelloI _hello ; 20 private TextView _txvMessage ; private Button _btnCheck ; 15 21 23 24 25 26 28 29 30 32 33 34 35 36 37 38 @Override protected void onCreate ( Bundle s av ed In st an ce Sta te ) { super . onCreate ( s av ed Ins ta nc eS ta te ) ; setContentView ( R . layout . activity_main ) ; // Activity controllers _txvMessage = ( TextView ) findViewById ( R . id . txvMessage ) ; _btnCheck = ( Button ) findViewById ( R . id . btnCheck ) ; // Communication setting if ( VERSION . SDK_INT == 8) { // android . os . Build . VERSION_CODES . FROYO (8) // // Workaround for a bug in Android 2.2 ( Froyo ) . // // See http :// code . google . com / p / android / issues / detail ? id =9431 // java . lang . System . setProperty ( " java . net . preferIPv4Stack " , " true " ) ; java . lang . System . setProperty ( " java . net . p r ef e r IP v 6 Ad d r es s e s " , " false " ) ; 40 41 42 } 44 i n i t i a l i z e C o m m u n i c a t o r () ; 46 _hello = new HelloI () ; _hello . add_to ( _broker , _adapter ) ; 47 49 50 51 52 53 54 55 // Controllers setting _btnCheck . s et OnC li ck Li st en er ( new OnClickListener () { @Override public void onClick ( View v ) { _txvMessage . setText ( _hello . get_message () ) ; } }) ; 94 C. H ELLO W ORLD , I CE FOR A NDROID 57 } 59 @Override public boolean o n Cr e a te O p ti o n sM e n u ( Menu menu ) { // Inflate the menu ; this adds items to the action bar if it is present . getMenuInflater () . inflate ( R . menu . activity_main , menu ) ; return true ; } 60 61 62 63 64 @Override public void onDestroy () { super . onDestroy () ; 66 67 68 if ( _broker != null ) { try { _broker . destroy () ; } catch ( Ice . LocalException e ) { e . printStackTrace () ; } } 70 71 72 73 74 75 76 77 78 } 80 private void i n i t i a l i z e C o m m u n i c a t o r () { try { _broker = Ice . Util . initialize () ; _adapter = _broker . c r e a t e O b j e c t A d a p t e r W i t h E n d p o i n t s ( " adapter " , " tcp -p 10000 " ) ; 81 82 83 _adapter . activate () ; } catch ( Ice . LocalException e ) { e . printStackTrace () ; } catch ( Exception e ) { System . err . println ( e . getMessage () ) ; } 85 86 87 88 89 90 } 91 92 } Listado C.4: Servidor de ejemplo de Ice for Android 1 package israel . androidserver ; 3 import Example . HelloPrx ; import Example . HelloPrxHelper ; import Example . _HelloDisp ; 4 5 95 C. H ELLO W ORLD , I CE FOR A NDROID 6 7 8 10 import Ice . Communicator ; import Ice . Current ; import Ice . ObjectAdapter ; public class HelloI extends _HelloDisp { 12 private HelloPrx _proxy ; 14 private String _message ; 16 public HelloI () { this . _proxy = null ; } 17 18 public HelloPrx add_to ( Communicator broker , ObjectAdapter adapter ) { _proxy = HelloPrxHelper . uncheckedCast ( adapter . add ( this , broker . stringToIdentity ( " hello " ) ) ) ; 20 21 return _proxy ; 23 24 } 26 @Override public void puts ( String message , Current __current ) { _message = message ; } 27 28 29 public String get_message () { return _message ; } 31 32 33 36 } Listado C.5: Implementación de la interfaz Hello 1 2 3 4 5 6 7 9 10 < LinearLayout xmlns:android = " http: // schemas . android . com / apk / res / android " xmlns:tools = " http: // schemas . android . com / tools " a n d r o i d : l a y o u t _ w i d t h = " match_parent " a n d r o i d : l a y o u t _ h e i g h t = " match_parent " a nd r o i d: o r ie n t at i o n = " vertical " android:gravity = " center " tools:context = " . MainActivity " > < TextView android:id = " @ + id / txvMessage " 96 C. H ELLO W ORLD , I CE FOR A NDROID 11 12 13 14 15 16 17 18 19 a n d r o i d : l a y o u t _ w i d t h = " wrap_content " a n d r o i d : l a y o u t _ h e i g h t = " wrap_content " android:text = " " / > < Button android:id = " @ + id / btnCheck " a n d r o i d : l a y o u t _ w i d t h = " wrap_content " a n d r o i d : l a y o u t _ h e i g h t = " wrap_content " android:text = " @string / btnCheck " / > </ LinearLayout > Listado C.6: Definición en XML de la interfaz del servidor 97 Bibliografía [Anda] Android. Android Develop - API Guides. url: http://developer.android. com/guide/components/fundamentals.html. [Andb] Android. Android Develop - Tools. url: http://developer.android.com/ sdk/index.html. [Andc] Android. Location and Maps. url: http://developer.android.com/guide/ topics/location/index.html. [Andd] Android. Sensors Overview. url: http://developer.android.com/guide/ topics/sensors/sensors overview.html. [BBG+ 10] C. Blé, J. M. Beas, J Gutiérrez, F Reyes, y G Mena. Diseño agil con TDD. 2010. [Bec02] K. Beck. Una explicación de la programación extrema: Aceptar el cambio. Addison Wesley, 2002. [Cit12] Citroen. LDWS, 2012. url: http://www.citroen.es/universo-citroen/ tecnologia/seguridad/LDWS/#/universo-citroen/tecnologia/ seguridad/LDWS/. [CLM+ 03] B. Cascales, P. Lucas, J.M Mira, A.J Pallares, y S Sánchez-Pedreño. El libro de latex. Prentice Hall, 2003. [Con11] Continental. Two eyes are better than one - The stereo camera, 2011. url: http://www.conti-online.com/generator/www/com/en/continental/ pressportal/themes/press releases/3 automotive group/ chassis safety/press releases/pr 20110504 stereo camera en. html. [dlSdlIO09] Observatorio Regional de la Sociedad de la Información (ORSI). Sistemas de localización e información geográfica. Technical report, 2009. [Eura] Comision Europea. eCall: Time saved = lives saved. url: http://ec.europa. eu/information society/activities/esafety/ecall/index en.htm. 98 BIBLIOGRAFÍA 99 [Eurb] Comisión Europea. Imagen del funcionamiento de eCall. url: http://ec.europa.eu/information society/activities/esafety/ doc/ecall/ecall adac en 2012.pdf. [Eur13] Comisión Europea. eCall: La llamada de emergencia automática para accidentes de tráfico será obligatoria en los vehículos a partir de 2015. 2013. url: http://europa.eu/rapid/press-release IP-13-534 es.htm. [Foua] Python Software Foundation. The Python Tutorial. url: http://docs.python. org/2/tutorial/. [Foub] The Eclipse Foundation. url: http://www.eclipse.org/. [jt] junit team. JUnit wiki. url: https://github.com/junit-team/junit/wiki. [Kac] T. Kaczanowski. Practical Unit Testing with JUnit and Mockito. [LPFF08] J. A. Lahausse, D. Psych, B. N. Fildes, y M. P. Fitzharris. The potential for automatic crash notification systems to reduce road fatalities. Ann Adv Automot Med, 2008. [Nos] Testing with nose. testing.html. [OnS] OnStar. Automatic chash response. portal/emergencyexplore. [Org13] World Health Organization. Global status report on road safety. Technical report, 2013. [O’S] B. O’Sullivan. Mercurial: The Definitive Guide. red-bean.com/read/. [Par00] A.M. Parera. Sistemas de Seguridad y Confort en Vehículos Automóviles. Marcombo, Boixareu, 2000. [pla] Google play. Cerberus anti theft. url: https://play.google.com/store/ apps/details?id=com.lsdroid.cerberus. [Som05] Ian Sommerville. Ingeniería del software, Séptima edición. Addison Wesley, 2005. [Sta] Richard Stallman. GNU Emacs Manual, edición Sixteenth. [Sub12] Subaru. EyeSight, 2012. url: http://subaru.com.au/about/eyesight. url: https://nose.readthedocs.org/en/latest/ url: https://www.onstar.com/web/ url: http://hgbook. BIBLIOGRAFÍA 100 [Vil] D. Villa. Python-doublex. url: https://bitbucket.org/DavidVilla/ python-doublex/wiki/Home. [VMA12] D. Villa, F. Moya, y O. Aceña. Computación Distribuida Heterogénea con ZeroC Ice. 2012. [Vol12] Volvo. City Safety, 2012. url: http://www.volvocars.com/es/footer/ Pages/ CitySafetyTerms.aspx. [Wela] D. Wells. The Rules of Extreme Programming. extremeprogramming.org/rules.html. url: http://www. [Welb] D. Wells. The Values of Extreme Programming. extremeprogramming.org/values.html. url: http://www. [WTT+ 11] J. White, C. Thompson, H. Turner, B. Dougherty, y D. C. Schmidt. WreckWatch: Automatic Traffic Accident Detection and Notification with Smartphones. Mobile Networks and Applications, 2011. [Zera] ZeroC. Ice for Android. url: http://www.zeroc.com/android.html. [Zerb] ZeroC. The Internet Communications Engine. url: http://www.zeroc.com. [Zer11] ZeroC. Ice 3.4.2 Documentation, 2011. Este documento fue editado y tipografiado con LATEX empleando la clase arco-pfc que se puede encontrar en: https://bitbucket.org/arco group/arco-pfc [Respeta esta atribución al autor]
