Detección de rutinas : internet of people. Prueba de concepto

ESCUELA'TÉCNICA'SUPERIOR'DE'INGENIERÍA'INFORMÁTICA' Grado'en'Ingeniería'del'Software' ' ' ' ' ' ' Detección(de(rutinas:(Internet(of(People.(Prueba(de(concepto(( Routine(detection:(Internet(of(People.(A(proof(of(concept' ' ' ' Realizado'por' Alejandro(Pérez(Vereda' Tutorizado'por' Carlos(Canal(Velasco' Departamento' Lenguajes(y(Ciencias(de(la(Computación( ' ' ' ' UNIVERSIDAD'DE'MÁLAGA' MÁLAGA,'Julio'2015' ' ' ' Fecha'defensa:'' El'Secretario'del'Tribunal'' ' ! Agradecimientos Deseo expresar mi más sincero agradecimiento al Profesor D. Carlos Canal Velasco, tutor de la presente memoria, por su estímulo, dedicación y valiosas orientaciones que me ha ofrecido en todo momento. A mis compañeros de la Universidad de Extremadura por la colaboración y ayuda recibidas, en especial a Pablo Pérez Lozano y Juan Manuel Murillo Rodríguez. A mi amigo Albert Munné Fuentes por la ayuda recibida con el diseño tanto de la aplicación como de la presente memoria. Por último, un agradecimiento especial a mi familia por el apoyo durante toda la elaboración del trabajo. ! ! ! ! Resumen: El principal objetivo de Internet of Things (IoT) es integrar las tecnologías informáticas en el quehacer cotidiano de las personas, facilitando su interacción con un entorno de dispositivos interconectados, pero el estado actual del arte hace que dicha interacción esté aún lejos de resultar trivial, precisando de continua intervención del usuario. Como alternativa a esta situación, iniciativas emergentes como la de Internet of People (IoP) pretenden integrar de forma más efectiva el IoT en la vida de las personas. En línea con este propósito, el modelo People as a Service (PeaaS) facilita estas tareas por medio del uso del teléfono móvil como interfaz del usuario con el IoT y haciendo uso del contexto del usuario del mismo. PeaaS permite elaborar un perfil sociológico del usuario, que puede ser explotado por el mismo y servido a terceros de forma segura y controlada. En este trabajo presentamos una aplicación móvil para la supervisión de personas afectadas de alzhéimer mediante el aprendizaje y monitorización de sus rutinas como prueba de concepto del modelo PeaaS, teniendo como resultado una funcionalidad que va mucho más allá de la ofrecida por otros productos similares en este campo, y una tecnología que es base para infinidad de aplicaciones que provoquen el avance hacia IoP. Palabras claves: Internet of People, People as a Service, Detección de rutinas, Alzhéimer, Inferencia de datos. Abstract: The Internet of Things (IoT) main point is to integrate computer technology in people’s ordinary life, easing their interaction with an environment of interconnected devices, but the actual state of the art makes this interaction be far yet from being trivial, requiring a continuous user’s intervention. As an alternative to this situation, emergent alternatives as the Internet of People (IoP) aim to integrate in an effective way the IoT in people life. Following this purpose, the People as a Service (PeaaS) model pretends to simplify these tasks by using the mobile phone as an user’s interface with IoT and taking advantage from the mobile’s user context. PeaaS enables elaborating a sociologic profile for the user, which he/she can use and offer to third parties in a safe and controlled way. In this work, we present a mobile application for the supervision of people affected with Alzheimer by learning and monitoring their routines as a proof of concept of PeaaS model, obtaining as a result a functionality that goes further from the ones which similar products today offer, and a base technology for a wide variety of mobile applications that will cause the evolution to IoP. Keywords: Internet of People, People as a Service, Routine detection, Alzheimer, Data inference. Índice 1.(Introducción(..................................................................................................................................................(9' 1.1'Motivación'.................................................................................................................................................................'10' 1.2'Objetivos'....................................................................................................................................................................'11' 1.3'Tecnologías'utilizadas'..........................................................................................................................................'12' 2.(Una(aplicación(para(enfermos(de(alzhéimer(...................................................................................(15' 2.1'Actores'........................................................................................................................................................................'18' 2.2'Requisitos'..................................................................................................................................................................'18' 2.3'Arquitectura'.............................................................................................................................................................'21' 2.4'Estructura'de'Datos'...............................................................................................................................................'31' 2.5'Procedimiento'de'análisis'..................................................................................................................................'35' 2.6'Optimización'de'recursos'...................................................................................................................................'40' 3.(Proceso(de(desarrollo(.............................................................................................................................(43' 4.(Trabajos(relacionados(............................................................................................................................(49' 5.(Conclusiones(..............................................................................................................................................(53' 5.1'Trabajos'Futuros'....................................................................................................................................................'53' 6.(Referencias(.................................................................................................................................................(57' Introducción 9 1. Introducción A día de hoy, el móvil y sus aplicaciones sociales (email, mensajería, redes sociales…) se han convertido en un gran pilar de nuestra vida. Por ellas expresamos todo tipo de cosas, desde como nos sentimos o nuestras posturas éticas o sociales, hasta donde y con quien hemos estado o que hemos comido [1]. Se han convertido en nuestra principal herramienta de expresión, interacción y de obtención de información. Un concepto del que se habla mucho en la actualidad es el Internet of Things (IoT), cuyo principal objetivo es integrar las tecnologías informáticas en el quehacer cotidiano de las personas [2, 3], haciéndoles la vida más sencilla, de forma que, por ejemplo, pueda programarse que se encienda de forma remota la cafetera utilizando el móvil para tener el café hecho al levantarnos o, incluso planificar esta tarea de acuerdo con nuestros hábitos diarios. Sin embargo, la forma en que las tecnologías relacionadas con este concepto se aprovechan en la actualidad es notablemente susceptible de mejora. Un aspecto importante a tener en cuenta para el futuro progreso de estas tecnologías es la existencia aún de un salto entre la red donde la información es tratada e intercambiada y la realidad de la vida física y su contexto [4]. En general, el usuario necesita configurar diversos parámetros del sistema en cuestión de forma manual, parámetros que debe reconfigurar cuando el contexto cambia, de forma que lo que inicialmente se piensa como una comodidad, se vuelve algo tedioso y con una integración mínima con nuestra vida. El resultado es que, lejos de hacer que la tecnología trabaje para las personas, esta obliga a las personas a estar pendientes de introducir nuevas órdenes o modificar la planificación siempre que se produzca un cambio inesperado en su día a día. En un escenario más adecuado, la tecnología debería tener en cuenta el contexto de las personas a las que debe servir, aprendiendo de dicho contexto y realizando acciones de forma proactiva de acuerdo con su situación y expectativas en cada momento. Así cuando la persona va a levantarse más tarde de lo habitual, le gustaría que el café empezara a hacerse en el momento justo para tomárselo caliente al levantarse, o si va a alguna parte en busca de ocio, pueda contactar con más gente interesada o saber cual es el mejor lugar para ir en ese momento. Un escenario más adecuado, que resolviera estas deficiencias, podría ser el planteado por el modelo de People as a Service (PeaaS) [5], un modelo social que pone su énfasis en el usuario como proveedor de servicios y al que permite controlar la información que fluye de su dispositivo, dando especial importancia a aspectos de privacidad y de Una aplicación para enfermos de alzhéimer 16 Figura 2. Cifra de personas con alzhéimer en el mundo. Según se puede ver en la figura 2, existen alrededor de 47,5 millones de personas afectadas por alzhéimer en el mundo, y se estima que esta cifra alcanzará los 80 millones dentro de 20 años. Esta enfermedad no solo afecta a los pacientes, sino que también condiciona la vida de sus cuidadores, ya que les obliga a estar constantemente pendientes de ellos y preocupados por su situación. Con objeto de contribuir a la mejora de esta situación, nos planteamos el desarrollo de una aplicación para dispositivos móviles basada en PeaaS y capaz de aprender las rutinas de desplazamiento del usuario. La motivación para ello fue doble. Por un lado la penetración cada vez mayor de los dispositivos móviles en la sociedad incluso entre la población de edad más avanzada; además con la creación de nuevos dispositivos que cada vez son más personales y se integran de forma más discreta y cómoda en nuestra vida, como los relojes, pulseras, gafas... Por otro, las ventajas que proporciona PeaaS para potenciar el uso del contexto de los usuarios de estos dispositivos móviles y mejorar la integración de dichos usuarios con su entorno. La aplicación diseñada cuenta con dos componentes funcionales distintos, pero comunicados entre sí, en función del tipo de usuario, puede ser un paciente enfermo de alzhéimer o su cuidador: Una aplicación para enfermos de alzhéimer 17 • Dispositivo Paciente: Es el componente principal y en el que se centra la actividad de PeaaS. Se trata de una aplicación Android que reside en el dispositivo del paciente. Valiéndose de la información facilitada por el GPS del dispositivo, la aplicación registra los desplazamientos del usuario para posteriormente analizarlos y ser capaz de aprender y detectar las rutinas de desplazamiento diarias del usuario, llegando así incluso a predecir a donde va a dirigirse el usuario y en que momento del día lo hará. La utilidad de la aplicación viene al ir comprobando continuamente si los desplazamientos que va realizando son acordes a dichas rutinas, y en caso contrario, emitir avisos tanto al paciente como a su cuidador según diferentes niveles de alarma que pueden ser configurados. CareMe utiliza, analiza y pone al servicio de otros su contexto. En este caso los otros serían los cuidadores, que de forma segura podrán acceder a la información de los desplazamientos del paciente. Figura 3. Aplicación CareMe. • Dispositivo Cuidador: De nuevo es una aplicación Android, que en este caso reside en el dispositivo del cuidador. A través de ella el cuidador puede realizar un seguimiento de la posición del paciente y configurar de forma remota la aplicación de este, indicando los niveles de alarma deseados, las actuaciones a Una aplicación para enfermos de alzhéimer 18 llevar a cabo en la detección de cada nivel, o introduciendo nuevos compromisos o citas puntuales que el paciente pueda tener, como una cita con el médico. La aplicación además se encarga de recibir y procesar las alarmas emitidas por el otro componente dándoles el tratamiento adecuado y mostrándolas al usuario, permitiéndole realizar una serie de acciones en reacción a esta como un seguimiento en tiempo real, llamar al paciente, o llamar a urgencias de forma rápida. En la figura 3 se muestra una captura de ambas aplicaciones con el diseño final de sus interfaces gráficas. 2.1 Actores Habrá dos actores además del sistema que tendrán acceso a este. El usuario principal, que será el paciente de alzhéimer. Es sobre quien el sistema trabaja y obtiene las rutinas, pero recordemos que la idea es tratar de reducir al máximo la interacción de este con el sistema, tratando que la introducción de datos sea mínima o nula, es el sistema automáticamente quien deberá aprender del paciente sin que este se dé cuenta si quiera. Sin embargo, si se le permitirá en cualquier caso hacer algunas consultas en el móvil, o realizar algunas acciones de emergencia como alertar al cuidador, o iniciar una navegación a casa. El otro actor es el responsable del usuario, que nosotros hemos denominado cuidador (caregiver, en inglés) que tendrá todo el control sobre la supervisión del anterior, además de poder realizar cambios en el sistema, llegando incluso a poder introducir citas concretas a las que el usuario deberá acudir para que se consideren como una rutina más, pero pueden ser sin ningún tipo de periodicidad. 2.2 Requisitos A continuación se citan los requisitos funcionales y no funcionales a ser tenidos en cuenta en la producción de la aplicación con el fin de intentar definir de forma más concreta el sistema con los requerimientos mínimos que este debería cumplir. Requisitos Funcionales Mínimos 1. El usuario podrá consultar sus rutinas. Al abrir la aplicación se le mostrará una lista de los lugares a los que asistirá ese día y a la hora a la que tendrá que salir para llegar a ellos. Una aplicación para enfermos de alzhéimer 19 2. El sistema creará notificaciones para cada situación según su riesgo. Si el paciente se pierde o entra en situación de riesgo, el sistema se encargará de detectarlo y emitir una alerta al usuario con opción de iniciar una navegación a casa. 3. El sistema avisará a los contactos de emergencia en situaciones de riesgo. Si el paciente se pierde o entra en situación de riesgo, el sistema se encargará de detectarlo y enviar la correspondiente alerta al cuidador. 4. El sistema calculará constantemente las rutinas del usuario. El sistema será capaz de aprender, sin necesidad de interacción del usuario, sus rutinas habituales de desplazamiento diarias y actualizarlas de forma automática frente a cualquier cambio en ellas. 5. El sistema gestionará las rutinas del usuario. 5.1. El sistema consultará rutinas 5.2. El sistema creará rutinas. 5.3. El sistema actualizará rutinas. 5.4. El sistema eliminará rutinas. 6. El sistema detectará desvíos en la rutina del usuario. El sistema monitorizará todos los movimientos del paciente para contrastarlos con sus rutinas y detectar en su caso el desvío del paciente si se sale de ellas. 7. El sistema almacenará los movimientos del usuario. El sistema mantendrá un histórico de los desplazamientos realizados por el paciente para su análisis y recuperación en caso de fallo. 8. El sistema eliminará datos antiguos. El sistema deberá borrar datos del histórico que ya sean bastante antiguos y hayan sido tenidos en cuenta en el análisis con la intención de optimizar el uso de la memoria del teléfono. 9. El responsable podrá recibir notificaciones del sistema. El dispositivo del cuidador recibirá notificaciones de alertas del paciente si este se desvía de una rutina o está en peligro porque se ha perdido. Requisitos Funcionales Opcionales 1. El usuario podrá actualizar sus notificaciones ajustando su intensidad. El usuario podrá establecer si quiere que el dispositivo quede en silencio, solo vibre, o vibre y suene, según el tipo de alarma. Una aplicación para enfermos de alzhéimer 20 2. El responsable podrá gestionar las rutinas, con la frecuencia que tendrán y el lugar y la hora en la que tendrán lugar. El cuidador podrá introducir modificar o eliminar cualquier rutina, dándole una frecuencia, o sin ella, siendo una cita puntual del paciente. 2.1. El responsable podrá consultar rutinas. 2.2. El responsable podrá crear rutinas. 2.3. El responsable podrá actualizar rutinas. 2.4. El responsable podrá eliminar rutinas. 3. El responsable podrá gestionar la lista de contactos de emergencia del usuario. El responsable tendrá el control sobre la lista de contactos de emergencia con los que el paciente podrá contactar en caso de algún problema o de que se haya perdido. 3.1. El responsable podrá crear un nuevo contacto. 3.2. El responsable podrá actualizar un contacto. 3.3. El responsable podrá eliminar un contacto. 3.4. El responsable podrá consultar los contactos. Requisitos No Funcionales 1. El sistema debe estar desarrollado en plataforma Android. Es la plataforma que se ha elegido para el desarrollo en un principio, debido a que se trata de la plataforma más asequible para los usuarios, con el objetivo de que cualquiera pueda tener acceso a la aplicación sin realizar una gran inversión monetaria. 2. El sistema debe cumplir con la LOPD. Es obligatorio cumplir con la Ley Orgánica de Protección de Datos ya que trabajamos con datos sensibles de los usuarios. 3. El sistema se adaptará a los recursos disponibles. El sistema debe ser lo más eficiente posible optimizando la utilización de los recursos del dispositivo móvil, que como sabemos, son escasos. Aunque todos estos son requisitos para una aplicación final comercial, hay algunos de ellos que se han considerado de menor relevancia para este estudio, y aún no están integrados en la fase actual de la aplicación, son los denominados opcionales. Sin embargo deberán ser tenidos en cuenta para las versiones futuras de la misma y disponer de una App de funcionalidad completa. Una aplicación para enfermos de alzhéimer 21 2.3 Arquitectura El sistema se ha desarrollado con el mayor nivel de autonomía posible. Este es capaz de tomar decisiones y adaptarse a los recursos y situaciones que se den en el dispositivo. Para cumplir con esto y con los requisitos anteriormente descritos se ha desarrollado el sistema de forma que es capaz de realizar varias tareas independientes y de forma simultánea. Si examinamos detenidamente los requisitos, podemos ver que la aplicación en sí, debe realizar cuatro tareas fundamentales que engloban todos los requisitos. Estas cuatro tareas que distinguimos son la de monitorización, que es la que comprende toda la detección de desvíos del usuario y la vigilancia del mismo; la de acumulación, que consiste en ir almacenando el histórico de movimientos que luego se analizará; la de análisis, que es la que podemos llamar tarea de aprendizaje, usa los datos recogidos por la tarea de acumulación para llegar a obtener las rutinas del usuario; y por último, la de actuación, que es la encargada de mostrar notificaciones y enviar alertas a los contactos de emergencia si se diera el caso. Figura 4. Arquitectura de la aplicación. Una vez definidas las distintas tareas, las únicas que realmente necesitan ser simultáneas son la de monitorización y la de acumulación, ya que necesitan estar en funcionamiento constante durante todo desplazamiento. Es por esto, por lo que se decidió usar una arquitectura basada en tres componentes, con diferentes Una aplicación para enfermos de alzhéimer 22 características, pero comunicados entre sí de la forma en que se muestra en la figura 4. Estos componentes son: Monitorización/Acumulación Este es el componente que como hemos dicho consta de dos tareas que se van realizando de forma simultanea. Estas tareas son la de acumulación de histórico y la de monitorización de los desplazamientos del usuario. Al ser un componente que necesita estar en ejecución de forma constante, se decidió implementarlo en forma de un servicio Android, que permanece activo aunque se cierre la ventana de la aplicación, así conseguimos que las dos tareas que realizan no sean interrumpidas y realice correctamente su trabajo. La forma en que se decidió implementar este componente es con un Listener, en este caso de Localización. Este Listener nos permite configurarlo de varias maneras para poder ajustarlo a nuestros requerimientos. El que nos atañe, como va a estar activo todo el tiempo, nos interesa que el GPS que vaya a utilizar consuma lo mínimo posible, pero siempre guardando un cierto compromiso con la exactitud de la posición del usuario. Una vez configurado así, el Listener usará la mejor opción disponible atendiendo a esos requisitos. El último aspecto a configurar que queda es si necesitamos una muestra cada cierto tiempo, o cada vez que se desplace cierta distancia. Para esta tarea se escogió la opción de coger una muestra cada cierta distancia, por el ahorro de batería y memoria, la otra opción sería antagónica. De esta forma, mientras el usuario permanezca quieto en casa, dentro de la distancia especificada al Listener, conseguimos que este componente esté en reposo, ni monitoriza ni acumula histórico, ya que sería inútil. Además esta forma de acumular histórico, es mucho más eficiente ya que solo recogemos muestras importantes, y esto es de bastante ayuda a la hora de analizarlas, haciendo dicho proceso bastante más simple. Bien, pues ya definida la estructura de este componente y su forma de actuar, podemos explicar, como realmente trabaja. Para empezar, la acumulación es bastante fácil, cada vez que el usuario recorre la distancia x expresada anteriormente, se produce una llamada al Listener, y es aquí donde aprovechamos para esta primera tarea, recogemos una muestra de latitud y longitud y la almacenamos en cuanto a una fecha y una hora en la base de datos. Una aplicación para enfermos de alzhéimer 23 Justo después de esta operación, aprovechando la misma llamada, llevamos a cabo el proceso de monitorización. El proceso de monitorización esta pensado para ser lo más eficiente y flexible posible, refiriéndonos con flexible, a la flexibilidad de movimiento del paciente a la hora de realizar sus desplazamientos por distintos caminos, por ejemplo. Esto se consigue de la siguiente forma. Como tenemos que aprovechar la llamada del Listener para actuar, el algoritmo se diseñó de forma que no cada vez que el usuario avanza unos pocos metros se haga todo el proceso de monitorización, lo cual sería muy costoso. Lo que se implementó fue una especie de contador, de forma que pudiéramos hacer la monitorización en función no solo de una distancia, si no de un tiempo en recorrerla también. Explicándolo mejor, el proceso de monitorización solo actúa, en el caso concreto de esta fase de la app, si en cinco minutos, el usuario ha recorrido unos doscientos metros o más; y esto lo conseguimos incrementando un contador cada vez que hay una llamada al Listener, si en una llamada han pasado mas de cinco minutos desde la última monitorización, se comprueba que al menos haya habido un número x de llamadas al Listener antes recogidas en el contador. Así conseguimos el mínimo consumo de batería con un rango de detección de desvíos bastante aceptable. Ahora bien, para pasar a la explicación de cómo se detecta un desvío, hay varias cuestiones que resolver con antelación. La primera cuestión puede estar bastante relacionada con la libertad del usuario, la capacidad de adaptación del monitor y con los niveles de riesgo que vamos a considerar. En esta implementación, se ha decidido que la monitorización no solo tenga en cuenta la rutina que tiene que estar haciendo el usuario a cierta hora hoy, sino que consideramos una opción viable, el que el usuario esté realizando una rutina propia de otro día, ya sea de forma excepcional, o por un cambio en sus hábitos, como es que le cambien los días de rehabilitación. De esta forma, hay un riesgo, que consideramos bajo, y que asumimos ya que puede darse esta situación. La segunda cuestión tiene que ver con la libertad del usuario de cambiar el camino que usa para ir a alguna parte, ya sea por una calle cortada por obras, o porque tiene que desviarse mínimamente a comprar el pan. Así que la monitorización no debería ser tan estricta como para valorar un solo camino para una misma rutina. Teniendo estos dos conceptos claros, pasamos a explicar como funciona la monitorización. Una aplicación para enfermos de alzhéimer 24 Empecemos por el primer desplazamiento del día, en cuanto recogemos la primera muestra del histórico, actúa el monitor, lo primero que hace es rellenar una lista con todas las rutinas que parten del lugar de la muestra recién recogida e incrementamos el contador por primera vez. Figura 5. El usuario puede estar siguiendo cualquier rutina de la lista. A partir de aquí, empieza el procedimiento descrito antes, comprobamos si han pasado los cinco minutos, si no han pasado, incrementamos contador; si sí que han pasado, vemos si el contador tiene un número de medidas aceptable, lo que significa que el usuario sigue moviéndose. Entonces pasamos a la parte central del procedimiento, ahora hay que comprobar si el paciente se ha desviado de alguna de las rutinas de la lista que recogimos antes, pero sin atender a caminos exactos. Lo que se hace es ir rutina a rutina de la lista, y se establece un radio de cierta holgura con centro en el destino de la rutina. El radio va a estar fijado en función del tiempo que quede para que el usuario llegue a su destino, teniendo en cuenta el tiempo que suele tardar en realizar dicha rutina. Así, a medida que va avanzando el tiempo, el radio va acotándose, haciéndose cada vez menor hasta que tenga que haber llegado a su destino. De esta forma, somos capaces de considerar que el usuario está en camino siempre que permanezca dentro de ese radio. En la figura 5 puede observarse la fase inicial de este procedimiento, cuando el usuario sale de un lugar y puede estar siguiendo cualquiera de las rutinas de la lista ya que está dentro de todos los radios con cierta holgura. Una aplicación para enfermos de alzhéimer 25 De todas las rutinas que habrá en la lista, la mayoría de las veces, habrá una que es la habitual, la que el usuario debería estar siguiendo ese día a esa hora, si en esta rutina específica se detecta, en alguna de las veces que se activa el monitor, que el paciente se ha desviado, se considera un riesgo bajo y se avisa al actuador para que realice su trabajo. En la figura 6, esta rutina concreta se corresponde con el área del punto rojo, indicando que ha quedado fuera del área permitida con el paso del tiempo y ya no se encuentra en su camino. Figura 6. El usuario se desvía de la rutina que debería estar siguiendo. El otro nivel de riesgo, el alto, se dará cuando en la lista no haya ninguna rutina que el usuario esté siguiendo, en cuyo caso se volverá a avisar al actuador pero para que esta vez, atienda a una alerta más grave. Esta es la situación descrita en la figura 7, el tiempo ha ido transcurriendo y las áreas permitidas han ido encogiendo hasta que finalmente se ha dado el caso de que el usuario no esta dentro de ninguna, por lo que no debe estar siguiendo ninguna de las rutinas habituales que salen desde su lugar de partida. Una aplicación para enfermos de alzhéimer 32 Figura 9. Diagrama entidad/relación de la base de datos del sistema. Las primeras tablas serían las de los contactos, las citas y el historial que no tienen mayor relevancia. Contacto Esta tabla contiene la información de los contactos de emergencia del usuario. • Nombre. • Prioridad, es un entero del 1 al 3, siendo el 1 la mayor prioridad, la del responsable y el 3 la menor como bomberos… • Teléfono. • Dirección bluetooth, que nos puede ser útil para saber si el usuario en algún momento está acompañado por su responsable. Una aplicación para enfermos de alzhéimer 33 Cita Aquí se recogen los eventos o citas eventuales que tenga el usuario como pueden ser citas con algún médico o para hacerse alguna analítica, cumpleaños de familiares… Contiene datos de: • La fecha de la cita. • La hora. • El lugar en que tendrá lugar. • Descripción de la cita. Historial Es donde el acumulador almacena todas las muestras que vaya recogiendo. Esta tabla tiene en primer lugar una columna ID que es un entero y representa la clave primaria. Tras esto tiene los datos que en principio necesitaríamos saber para que después el proceso analizador pueda establecer rutinas. Contiene datos de: • Coordenadas GPS, que son dos números decimales largos que representarán latitud y longitud. • Fecha, en que se ha tomado la muestra. Esta tiene un formato que incluye la hora para facilitar la definición de la rutina. Se intentará borrar los valores más antiguos de esta tabla cada cierto tiempo, para que no llegue a ocupar demasiado en la memoria del teléfono del usuario en versiones futuras de la aplicación. Además de estas tres tablas, la base de datos cuenta con la tabla Rutina, aunque esta también cuenta con otras tablas que se encuentran en una relación muchos a muchos con ella. Estas tablas son las utilizadas para almacenar lugares conocidos y las frecuencias de las rutinas. Rutina Esta es la tabla fundamental del sistema, en ella se almacenan las rutinas y su grado de convicción y frecuencia. Todas sus columnas deberán inferirse de los datos de las muestras de la tabla Historial que tienen que ver con dicha rutina. • Lugares a los que el usuario acude durante la rutina, Una aplicación para enfermos de alzhéimer 34 • Hora de inicio de la rutina. • Hora de fin de la rutina. • Frecuencia semanal con la que se repite la rutina (Lunes y martes, solo los miércoles…) Los puntos a los que el usuario acude en la rutina se han modelado usando una relación muchos a muchos con una tabla llamada Lugares Habituales que contiene las coordenadas GPS de dichos puntos visitados por el usuario. En cuanto a la columna frecuencia, también es una relación muchos a muchos con una tabla Día que contiene los nombres de los días de la semana; esta relación además tiene un campo convicción que será el porcentaje de convicción de que esa rutina se realice en ese día de la semana. Lugares Habituales Se trata de la tabla que se relaciona con las rutinas en la relación muchos a muchos de los lugares a los que irá acudiendo el usuario durante la misma. Representa los lugares en los que el usuario pasa más tiempo o acude con asiduidad, como su casa, el trabajo, la panadería… Esta tabla contendrá las columnas necesarias para identificar estos lugares. • Coordenadas GPS. • Descripción del lugar, o anotaciones que se quieran hacer sobre él. • Asiduidad, que representará un número entero, representando el más alto, el lugar donde más ha ido el usuario, que suele ser su casa. Esta relación nos permite una muy fácil ampliación para versiones futuras en las que se podría considerar rutinas de mayor longitud con más lugares intermedios, y no de un lugar a otro únicamente, sin poder establecer relaciones entre ellos como en esta versión inicial. Frecuencia Es la tabla que está relacionada con Rutina, para representar la frecuencia semanal con la que se repite una rutina de desplazamiento del usuario. Solo contiene una fila por día de la semana de lunes a domingo. Para completar la información sobre una frecuencia semanal de una rutina, se añadió un campo de un entero para representar el Una aplicación para enfermos de alzhéimer 35 grado de convicción que se tiene sobre la repetición del desplazamientos ese día. Este campo se encuentra en la relación muchos a muchos entre las dos tablas. Por último, es de esperar que en análisis, antes de obtener las rutinas completas, son necesarios una serie de pasos intermedios en los que los datos van adquiriendo cada vez una mayor complejidad. Estas tablas son, en orden ascendente de completitud, Instancia de Lugar e Instancia de Rutina. Instancia de Lugar Es el primer paso en el análisis. En esta tabla se intentan identificar los lugares en los que el usuario ha permanecido cierto tiempo. Es el paso previo a convertirse en un lugar habitual. Contiene: • Coordenadas GPS, del lugar en cuestión. • Fecha y hora de comienzo, de la permanencia en ese lugar. • Fecha y hora del fin, de la permanencia en ese lugar. Instancia de Rutina Este es el último paso de los datos antes de convertirse en Rutinas. Estos datos ya tienen la misma forma que una rutina, a falta de la frecuencia. • Coordenadas GPS, del lugar de partida. • Coordenadas GPS, del lugar de llegada. • Fecha y hora de salida, desde el lugar de partida. • Fecha y hora de llegada, al destino. 2.5 Procedimiento de análisis Según la filosofía PeaaS, los dispositivos móviles de los usuarios deben ser capaces de ser su interfaz con el mundo que los rodea, sin necesidad de que estos tengan que configurarlos. Estos dispositivos ya poseen toda la información que necesitan acerca de nosotros, y deben ser capaces de reaccionar ante estímulos teniendo en cuenta el contexto en el que se encuentra el usuario. Según PeaaS el dispositivo móvil del usuario es capaz de elaborar un perfil sociológico sensible al contexto de su usuario. Una aplicación para enfermos de alzhéimer 36 Para llegar a esta idea, es necesario tener conocimiento del usuario. La definición de conocimiento sigue siendo materia de discusión a día de hoy y, adopta diferentes formas dependiendo del contexto. En el contexto que atañe a este trabajo, una buena definición de conocimiento podría ser la proporcionada por Wright [12]. Esta hace énfasis en que el conocimiento, siempre estará fundado en hechos solidos. “Knowledge signifies things known. Where there are no things known, there is no knowledge. Where there are no things to be known, there can be no knowledge. We have observed that every science, that is, every branch of knowledge, is compounded of certain facts, of which our sensations furnish the evidence. Where no such evidence is supplied, we are without data; we are without first premises; and when, without these, we attempt to build up a science, we do as those who raise edifices without foundations. And what do such builders construct? Castles in the air.” Para entender esta definición, es necesario entender la diferencia entre hechos y conocimiento para obtener este último. Un buen punto de partida para establecer la relación entre los hechos y el conocimiento es la anteriormente descrita pirámide de DIKW, que divide el proceso de obtención de conocimiento en datos, información, conocimiento y sabiduría. Esta pirámide se muestra en la figura 10, donde pueden verse los niveles de ascensión hasta llegar a la sabiduría o inteligencia. Figura 10. Pirámide del conocimiento de Davenport y Prusak. Una aplicación para enfermos de alzhéimer 37 Los datos en este contexto representan las evidencias observables, los estímulos que recogemos de la inspección del mundo. Esto es lo que representaría nuestro histórico de muestras. La información tiene una naturaleza descriptiva, y es capaz de empezar a responder preguntas de quién, cuándo, qué… La información pueden ser datos útiles y con significado propio. El conocimiento es una serie de reglas o expectativas que proporcionan un claro entendimiento de conjuntos de información. Es capaz de reconocer patrones en la información con experiencia e interpretación. Por último, la sabiduría es el conocimiento que en un contexto puede utilizarse para generar nuevos conocimientos o parar tomar decisiones. Es lo que en nuestro trabajo serían las rutinas finales. Siguiendo este modelo de proceso de obtención de conocimiento, el algoritmo diseñado e implementado para el análisis de rutinas de la aplicación CareMe va ascendiendo por la pirámide desde las muestras del histórico, hacia lo que se ha denominado instancias de lugar (información), de aquí al conocimiento de lo denominado instancias de rutina, y por último llegando a obtener las rutinas, que representarían la sabiduría. Este algoritmo, debido a su elevado coste computacional, podría tener una fuerte repercusión en el dispositivo durante su ejecución. Es por esto, por lo que se decidió que este proceso solo se ejecutara una vez al día, y en las mejores condiciones posibles, para garantizar la comodidad del usuario. El algoritmo solo se ejecuta o bien, cuando se conecta el teléfono a la red eléctrica, o si esto no sucede un día, y este tiene aun un nivel considerable de batería, a altas horas de la madrugada de forma automática. El procedimiento, como hemos dicho, sigue una serie de pasos hasta llegar a la obtención de las rutinas para ir ascendiendo por la pirámide del conocimiento. 1. Primer paso. Este paso parte desde la muestras recogidas por el proceso del acumulador durante el día. Recordamos que este recoge una muestra únicamente cuando el usuario se ha desplazado un cierto número de metros, así, si el paciente permanece en un mismo lugar, este margen de metros es considerado lo suficientemente grande para que mientras que el usuario camine por el interior de este, no se recoja ninguna muestra. De esta forma, solo tenemos muestras de los desplazamientos del usuario de un lugar a otro, pero no mientras está en ellos. En la Una aplicación para enfermos de alzhéimer 38 figura 11 puede observarse cómo se obtendrían las muestras según la situación del usuario. Pues bien, teniendo esto claro, el primer paso del algoritmo consistirá en reconocer los lugares en los que ha estado el usuario y de que hora a que hora ha permanecido en ellos. Esta tarea resulta no muy complicada, consiste en ir tratando las muestras de dos en dos; si entre estas dos muestras ha pasado un tiempo coherente con el necesario en recorrer la distancia en metros que tiene como frecuencia el acumulador, entonces quiere decir que el usuario se esta moviendo, en caso contrario, tendríamos que la primera muestra es la llegada a un lugar donde ha permanecido un tiempo parado, y la segunda la salida de este. Así reconocemos las instancias de lugar. Es importante tener en cuenta que la primera muestra del análisis siempre hay que compararla con la última del análisis del día anterior, para no saltarse ningún lugar por medio. Cada vez que se crea una instancia de lugar, se compara con todas las demás almacenadas, ya que si se detecta que empieza a repetirse bastante, se crea un lugar habitual del usuario, al crearlo, puede darse el caso de que el lugar ya esté, por lo que en cuyo caso, solo incrementamos su campo de asiduidad. Gracias a esto es posible saber cual es la casa o el trabajo del usuario, ya que son los lugares con mayor asiduidad. Figura 11. Recolección de muestras de posición a lo largo del tiempo. Una aplicación para enfermos de alzhéimer 39 2. Segundo paso. Ahora partimos de las instancias de lugar que tenemos en la base de datos. El procedimiento es muy parecido al anterior, solo que esta vez su significado es distinto. Una vez separados los lugares en los que ha estado el usuario en las instancias y conocidos sus momentos de llegada y salida, solo es necesario ir agrupándolos de dos en dos, de modo que si se tienen las instancias 1, 2 y 3, se obtendrían los grupos [1, 2] y [2, 3]. Estos grupos, como es de esperar, se corresponden con nuevas instancias de rutinas. 3. Tercer paso. En este último paso obtenemos las rutinas de desplazamiento del usuario. Para entender el procedimiento recordemos como se formaba una rutina en la base de datos. Este paso es prácticamente una prolongación del anterior. Cuando se almacena una instancia de rutina, se hace como con los lugares, se comprueba si hay alguna que empiece a repetirse. Si esto es así, cuando llegue a repetirse cierto número de veces, entonces pasamos a la creación de la rutina. Buscamos en la tabla de lugares habituales los lugares de la instancia y creamos la relación. Cabe destacar la fácil ampliación ya comentada del modelo a rutinas más complejas con mas paradas en lugares gracias a la relación y a su campo de hora de fin, que es importante saber para su posterior monitorización. Tras esto, se busca si la rutina ya existe, con esos dos mismos lugares de salida y llegada; si existe, se busca si se repite en la misma frecuencia, es decir, en el mismo día, si es así, incrementamos la convicción de la misma, en caso contrario, añadiríamos una nueva frecuencia a la rutina. Hay que tener en cuenta también, la hora a la que empieza la rutina para decidir si se repite en la misma frecuencia o no. Esta comprobación quedaría así. l1.setLatitude(routineActual.getPlace().getLatitude()); l1.setLongitude(routineActual.getPlace().getLongitude()); l2.setLatitude(routineActual.getPlace().getLatitude()); l2.setLongitude(routineActual.getPlace().getLongitude()); l3.setLatitude(routineAlmacenada.getPlace().getLatitude()); l3.setLongitude(routineAlmacenada.getPlace().getLongitude()); l4.setLatitude(routineAlmacenada.getPlace().getLatitude()); l4.setLongitude(routineAlmacenada.getPlace().getLongitude()); if (l1.distanceTo(l3) < MIN_DISTANCE && l2.distanceTo(l4) < MIN_DISTANCE) { routineFreqs = db.getRoutineFreqs(routineAlmacenada.getId()); for (int i = 0; i < routineFreqs.size() && !found; i++) { rf = routineFreqs.get(i); if (getWeekDay(routineActual.getStart()).equals(rf.getFrequency().getDay())) { Una aplicación para enfermos de alzhéimer 40 if (getWeekDay(routineActual.getStart()).equals(rf.getStart())) { //Actualizamos reliability if (rf.getReliability() < 95) { rf.setReliability(rf.getReliability() + 5); db.insertRoutineFreq(rf.getRoutine().getId(), rf.getFrequency().getId(), rf.getReliability(), rf.getId()); } found = true; } } } } 2.6 Optimización de recursos En el diseño de aplicaciones destinadas a dispositivos móviles, la optimización del consumo de recursos del dispositivo debe ser un factor director. Los recursos en los que se debe focalizar el esfuerzo son primordialmente la memoria del dispositivo, que suele ser uno de los principales problemas que los usuarios afrontan con su teléfono, la batería, y la capacidad de procesamiento del móvil (RAM y CPU), para no provocar que el dispositivo pueda quedarse bloqueado o disminuir mucho su rendimiento y velocidad durante su uso cotidiano. En primer lugar, teniendo en cuenta el tamaño limitado de la memoria de los dispositivos, se ha optado por no guardar el historial de desplazamientos del paciente por un plazo indefinido. Como ya se ha mencionado anteriormente, una vez que los datos correspondientes al último día de actividad han sido procesados e integrados a la línea de tiempo del paciente podrían eliminarse. Otro caso es el de los datos intermedios generados en el análisis, podría ser útil mantener algunos y solo ir eliminando los más antiguos, ya que se trata de las muestras, pero ya tratadas y tendrán un menor impacto en la memoria. Gracias a esto puede implementarse una recuperación ante fallos en casos de que las rutinas se borren o estropeen para volver a generarlas. Esto también podría resultar beneficioso cuando el paciente introduce un cambio en sus rutinas de comportamiento y desea regenerar su línea de tiempo a partir de las actividades realizadas en los últimos días. Por ejemplo, imagínese que el paciente cambia su domicilio habitual por una residencia con el objeto de conseguir asistencia durante todo el día. Una aplicación para enfermos de alzhéimer 41 Si ahora nos centramos en otro de los puntos críticos, la capacidad de procesamiento, el punto clave estará probablemente en el procesamiento de la actividad de la jornada, el reconocimiento de rutinas y su integración en la línea de tiempo, es decir, en el análisis, que es una tarea que consume muchos ciclos de reloj. Por ello esta actividad se lleva a cabo sólo en momentos en los que el Smartphone este siendo lo menos usado posible. Estos momentos son como hemos explicado, cuando se detecta que el teléfono está en carga, conectado a la red eléctrica, o en altas horas de la madrugada, en la que el usuario estará durmiendo. Esta tarea, por extensión, también resulta crítica para el ultimo recurso a tener en cuenta del dispositivo, la batería. Es por esto por lo que se decidió dar prioridad entre estas dos opciones a la de mientras esté cargando, ya que la ejecución de la tarea en este momento, no tendría repercusión en la duración de la batería. Por último, todas las actividades de registro de localización física y monitorización también consumen mucha batería y capacidad de procesamiento durante el día. Sin embargo, en este caso resulta difícilmente evitable. Si se desea mucha precisión en los registros de información y en los cálculos de cercanía se requieren cadencias de registro muy elevadas. No obstante, como ha podido comprobarse, existen gran número de parámetros configurables en la aplicación con el objeto de poder adecuar estas cadencias a las características de cada paciente. Además, se han implementado medidas ya explicadas en sus respectivos procesos, por ejemplo en el de monitorización, para reducir el cómputo, sobre todo en frecuencia, sin llegar a observar una pérdida de precisión en la monitorización muy grave, ya que en la versión actual, se detectarían como máximo en 5 minutos. Actualmente se dispone de un prototipo funcional de la aplicación al que corresponden las imágenes mostradas. Dicho prototipo monitoriza la actividad del paciente, aprende sus rutinas en base a puntos de inactividad y rutas entre ellos y realiza detecciones básicas de si el paciente se encuentra en rutina o no. Sin embargo, todavía existen múltiples extensiones que pueden mejorar las medidas de optimización de recursos, como por ejemplo detectar la conexión a puntos WIFI, permitiendo la desactivación de algunos procesos durante un tiempo o la presencia de un acompañante del paciente, quizás mediante Bluetooth, que permitiría también reducir el computo de monitorización. Trabajos relacionados 49 4. Trabajos relacionados PeaaS es un modelo que persigue poner en valor el contexto de las personas proporcionándolo como un servicio desde el teléfono móvil. En los últimos meses, hemos podido observar como las grandes compañías, y en general la tecnología, está tratando de encontrar el modo en que nuestra interacción con el resto de personas o cosas presentes en nuestra vida sea mucho más sencilla, podríamos decir que automática. Y es sin duda esto lo que persigue este modelo, dando a este trabajo una especial relevancia además de suponer una gran cantidad de aportaciones a esta materia. Algunas de las tecnologías más avanzadas en este campo por el momento, como avecinamos, son las aportadas por las grandes empresas. Es el caso de Siri6 de Apple, Cortana7 de Microsoft o Google Now8; Aunque también hay proyectos similares que no vienen de ellas, como es Sherpa9. Todas estas ofrecen una funcionalidad parecida, proporcionando al Smartphone capacidades atribuibles a personas, y encargando a este funciones de asistencia en nuestro día a día especial y adaptada para el usuario. En las últimas versiones de los sistemas operativos móviles de estas compañías, puede ir observándose esta tendencia, dedicando a este propósito una pantalla de escritorio, o algunas etiquetas en el área de notificaciones. Estos avances suelen ser del tipo de detectar cosas de interés para el usuario, como las noticias con más repercusión alrededor de este, que entren dentro de sus secciones de interés. O los restaurantes del alrededor mejor valorados que ofrezcan el tipo de comida más habitual del usuario. La aplicación de PeaaS en este trabajo consiste en poner el contexto del Paciente al servicio del Cuidador. Ya existen otras aplicaciones móviles basadas en una arquitectura convencional que asisten a pacientes de alzhéimer con el mismo objetivo que CareMe. Una de las pioneras en este género es Tweri. Esta aplicación proporciona funcionalidades básicas para identificar las zonas donde el paciente se encuentra seguro de forma que se notifiquen alertas al cuidador si las abandona. El cuidador puede seguir al paciente a través de una aplicación diferente. Además, si el paciente se encuentra inseguro puede lanzar una alerta al cuidador mediante una pulsación en la interfaz. Con funciones mejoradas y el mismo objetivo, Cerqana, cuyo panel web puede verse en la figura 15, permite la fijación manual de zonas seguras y peligrosas 6 Siri. https://www.apple.com/es/ios/siri/! 7 Cortana. http://www.windowsphone.com/es-es/how-to/wp8/cortana/meet-cortana 8 Google Now. https://www.google.com/landing/now/ 9 Sherpa. http://sher.pa/ Trabajos relacionados 50 en un mapa, aviso vía notificación si entra en alguna zona marcada como insegura, fijación manual de rutas habituales del usuario o detección de caídas o desvanecimientos. Figura 15. Panel web de Cerqana. En comparación con CareMe, ambas aplicaciones adoptan una estrategia en la que el dispositivo móvil del paciente se encarga de subir su localización a un servidor con una cadencia determinada. En el servidor se realizan todos los análisis de datos y el tratamiento de alertas. Ninguna de ellas aborda la detección y aprendizaje de las rutinas del paciente, ni la actuación en tiempo real ante alertas, sino sólo basada en los datos que se encuentran en el servidor y que normalmente tienen minutos de retraso que, en algunos casos, pueden resultar decisivos. Esta característica es difícilmente solventable mediante el uso de arquitecturas convencionales ya que implicaría cadencias muy altas en la subida de datos al servidor con el consiguiente consumo de batería. Plataformas como UrbanAirship10 advierten que cadencias de registro y subida de datos cercanas a los 30 segundos implican el consumo de la batería del dispositivo en un periodo de 30 a 40 minutos. Para la elaboración de este trabajo, finalmente se ha optado por emplear un algoritmo propio y muy básico para el análisis y aprendizaje de rutinas. Sin embargo, el uso de 10 UrbanAirship. http://urbanairship.com/ Trabajos relacionados 51 herramientas como RDFQuery 11 , RDFStoreJS 12 , Nools 13 o AndroJena 14 podrían contribuir a mejorar nuestra propuesta. Su uso está contemplado en un siguiente paso cuando se proceda a incorporar datos al análisis más allá de la localización. 11 RDFQuery. https://code.google.com/p/rdfquery/ 12 RDFStoreJS. https://github.com/antoniogarrote/rdfstore-js 13 Nools. https://github.com/C2FO/nools 14 AndroJena. https://github.com/lencinhaus/androjena Conclusiones 53 5. Conclusiones El progresivo desarrollo de IoT y la salida al mercado de nuevos dispositivos wearable están haciendo cambiar la forma en que interactuamos con nuestro entorno, favoreciendo el surgimiento de escenarios cada vez más interconectados y de complejidad creciente. Sin embargo, el estado actual de la tecnología, obliga a una continua intervención del usuario. Modelos como PeaaS abogan por el uso del teléfono móvil como interfaz del usuario con su entorno, y permiten el desarrollo de perfiles sociológicos que pueden ser ofrecidos como servicios a terceros de forma controlada, favoreciendo la transición de IoT a IoP. En este trabajo presentamos el desarrollo de una aplicación para la supervisión y seguimiento de enfermos de alzhéimer, como prueba de concepto del modelo PeaaS. A partir de la monitorización de la señal GPS del teléfono, la aplicación desarrollada es capaz de aprender las rutinas de desplazamiento del usuario y de tomar decisiones en caso de desviaciones de las mismas que puedan implicar un peligro para el enfermo. CareMe ofrece una funcionalidad significativamente superior a otras similares actualmente en el mercado, y muestra cómo los conceptos inherentes al modelo PeaaS pueden ser puestos en práctica en un escenario de uso real, más allá del caso de estudio elegido como prueba de concepto. Actualmente nos encontramos en una fase alpha del desarrollo de la aplicación, aunque ya es plenamente funcional, sin embargo, como hemos repetido numerosas veces en este articulo, aún admite numerosas funcionalidades más y mejoras a realizar para nuevas versiones más avanzadas y que pueden llevar CareMe a su uso real en la vida cotidiana de estas personas que lo necesitan. 5.1 Trabajos Futuros En cuanto a trabajos futuros, cabe señalar la incorporación progresiva de nuevos algoritmos de aprendizaje, para lograr una mayor precisión tanto en la detección de rutinas de desplazamiento, como en la predicción de las mismas y en la detección de desviaciones respecto al comportamiento habitual. La integración con servicios como Google Maps permitiría obtener información de interés sobre el entorno de las coordenadas del usuario, afinar la detección de situaciones peligrosas y proporcionar ayuda al usuario para retomar su rutina de desplazamiento en caso de que se haya extraviado. Por otro lado, el uso de la señal wifi, y bluetooth del teléfono permitiría un Conclusiones 54 mejor seguimiento de la actividad del usuario en interiores, por ejemplo mediante iBeacons15, y la detección de si está acompañado por sus cuidadores o no. Mediante esta prueba de concepto se ha demostrado las numerosas aportaciones que puede realizar el modelo PeaaS a la tecnología actual, convirtiendo la vida de los usuarios en una vida mucho mas cómoda y permitiendo la integración de estos usuarios en el mundo que los rodea sin ningún esfuerzo y de forma automática. El modelo supone un gran adelanto para muchas tecnologías, entre otras IoT, permitiéndole adaptarse automáticamente a cada usuario Esta idea abre la puerta a multitud de nuevos escenarios. • Nuevos protocolos de pago. No es necesario tener la información de pago en el móvil. Únicamente cuando se esté pagando, la entidad financiera desplegará un servicio de pago seguro en tu Smartphone. • Logística de recolección de residuos. El teléfono centraliza información acerca de la cantidad y tipos de residuos que generamos en casa, así preguntando al usuario y sus vecinos se podrá planificar una recogida más eficiente. También podrá avisar del momento en el que dejar la basura en el contenedor. • Política. El Smartphone podría plantear encuestas a sus usuarios de forma que el gobierno sería luego capaz de recoger los resultados agrupados por edad, sexo… Esta información siempre quedará segura, ya que en ningún momento sale del teléfono. • Planes energéticos. El dispositivo móvil podrá elaborar planes energéticos más eficientes para cada usuario. • El caso que ocupa la prueba de concepto, ayuda a personas mayores o enfermos. Estos no tendrán que enterarse de nada ni saber nada acerca de tecnología, la aplicación se despliega en sus Smartphone y la ofrece a sus cuidadores y a ellos mismos para mejorar sus hábitos. • Estrategias de marketing avanzadas. Se podría extraer información directamente de los clientes, explorar sus necesidades. Así se programarían las estrategias teniendo toda esta información en cuenta. • Salud. Los teléfonos móviles ofrecerían datos acercar de parámetros de salud. Analizar las enfermedades de los usuarios y ayudarles con la medicación que 15 iBeacons. https://developer.apple.com/ibeacon/ Conclusiones 55 usan. Además obtendrían estadísticas de salud acerca de distintos tipos de enfermedades por áreas geográficas. Referencias 57 6. Referencias Y. Cui, M. Honkala. “A novel mobile device user interface with integrated social [1] networking services”: International Journal of Human-Computer Studies, 71(9), 919-932, 2013. M. Bakardjieva, R. Smith. “The Internet in everyday life computer networking from [2] the standpoint of the domestic user”: New Media & Society, 3(1):67-83, 2001. A. Dohr, R. Modre-Opsrian, M. Drobics, D. Hayn, G. Schreier. “The Internet of [3] Things for ambient assisted living”: Information Technology - New Generations (ITNG), Seventh International Conference on, pp. 804-809, IEEE Computer Society, 2010. L. Sha, S. Gopalakrishnan, X. Liu, Q. Wang. “Cyber-physical systems: A new [4] frontier”: Machine Learning in Cyber Trust, pp. 3-13, Springer, 2009. J. Guillen, J. Miranda, J. Berrocal, J. Garcia-Alonso, J.M. Murillo, C. Canal. “People [5] as a Service: A Mobile-centric Model for Providing Collective Sociological Profiles”: Software, IEEE 31(2), 48-59, 2014. L. Srivastava “Mobile phones and the evolution of social behavior”: Behaviour & [6] Information Technology, 24(2), 111-129, 2005. A. Oulasvirta, T. Rattenbury, L. Ma, E. Raita “Habits make smartphone use more [7] pervasive”: Personal and Ubiquitous Computing, 16(1), 105-114, 2012. T.H. Davenport, L. Prusak. Working Knowledge : How Organizations Manage What [8] They Know. Harvard Business School Press, 1998. ! J. Miranda, N. Mäkitalo, J. Garcia-Alonso, J. Berrocal, T. Mikkonen, C. Canal, J.M. [9] Murillo. “From the Internet of Things to the Internet of People”, Internet Computing Magazine, IEEE, 19(2), 40-47, 2015. N. Mäkitalo, J.Pääkkö, M. Raatikanien, V. Myllärniemi, T. Aaltonen, T. Leppänen, T. [10] Mänistö, t. Mikkonen, “Social Devices: Collaborative Co-located Interactions in a Mobile Cloud” Proceedings of the 11th International Conference on Mobile and ubicuous Multimedia, MUM, 2012. N. Mäkitalo. Building and programming ubiquitous social devices, Proceedings of [11] the 12th ACM international symposium on mobility management and wireless access (MobiWac ’14), pp. 99-108, ACM 2014. Frances Wright. Course of Popular Lectures. Office of the Free Enquirer, 1829. 24 [12] Anexos Análisis El proceso de análisis solo se lleva a cabo una vez al día, cuando el teléfono entra en modo de carga. Para atender a esto, es necesario que el análisis lo realice una clase que extienda BroadcastListener. Este tipo de clases es necesario registrarlas en el manifiesto Android de la siguiente forma. <receiver android:name=".PowerConnectionReceiver" > <intent-filter> <action android:name="android.intent.action.ACTION_POWER_CONNECTED" /> </intent-filter> </receiver> En este caso, la clase que extiende se llama PowerConnectionReceiver y se registra para la llamada de conexión a la alimentación. El comportamiento a realizar debe escribirse en el método sobrescrito onReceive(Context context, Intent intent), que en la aplicación CareMe, realiza llamadas a distintos métodos para ir completando los pasos del análisis. • Private void analyzeHistories(Context context, History h1, History h2) Usa las dos muestras de histórico que recibe como parámetros para crear una instancia de lugar si ha permanecido en el una estancia mínima, y en función de si se repite un número mínimo de veces, crear un lugar habitual. El número mínimo de repeticiones y la estancia mínima son variables globales que están definidas en tres repeticiones y quince minutos, este último expresado en milisegundos. • Private int getInstancesCount(History h1) Es el método que usa analyzeHistories para realizar la cuenta de instancias de un lugar u en función de esta, crear un Lugar Habitual. count = getInstancesCount(h1); if (count > MIN_REPS) { //Comprobamos que no este ya en la bd e insertamos o actualizamos createPlace(context, h1, count); } • Private boolean createPlace(Context context, History h, int count) Es el método que usa analyzeHistories para crear un Lugar habitual. Primero busca si el lugar a crear ya existe, en cuyo caso realiza una media de las coordenadas para ser lo más preciso posible a medida que va a prendiendo e incrementa la asiduidad en uno. Anexos if (l1.distanceTo(l2) < MIN_DISTANCE) { //hacemos media de la localización para ser cada vez mas exactos double avlat = ((l1.getLatitude() * p.getAssiduity()) + l2.getLatitude()) / (p.getAssiduity() + 1); double avlon = ((l1.getLongitude() * p.getAssiduity()) + l2.getLongitude()) / (p.getAssiduity() + 1); p.setLatitude(avlat); p.setLongitude(avlon); //actualizamos assiduity p.setAssiduity(p.getAssiduity() + 1); db.insertPlace(p); found = true; } Si no existe aún lo inserta en la base de datos. MIN_DISTANCE es la distancia que se usa para considerar si dos coordenadas son el mismo lugar, su valor se fija en sesenta metros. El método devuelve true si el lugar ya existía. • Private void analyzeInstances(Context context, PlaceInstance p1, PlaceInstance p2) Es el segundo método que invoca onReceive para los siguientes pasos del análisis. Tiene la misma estructura que analyzeHistories, pero esta vez con Instancias de Lugar como parámetro para construir Instancias de Rutinas y las propias Rutinas. También usa la estancia mínima para comprobar si entre los lugares hay un mínimo desplazamiento y disminuir los errores del GPS • Private int getRInstancesCount(PlaceInstance p1, PlaceInstance p2) Tiene exactamente el mismo funcionamiento que getInstancesCount. • Private void createRoutine(Context context, PlaceInstance p1, PlaceInstance p2, int count) Lo invoca analyzeInstances para crear Rutinas. Primero comprueba que la rutina no exista ya, pero esta comprobación tiene varias fases. if (l1.distanceTo(l3) < MIN_DISTANCE && l2.distanceTo(l4) < MIN_DISTANCE) { routineFreqs = db.getRoutineFreqs(r.getId()); for (int i = 0; i < routineFreqs.size() && !found; i++) { rf = routineFreqs.get(i); if (getWeekDay(p1.getStart()).equals(rf.getFrequency().getDay())) { //Actualizamos reliability if (rf.getReliability() < 95) { rf.setReliability(rf.getReliability() + 5); db.insertRoutineFreq(rf.getRoutine().getId(), rf.getFrequency().getId(), rf.getReliability(), rf.getId()); } found = true; } } } Anexos primero se comprueba que los lugares de partida y destino sean los mismos, tras esto, se deben hacer comprobaciones de la frecuencia. Si los lugares coinciden y la frecuencia también está ya incluida, se incrementa su fiabilidad. En caso de que no exista la frecuencia se añade, y en caso de que no exista la rutina, se crea con todas sus relaciones de lugares y frecuencia. Monitorización Este proceso debe estar en ejecución constante todo el día, independientemente de si la aplicación no esta abierta. Es por esto que se decidió implementarlos en un Servicio de Android. Esta clase debe extender de Service e implementar sus métodos de creación. También ha de ser registrado en el manifiesto como sigue. <service android:name=".AccumulatorService" android:enabled="true" android:exported="true" > </service> Los métodos de creación, onCreate() y onStartCommand(Intent, int, int) se usan para crear la instancia de la base de datos y registrar los usuarios de la comunicación de Nimbees. AccumulatorService, que es como se llama esta clase, realiza los procesos de acumulación de muestras de histórico y de monitorización. La acumulación de histórico se lleva a cabo mediante un LocationListener. locManager = (LocationManager) getSystemService(Context.LOCATION_SERVICE); Criteria crit = new Criteria(); crit.setAccuracy(Criteria.ACCURACY_FINE); crit.setPowerRequirement(Criteria.POWER_LOW); provider = locManager.getBestProvider(crit, true); locManager.requestLocationUpdates(provider, 0, MIN_DISTANCE, locListener); Se usan criterios para conseguir un compromiso entre un consumo de batería mínimo y precisión máxima. Recogemos muestras cada vez que se realiza un desplazamiento de MIN_DISTANCE, que eta definido globalmente a treinta metros. Aprovechando estas ejecuciones, es cuando se envía la posición al cuidador y se lanza el proceso de monitorización. Anexos • Public void sendPersonalizado(Location loc) Es el método que se llama al recoger la muestra de histórico para enviar la posición actual al cuidador. Este envío se realiza mediante una CustomNotification de Nimbees. En este mensaje se incluye un fragmento JSON con las coordenadas y se envía. usuarios.add(email); filters.add(new UserNameListFilter(usuarios)); //Envio un mensaje con los usuarios del filtro como content (Utilizo GSON para convertir // List<String> a un String en formato JSON, y luego convertire ese String en List<String> con //GSON) NimbeesNotificationManager nimbeesNotificationManager = NimbeesClient.getNotificationManager(); Gson gson = new Gson(); nimbeesNotificationManager.sendNotification(gson.toJson(coordenadas), MessageContent.NotificationType.CUSTOM, filters, new NimbeesCallback()) • Private void monitor(Location loc) Esta función también se llama al recoger la muestra de histórico. Funciona solo si han pasado cinco minutos desde su última intervención. Cuando esto sucede comprueba si un contador que se incrementa cada vez que se guarda una muestra si al menos su valor es de seis, lo que supondría que en esos cinco minutos, el usuario se ha desplazado aproximadamente doscientos metros. En caso de que si, se actualiza la lista de rutinas que podría estar siguiendo el usuario (que son todas las que parten del mismo lugar que partió el usuario), y en caso de que no, querría decir que el usuario se paró y se resetea la lista. if (act.getTime() - date.getTime() > 300000) { int medidas = shared.getInt("medidas", 0); if (medidas >= 6) { //Esta andando, Actualizo lista actualizarLista(loc); } else { //Se ha parado, Reseteo lista reseteaLista(loc); } • Private void reseteaLista(Location loc) Regenera la lista de posibles rutinas que el usuario podría seguir saliendo de la localización loc. También se busca la que debería estar haciendo a esa hora ese día, si es que existe para tenerla en especial consideración. • Private void actualizarLista(Location loc) Es el método que llama el monitor para ir actualizando la lista. La actualización de la lista consiste en ir eliminando de ella aquellas que ya no está siguiendo el usuario según el algoritmo. Es importante a la hora de ir Anexos realizando las comprobaciones con las frecuencias y tiempos, realizar un traslado de la fecha en que se produjo la rutina y se almacenó a la fecha actual para poder extraer las horas de salida y llegada que hay que tener en cuenta en el algoritmo. double v1 = (l1.distanceTo(l2) + 500) / (rlist.get(0).getRoutine().getEnd().getTime() - rlist.get(0).getRoutine().getStart().getTime()); long t1 = new Date().getTime() % 86400000; long t2 = rlist.get(0).getRoutine().getEnd().getTime() % 86400000; double v2 = (loc.distanceTo(l2)) / (t2 - t1); if (v2 > v1) { ids.remove(id); if (id.compareTo(shared.getString("probable", Integer.toString(-1))) == 0) { shownot("Se ha salido de la rutina más probable!"); } } Siendo en este fragmento l1 y l2 los lugares de salida y llegada respectivamente y loc la localización actual del usuario. En los casos de riesgo, es decir cuando no sigue la rutina más probable, o ya no sigue ninguna, se lanza una notificación al usuario y se envía un mensaje al cuidador para alertarlo. Anexos Anexo III Publicación Este trabajo ha servido de objeto para un articulo publicado en las jornadas SISTEDES de Ciencia e Ingeniería de Servicios JCIS 2015. El articulo se basa en una descripción de este trabajo en las fases iniciales del mismo para ir dando a conocer el modelo de PeaaS sobre el que se ha trabajado en el presente proyecto. A continuación se adjunta el articulo completo publicado. SafeWalks: aplicación móvil de supervisión de pacientes de Alzheimer Pablo Pérez Lozano1, Alejandro Pérez Vereda2, Juan Manuel Murillo1, Carlos Canal2 1 Universidad de Extremadura; 2 Universidad de Málaga [email protected]; [email protected]; [email protected]; [email protected] Abstract. El principal objetivo de Internet of Things (IoT) es integrar las tecnologías informáticas en el quehacer cotidiano de las personas, facilitando su interacción con un entorno de dispositivos interconectados, pero el estado actual del arte hace que dicha interacción esté aún lejos de resultar trivial, precisando de continua intervención del usuario. El modelo People as a Service (PeaaS) pretende facilitar estas tareas por medio del uso del teléfono móvil como interfaz del usuario con IoT. PeaaS permite elaborar un perfil sociológico del usuario, que puede ser explotado por el mismo y servido a terceros de forma controlada. En este trabajo presentamos una aplicación móvil para la supervisión de personas afectadas de alzheimer como prueba de concepto del modelo PeaaS, teniendo como resultado una funcionalidad que va mucho más allá de la ofrecida por otros productos similares en este campo. 1 Introducción El principal objetivo de Internet of Things (IoT) es integrar las tecnologías informáticas en el quehacer cotidiano de las personas [1, 2], de forma que, por ejemplo, se encienda de forma automática la cafetera para tener el café preparado al levantarnos, incluso planificando esta tarea de acuerdo con nuestros hábitos diarios. Sin embargo, la forma en que esta integración se lleva a cabo en la actualidad es notablemente susceptible de mejora, quedando aún un salto entre la red donde la información es tratada e intercambiada y la realidad de la vida física y su contexto [3]. En general, el usuario necesita configurar diversos parámetros del sistema en cuestión de forma manual, lo cual, lejos de hacer que la tecnología trabaje para las personas, las obliga a estar pendientes de introducir nuevas órdenes o modificar la planificación siempre que se produzca un cambio inesperado en sus hábitos. En un escenario de IoT más adecuado, la tecnología debería tener en cuenta el contexto de las personas a las que debe servir, aprendiendo de dicho contexto y realizando acciones de forma proactiva de acuerdo con su situación y expectativas en cada momento. Así, cuando una persona pone el despertador más tarde de lo habitual, le gustaría que el café empezará a hacerse en el momento adecuado para tomárselo caliente al levantarse. Esto es lo que plantea el modelo People as a Service (PeaaS) [4]. PeaaS se basa en el uso de smartphones como representantes e interfaces de los usuarios con IoT, debido a que este tipo de dispositivos son altamente personalizados, y acompañan a sus propietarios a lo largo de sus actividades diarias y, en particular, en la mayor parte de sus interacciones en Internet, acumulando una gran cantidad de información sobre ellos [5,6]. PeaaS es un modelo social que pone su énfasis en el usuario como proveedor de servicios y le permite controlar la información que ofrece su dispositivo móvil, dando especial importancia a aspectos de privacidad y de seguridad. Con la intención de validar este modelo, y como prueba de concepto del mismo, este trabajo se centra en el desarrollo de una aplicación Android para el seguimiento de personas con capacidades intelectuales mermadas, pero con cierto grado de autonomía, como pueden ser las personas con alzheimer. El objetivo es que el teléfono móvil aprenda los patrones habituales del usuario (horarios, rutinas de desplazamiento, etc.), de forma que pueda supervisar dichas actividades y realizar acciones (por ejemplo, alertas al paciente o a sus familiares) en caso de un cambio inesperado en dichos patrones. La propuesta entronca con el interés actual en el desarrollo de productos software relacionados con la salud de los usuarios. Es tal el crecimiento de este sector que incluso Google ofrece una API1 para la creación de aplicaciones destinadas a fomentar hábitos saludables de una forma más fácil, rápida y eficiente. La estructura de este artículo es la siguiente. La Sección 2 presenta y discute la motivación del trabajo y su campo de aplicación. La Sección 3 desarrolla los principales aspectos técnicos del mismo, incluyendo entre otros la descripción del caso de estudio, la arquitectura de la aplicación, el procedimiento de análisis de detección de rutinas y el estado actual del producto. La Sección 4 hace un repaso de los principales trabajos relacionados. Por último, la Sección 5 recoge las conclusiones de este trabajo. 2 Motivación Este trabajo se enmarca en el desarrollo de una plataforma software que mejore cómo las personas se integran en IoT, para lo que se hace uso de la información contextual y perfil de usuario alojado en sus teléfonos móviles, paliando así las limitaciones actuales de este tipo de sistemas. Esto abre camino a la transición del actual modelo de IoT hacia el que podríamos llamar Internet of People (IoP) [7]. Esta línea de investigación parte de trabajos anteriores sobre los modelos y plataformas Social Devices [8,9] y PeaaS. Social Devices es una plataforma desarrollada en la Universidad de Tampere que tiene por objeto enriquecer, incrementar y facilitar las interacciones entre personas geográficamente próximas y entre ellas e IoT. Por otro lado, PeaaS, es un modelo y plataforma de computación móvil que permite la gestión de perfiles sociológicos de los usuarios, que son inferidos y almacenados en el propio dispositivo móvil y proporcionados a terceros como un servicio en la Nube, de manera segura y controlada por su propietario. La combinación de ambos modelos permite convertir el teléfono móvil en la interfaz 1 Google Fit. http://developers.google.com/fit/ natural entre las personas e IoT, de forma que este almacena toda la información contextual necesaria e interactúa con IoT en consecuencia, minimizando la necesidad de intervención del usuario. En la actualidad, con la aparición en el mercado de diversos dispositivos wearable, el sector de IoT está experimentando un gran crecimiento y difuminando las fronteras que había en cuanto a lo que es posible hacer con estas tecnologías. La mayoría de estos dispositivos salen al mercado en una línea claramente dirigida hacia sanidad y hábitos saludables. Esto es lo que nos ha llevado a elegir este sector como la prueba de concepto más adecuada. Existen en la actualidad diversas aplicaciones móviles para la ayuda de personas con alzheimer, entre las que podemos citar Cerqana2 y Tweri3. Sin embargo, ninguna de ellas considera el aprendizaje automático de rutinas y patrones de desplazamiento. Esto sin duda es una gran ventaja de nuestra aplicación sobre las ya existentes, ya que minimiza la necesidad de configuración de distintos parámetros que pueden ser complejos. De esta manera se facilita el uso de la aplicación tanto a los enfermos, que suelen tener edad avanzada y no tienen interiorizado el uso del teléfono, como a sus cuidadores, que simplemente recibirán notificaciones cuando sea oportuno. Para ello, nuestra propuesta sigue el modelo de la pirámide DIKW, que distingue entre los niveles de datos, información, conocimiento y sabiduría [10]. Así, partiendo de la recolección y agregación de datos de geolocalización temporal del teléfono móvil, se obtiene información sobre lugares y trayectorias habituales del usuario. A partir de esta información, es posible inferir conocimiento sobre sus rutinas de desplazamiento y frecuencia de las mismas, adquiriendo finalmente la sabiduría necesaria para poder predecir comportamientos y detectar desviaciones en los mismos, tomando decisiones de emisión de alertas en caso necesario. 3 Una aplicación para enfermos de alzheimer El escenario elegido como prueba de concepto del modelo PeaaS consiste en el desarrollo de SafeWalks, una aplicación para ayudar a personas con alzheimer en las fases iníciales de esta enfermedad. Con ella se quiere contribuir a mejorar su calidad de vida y la de sus cuidadores. El síndrome de Alzheimer, es una enfermedad degenerativa que produce un deterioro de las neuronas del cerebro. Esto afecta al enfermo con síntomas como pérdida de memoria, desorientación o pérdida de otras capacidades mentales que pueden resultar muy peligrosas para su seguridad. Estos síntomas pueden manifestarse con mayor fuerza en ciertos momentos, afectando a la persona de inmediato. Por ejemplo, el enfermo ha salido de casa a realizar alguna actividad y durante ella olvida el propósito de lo que estaba haciendo o cómo volver a casa. Existen alrededor de 24 millones de personas afectadas por alzheimer en el mundo, y se estima que esta cifra alcanzará los 80 millones dentro de 20 años. Esta enfermedad no solo afecta a los pacientes, sino que también condiciona la vida de sus cuidadores, ya que les obliga a estar constantemente pendientes de ellos y 2 Cerqana. http://www.cerqana.es 3 Tweri. http://www.tweri.com preocupados por su situación. Con objeto de contribuir a la mejora de esta situación, nos planteamos el desarrollo de una aplicación para dispositivos móviles basada en PeaaS y capaz de aprender las rutinas de desplazamiento del usuario. La motivación para ello fue doble. Por un lado la penetración cada vez mayor de los dispositivos móviles incluso entre la población mayor. Por otro, las ventajas que proporciona PeaaS para potenciar el uso del contexto de los usuarios de dispositivos móviles. La aplicación diseñada incorpora dos componentes funcionales: Dispositivo Paciente: Es el componente principal y se trata de una aplicación Android que reside en el dispositivo del paciente. Valiéndose de la información facilitada por el GPS del dispositivo, la aplicación registra los desplazamientos del usuario y los analiza para aprender y detectar sus rutinas. Comprueba continuamente si los desplazamientos realizados son acordes a dichas rutinas, sino emite avisos tanto al paciente como a su cuidador según diferentes niveles de alarma que pueden ser configurados. SafeWalks utiliza, analiza y pone al servicio de otros su contexto. La aplicación también permite indicar qué cuidadores tendrán acceso a este contexto. Dispositivo Cuidador: De nuevo es una aplicación Android, que en este caso reside en el dispositivo del cuidador. A través de ella el cuidador puede realizar un seguimiento de la posición del paciente y configurar de forma remota la aplicación de este indicando los niveles de alarma deseados y las actuaciones a llevar a cabo en la detección de cada nivel. La aplicación se encarga de recibir y procesar las alarmas dándoles el tratamiento adecuado. 3.1 Arquitectura En esta sección se describe la arquitectura adoptada para integrar PeaaS en el desarrollo de la aplicación. La Figura 2 muestra dicha arquitectura. Fig. 1. Arquitectura de componentes El componente Acumulador se encarga de registrar los datos de desplazamiento del paciente. Para ello detecta cuándo el paciente se pone en movimiento y, a partir de ese momento y hasta que de nuevo entre en reposo, va registrando sus coordenadas GPS, velocidad y dirección, con una cadencia variable. Toda esta información es