Agente IoT de FIWARE para el control de un dispositivo de monitorización de actividad física

i Equation Chapter 1 Section 1 Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Agente IoT de FIWARE para el control de un dispositivo de monitorización de actividad física Autor: Rafael Díaz Fernández Tutor: Jorge Calvillo Arbizu Dpto. Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2019 iii Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Agente IoT de FIWARE para el control de un dispositivo de monitorización de actividad física Autor: Rafael Díaz Fernández Tutor: Jorge Calvillo Arbizu Departamento de Ingeniería Telemática Dpto. Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2019 v Trabajo Fin de Grado: Agente IoT de FIWARE para el control de un dispositivo de monitorización de actividad física Autor: Rafael Díaz Fernández Tutor: Jorge Calvillo Arbizu El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2019 El Secretario del Tribunal vii A mi familia A mis maestros ix Agradecimientos Estos cuatro años de grado han sido los más duros académicamente de mi vida, pero también los que mayor satisfacción me han dado. He podido conocer a personas maravillosas que, sin duda, me acompañarán toda mi vida, he adquirido una gran cantidad de conocimientos de mano de profesores muy cualificados y he sido muy bien preparado para mi futura vida laboral. En primer lugar, quería agradecer a mis padres su apoyo incondicional durante todo el grado, sin presionarme en ningún momento y prestándome todo tipo de facilidades para que mi desarrollo en la carrera fuera el máximo posible. Estos años me han hecho madurar mucho, y he aprendido a valorar vuestro esfuerzo para que mi hermano y yo hayamos vivido sin preocupación alguna más que la de estudiar y formarnos. Me he abierto más a ustedes como persona y me encanta salir, viajar y hacer planes con vosotros. Desde pequeño me habéis inculcado la cultura del esfuerzo y sin ustedes no sería nada de lo que soy hoy. También agradecer a mi hermano Alberto, por tenerme como referencia y motivarme a seguir, y digo esto porque lo veo en tus ojos cada vez que cuento en casa algún pequeño éxito que haya conseguido, al igual que en los de papá y mamá. Es insuficiente este párrafo para agradeceros todo lo que habéis hecho por mi. Gracias a los tres. Por otro lado, me gustaría agradecer a mis compañeros por el genial grupo de trabajo que hemos formado. El trabajo en grupo, en mi opinión, es uno de los aspectos más importantes para tener éxito en el grado, y nuestro grupo era un muy buen equipo. Además, habéis conseguido hacer el camino muy ameno. Me llevo muchos amigos de esta experiencia en Sevilla: Gonzalo, Antonio, David, Manu, Vicente…, pero en especial a Luis, Juan y Leo. Desde el primer día que llegué a la residencia, Luis me ha acompañado en mi día a día y nos hemos vuelto inseparables. Desde su gran brillantez, nos ha ayudado siempre que ha podido, e incluso cuando tampoco podía, facilitándonos así muchas asignaturas de la carrera y ejerciendo de profesor particular en algunas ocasiones, véase Comunicaciones Digitales. Se ha convertido en un hermano para mí. A Leo y Juan los conocí uno de los primeros días, que iban a la cafetería y les dije que iba con ellos. Uno de los mayores aciertos de la carrera, pues son unas maravillosas personas y también hemos pasado estos cuatro años juntos, lo que nos ha hecho ser unos amigos de verdad. De ellos tres sé que, aunque acabemos en distintos lugares, nunca vamos a dejar de vernos, pues no querría dejar atrás a estas maravillosas personas, y sé que ellos tampoco querrán. Por último, debo agradecer a mis profesores del grado por su enseñanza y exigencia, que nos ha formado como buenos ingenieros de telecomunicaciones, con vistas al mundo laboral, donde tendremos que lidiar con problemas para los que salimos muy bien preparados. En especial, a Jorge Calvillo, mi tutor del TFG, que me ha ayudado en todo momento con el proyecto, guiándome y ofreciéndome facilidades para que el desarrollo del mismo se produjera lo mejor posible. Rafael Díaz Fernández Sevilla, 2019 3.1.3.5 Requisitos de integración con el sistema 30 3.2. Diseño del mapeo 31 3.1.1. Mensajes para Orion Context Broker 31 3.1.2. Definición y reutilización de entidades de FIWARE 31 3.3. Desarrollo del Agente IoT en la aplicación móvil 34 3.3.1. Actividad Registro 36 3.3.2. Actividad MainActivity 37 3.4. Desarrollo del Servicio Web 40 3.4.1. Componente Home 41 3.4.1.1 Servicio DataService 43 3.4.1.2 Servicio BbddService 43 3.4.2. Componente About 44 3.5. Pruebas y validación 45 3.6. Ejecución de la solución completa 45 4 Conclusiones y líneas futuras 49 Anexo A: Manual de instalación y despliegue del OCB 52 Anexo B: Manual de instalación y despliegue de la solución desarrollada 54 Referencias 58 xvii ÍNDICE DE TABLAS Tabla 1. Búsqueda y obtención de información 4 Tabla 2. Curso de Angular 4 Tabla 3. Diseño 5 Tabla 4. Implementación de la aplicación móvil 5 Tabla 5. Implementación del servicio web 5 Tabla 6. Pruebas y validación 6 Tabla 7. Documentación 6 Tabla 8. Tiempo total 6 Tabla 9. Requisito general número 1 23 Tabla 10. Requisito general número 2 24 Tabla 11. Requisito general número 3 24 Tabla 12. Requisito general número 4 24 Tabla 13. Requisito general número 5 25 Tabla 14. Requisito general número 6 25 Tabla 15. Requisito de información número 1 25 Tabla 16. Requisito de información número 2 26 Tabla 17. Requisito de reglas de negocio número 1 26 Tabla 18. Requisito de reglas de negocio número 2 27 Tabla 19. Requisito de reglas de negocio número 3 27 Tabla 20. Requisito de fiabilidad número 1 27 Tabla 21. Requisito de fiabilidad número 2 28 Tabla 22. Requisito de eficiencia número 1 28 Tabla 23. Requisito de eficiencia número 2 28 Tabla 24. Requisito de portabilidad número 1 29 Tabla 25. Requisito de portabilidad número 2 29 Tabla 26. Requisito de seguridad número 1 30 Tabla 27. Requisito de integración número 1 30 xix ÍNDICE DE FIGURAS Figura 1. Solución planteada 3 Figura 2. Definición de IoT en su forma más simple 7 Figura 3. Evolución del número de dispositivos conectados por persona 8 Figura 4. Logo de FIWARE 9 Figura 5. Elementos de un sistema IoT construido en torno a FIWARE 9 Figura 6. Estructura del Orion Context Broker 10 Figura 7. Diagrama de clases de una entidad de FIWARE 11 Figura 8. Android Studio en macOs 12 Figura 9. Camiseta inteligente 13 Figura 10. Modos de funcionamiento del módulo de actividad física de la camiseta y los respectivos métodos para pasar de uno a otro. 14 Figura 11. Funcionamiento de Postman Echo para una supuesta petición al servidor de postman-echo.com. 15 Figura 12. Interfaz de Postman Echo tras una petición GET hecha a Orion Context Broker 15 Figura 13. Interfaz de Visual Studio Code 16 Figura 14. Logo de Angular 17 Figura 15. Logo de TypeScript 17 Figura 16. Código escrito en HTML 19 Figura 17. Logo de Bootstrap 20 Figura 18. Servicios ofrecidos por Firebase 21 Figura 19. Respuesta de Orion al updateRequest de la entidad "Person" 32 Figura 20. Ejemplo de entidad de tipo "PhysicalActivity" 33 Figura 21. Ejemplo de entidad de tipo "Person" 33 Figura 22. Ejemplo de entidad de tipo "Device" 34 Figura 23. Ejemplo de entidad de tipo "Alert" 35 Figura 24. Solución parcial correspondiente al Agente IoT 35 Figura 25. Permisos en el archivo AndroidManifest.xml 36 Figura 26. Método PostRequest de la actividad Registro 36 Figura 27. Vista de la actividad Registro 37 Figura 28. Conexión con la camiseta inteligente y módulo de actividad física 38 Figura 29. Comprobación para la impresión de mensajes enviados a Orion 38 Figura 30. Impresión de mensajes enviados a Orion 38 Figura 31. Vista de la actividad MainActivity 39 Figura 32. Código del archivo network_security_config.xml 40 xxi Figura 33. Solución parcial correspondiente al Servicio Web 40 Figura 34. Interfaz de usuraio de la Realtime Database de Firebase 41 Figura 35. Servicio web en su vista principal 41 Figura 36 Tabla de progresión reciente del servicio web y datos de registro del paciente 42 Figura 37. Tipo de dato Post 42 Figura 38. Función mostrarProgreso 43 Figura 39. Función postKcalInfo 44 Figura 40. Servicio web en su vista secundaria, correspondiente al componente About 44 Figura 41. Ejecución del Agente IoT: Vista de la actividad Registro 46 Figura 42. Ejecución del Agente IoT: Vista de la actividad MainActivity 46 Figura 43. Ejecución del Servicio Web: Vista principal al acceder al servicio 47 Figura 44. Ejecución del Servicio Web: Vista principal una vez introducido el nombre del paciente 47 Figura 45. Ejecución del Servicio Web: Base de datos de Firebase actualizada 48 Figura 46. Ejecución del Servicio Web: Vista secundaria informativa 48 Figura 47. Ventana inicial de Android Studio 54 Figura 48. Opción "Build and run" de Android Studio 55 Figura 49. Aplicación móvil desplegada y en uso 55 Figura 50. Servicio web desplegado y en uso 56 1 1 INTRODUCCIÓN omo introducción a esta memoria se podrá conocer la motivación para la realización de este proyecto, así como los objetivos del mismo. Además, podrá encontrarse la metodología adoptada y el plan de trabajo que se planteó al inicio, junto con la estimación temporal realizada y el tiempo real dedicado finalmente. 1.1 Motivación y objetivos 1.1.1 Motivación La inactividad física es, según la Organización Mundial de la Salud, el cuarto factor de riesgo de mortalidad mundial, así como la causa de entre el 21% y el 25% de los cánceres de mama y colon, el 27% de los casos de diabetes y aproximadamente el 30% de la carga de cardiopatía isquémica. Mientras, se ha demostrado que un nivel adecuado de actividad física de forma regular reduce el riesgo de hipertensión, diabetes, distintos tipos de cánceres como el de mama o colon, depresión, hipertensión… además de mejorar la salud ósea y funcional y ser determinante clave en el gasto energético, siendo fundamental para el control de peso. [1] Los programas de ejercicio multicomponente y, en particular, el entrenamiento de fuerza, constituyen las intervenciones más eficaces para retrasar la discapacidad y otros eventos adversos [2]. Además, la actividad física no sólo tiene consecuencias en la prevención de enfermedades, sino que es usado como tratamiento de las mismas. Son muchas las patologías cuyo tratamiento principal consiste en la realización de ejercicio físico del paciente, siendo una de ellas la enfermedad pulmonar obstructiva crónica (EPOC). Sin embargo, una de las características de estos tratamientos es que su realización se lleva a cabo fuera del entorno médico y, por ello, dependen casi exclusivamente del paciente. Esto puede llevar a una incorrecta realización de los ejercicios y una pobre adhesión al tratamiento. Es por ello que el seguimiento del tratamiento de los pacientes en este tipo de enfermedades se complica, pues no puede saberse exactamente cómo se ha llevado a cabo, ni siquiera si realmente se ha realizado, más que por la palabra del paciente. Así, la monitorización del ejercicio físico supone una gran ayuda al equipo médico encargado, obteniendo así los datos de los ejercicios realizados, aportando exactitud al tratamiento y mejorando su observación. La camiseta inteligente desarrollada por el Grupo de Ingeniería Biomédica de la ETSI recoge datos de la actividad física del paciente, acompañándolo en la realización de actividad física y monitorizando sus ejercicios. Esto permite saber qué ejercicios se realizan y cómo. Sin embargo, en el estado actual de desarrollo de la camiseta, estos datos no pueden ser accedidos fácilmente por profesionales sanitarios que quieran conocer la información recogida, luego se necesitaría facilitar este acceso, como siguiente paso en el desarrollo del C Look up at the stars and not down at your feet. Try to make sense of what you see, and wonder about what makes the universe exist. Be curious. - Stephen Hawking - 2 dispositivo. En la monitorización remota convendría disponer de los datos recogidos en la nube, ofreciendo la posibilidad de acceder a los datos del paciente en cualquier momento y en cualquier sitio, con exactitud y sin lugar a fallos, dando lugar a un control exhaustivo del tratamiento. Esto se puede llevar a cabo con una solución propietaria, pero en la actualidad existen interesantes opciones a considerar como el Internet of Things (IoT). El uso del IoT para la disponibilidad de los datos en la nube conlleva una serie de ventajas, tales como la automatización de los procesos y una mayor flexibilidad, al poder incluir cualquier tipo de dispositivo en la red, entre otras. Además, permite un análisis de datos óptimo y profundo y un aprovechamiento de recursos disponibles a todo el mundo para la realización de soluciones específicas, lo cual puede llevar a un ahorro en el presupuesto dedicado. Por este motivo, la motivación del proyecto es integrar la camiseta inteligente en una plataforma de IoT abierta, que permita almacenar los datos de manera automática para que otros sistemas puedan disponer de ella, así como el acceso del equipo médico a ellos fácilmente, en cualquier momento y en cualquier lugar. Además, otra de las motivaciones del trabajo es poner en práctica los conocimientos aprendidos en el Grado y profundizarlos, así como la investigación de nuevas tecnologías para el desarrollo de estas soluciones. 1.1.2 Objetivos Como principal objetivo del proyecto, se encuentra el diseño y desarrollo de un Agente IoT para la plataforma FIWARE que actúe de intermediario entre una camiseta inteligente, que recoge datos de la actividad física del usuario, y FIWARE, permitiendo a cualquier usuario autorizado acceder a la información de una forma fácil y segura. Este agente se deberá llevar a cabo en una aplicación móvil para Android, pues la camiseta inteligente está diseñada para que se comunique con ella, la cual debe tener conexión a internet para mandar los datos a la nube, y que permite al usuario visualizar la información recogida y enviada en la misma pantalla. El objetivo principal se puede descomponer en los siguientes subobjetivos: • Estudio de FIWARE y sus componentes. Es importante conocer bien la plataforma IoT a utilizar, pues queremos aprovechar sus ventajas para la solución. • Mapeo de entidades para enviar a FIWARE, que contengan los datos recogidos por la camiseta. • Diseño de la solución completa (aplicación móvil, servicio de almacenamiento de datos, interfaz de visualización…) • Desarrollo de la aplicación móvil, que funcione como Agente IoT entre la camiseta y FIWARE. Como objetivo secundario y con el fin de alcanzar una resolución más completa, se realizará un servicio web que actúe de consumidor de la información enviada a FIWARE y utilice una base de datos para guardarla y registrar el progreso realizado, permitiendo al usuario profesional ver los datos más recientes de la camiseta inteligente y conocer los recogidos en los días anteriores. Este objetivo secundario también puede descomponerse en varios subobjetivos: • Conocimiento y estudio de las tecnologías a aplicar en la creación del servicio. • Desarrollo del servicio web, que consuma los datos de actividad física almacenados en FIWARE. • Integración del servicio con una base de datos, dando lugar a una solución más completa. 3 1.2 Solución planteada Se ha propuesto una aplicación móvil para Android que actúe como Agente IoT de FIWARE entre la camiseta inteligente y el Orion Context Broker de FIWARE, servidor que implementa una API de tipo REST mediante el protocolo de comunicación HTTP y que permite el acceso de los consumidores a esos datos, así como la suscripción a ellos. La solución diseñada usará FIWARE pues es una plataforma IoT abierta de fácil implementación y escalabilidad, que ofrece APIs estandarizadas para el desarrollo de aplicaciones y que está en continuo crecimiento. La camiseta inteligente se comunica con el agente IoT mediante la tecnología MQTT, permitiendo que los datos lleguen a la aplicación móvil mediante mensajes JavaScript Object Notation (JSON). Figura 1. Solución planteada. La aplicación móvil producirá mensajes para el Context Broker mediante peticiones POST. Además, queremos que la aplicación móvil muestre los mensajes que se mandan a FIWARE, para conocer así qué es exactamente lo que se está enviando. En cuanto al servicio web a desarrollar, éste realizará peticiones GET a Orion y mostrará por pantalla los datos recibidos. También tendrá acceso a una base de datos de Google, Firebase, que guardará la información obtenida y permitirá crear una tabla para observar el progreso realizado en los últimos días. Se utilizarán varias tecnologías para su creación, destacando entre ellas Angular y Bootstrap, para el apartado visual. 10 2.2.1 Orion Context Broker (OCB) El componente más importante de FIWARE y el único imprescindible y obligatorio en cualquier solución desarrollada con esta plataforma es el Orion Context Broker. Se trata de un servidor que permite administrar la información de contexto, consultarla y actualizarla, basándose en peticiones de una API tipo REST sobre el protocolo de transporte HTTP. La información de contexto es publicada y actualizada por los productores de contexto, que son aquellos sensores, agentes IoT y demás dispositivos que registran y envían información a FIWARE para que otros puedan acceder a ella, los denominados consumidores de contexto, interesados en analizar y procesar estos datos. Figura 6. Estructura del Orion Context Broker. [9] El OCB es un servidor que implementa una API que se basa en el modelo de información NGSI, por medio del cual se pueden realizar varias operaciones [9]: • Registrar información de proveedores de contexto. • Ser notificado ante una actualización de la información automáticamente, gracias a las suscripciones de los consumidores a los datos. • Consultar información de contexto. Orion se encuentra constantemente escuchando en un puerto, que por defecto es el 1026, y utiliza la base de datos MongoDB [10] para almacenar el estado actual de la información de las entidades, sin almacenar información histórica de sus cambios. Un principio fundamental que soporta el Orion Context Broker es el de lograr una disociación total entre productores y consumidores de contexto. Esto quiere decir que los productores enviarán datos a la nube sin saber quién va a acceder a esa información, mientras que los consumidores no necesitan conocer quién ha subido la información que se ha publicado en un evento en concreto. Es por todo ello que los consumidores y los productores no necesitan estar conectados entre ellos, mas que tener acceso a la plataforma de FIWARE. 11 2.2.1 Modelo NGSI La comunicación entre los distintos componentes de la red de FIWARE formada, con el Orion Context Broker en su núcleo, se lleva a cabo por el uso de una API RESTful NGSI. Es por ello que la información está representada en estructuras de datos genéricos referidos como elementos de contexto. Se tienen actualmente dos versiones de esta API que funcionan conjuntamente sin problemas: NGSIv1 y NGSIv2. La versión 2 de esta API incluye la posibilidad de incluir metadatos en los mensajes enviados a Orion. En este proyecto se ha utilizado la versión 1, pues no necesitamos la inclusión de metadatos, además de que es la más usada y extendida actualmente, en las peticiones de POST, mientras que en las de GET se ha usado la versión 2. Un elemento de contexto se refiere a la información que es producida, recopilada o consultada y que puede ser relevante en su posterior procesamiento, análisis y extracción de nuevo conocimiento. Tiene asociado un valor definido que consiste en una secuencia de uno o más triplas que se refieren a atributos de un elemento de contexto. [6] Además, FIWARE permite crear entidades con estructuras de datos tanto básicas como complejas. Un elemento de contexto proporciona información relevante en torno a una entidad, cada una identificada exclusivamente por su id (EntityId) y su tipo (EntityType). Figura 7. Diagrama de clases de una entidad de FIWARE. Fuente: [7] La tecnología usada en los mensajes enviados al Context Broker es JSON, permitiendo la fácil creación de entidades con pares atributo-valor. Las respuestas ante las peticiones RESTful al servidor también son enviadas en código JSON con distintos valores según si la acción ha tenido éxito o ha ocurrido algún error. Las operaciones estándar en NGSIv1 son las siguientes: • UpdateContext: Se usa para mandar nueva información de contexto a Orion. • QueryContext: Para solicitar datos al Context Broker. • SubscribeContext: Para suscribirse a una fuente de información de contexto. • UpdateContextSubscription: Para actualizar la suscripción a la fuente de información. • UnsuscribeContext: Para desuscribirse de la misma. En cuanto a NGSIv2, en este trabajo solo se usará para hacer las peticiones GET del servicio web a Orion, es decir, tan solo se usará la operación Entities y sus argumentos, que devuelve las entidades que coinciden con los argumentos dados. 2.3 e-Salud La e-Salud es el término por el que es conocido el conjunto de tecnologías de la información y la comunicación que se emplean en el entorno sanitario a modo de herramientas en materia de prevención, diagnóstico, tratamiento, seguimiento, además de la gestión de la salud, permitiendo una mejora de la eficacia del mismo, así como un ahorro de costes al sistema sanitario.[11] Como componentes que engloba este término encontramos diferentes modelos, productos y servicios tecnológicos aplicados al campo de la salud, tales como aplicaciones móviles, la telemedicina, el Big Data, los 12 sistemas de apoyo a la decisión clínica, el IoT y los dispositivos wearables, como la camiseta inteligente usada en este proyecto, entre otros. Como principales características buscadas en el desarrollo de tecnologías de e-Salud encontramos: • La consecución de una medicina personalizada y centrada en cada uno de los pacientes. • La atención contínua a un paciente, permitiendo que pueda continuar con su vida en la normalidad. • La extensión de las capacidades asistenciales más allá de las organizaciones sanitarias, siempre dentro de un ecosistema de elementos cooperantes de la salud. • La búsqueda de nuevos escenarios asistenciales, que mejoren la asistencia al paciente. 2.4 Materiales En este apartado se detallarán los elementos utilizados para la realización del proyecto, así como programas o dispositivos que hayan resultado de gran importancia en el trabajo. 2.4.1 Android Studio Android Studio es el entorno de desarrollo oficial de aplicaciones de Android. La primera versión de este programa fue publicada por Google en 2014. Está disponible para las plataformas de Microsoft Windows, macOs y Linux. Ahora mismo, se encuentra en la versión 3.4.2 para macOs. Se trata del programa principal usado para el desarrollo de este proyecto, donde se ha realizado el agente IoT y la aplicación móvil que lo contiene. Figura 8. Android Studio en macOs. Como características principales hasta la última versión tenemos las siguientes [12]: • Integración de ProGuard y funciones de firma de aplicaciones. • Mayor especificación a la hora de la programación. • Renderizado en tiempo real. • Consola de desarrollador: consejos de optimización, ayuda para la traducción y estadísticas de uso. 13 • Soporte para construcción basada en Gradle. • Refactorización específica de Android y arreglos rápidos. • Editor de diseño enriquecido que permite arrastrar y soltar componentes en la interfaz de usuario. • Herramientas Lint para detectar problemas de rendimiento y compatibilidad entre versiones, entre otros. • Plantillas para crear diseños comunes de Android. • Soporte para programar aplicaciones para Android Wear. • Distintos dispositivos virtuales de Android con el objetivo de ejecutar y probar las aplicaciones desarrolladas. • Herramienta de depuración integrada, para encontrar fallos en el programa. Android Studio soporta todos los lenguajes de programación de IntelliJ, un entorno de desarrollo integrado para el desarrollo de programas informáticos basado en Java, tales como Java o C++. Además, a partir de la versión 3.0 de Android Studio, se soporta Kotlin, el lenguaje preferido por Google para el desarrollo de aplicaciones móviles, y todas las características de Java7 y Java8, así como algunas de Java9, aunque de momento no está claro la compatibilidad de Java12 en Android. 2.4.2 Camiseta Inteligente para el reconocimiento de actividad física La camiseta inteligente utilizada en este trabajo es un dipositivo que recoge datos de la actividad física del usuario que la lleva puesta. Tiene como objetivo principal la monitorización del ejercicio del paciente, aplicando una tecnología precisa, simple y no obstructiva mediante un sensor capacitivo, integrado en la camiseta. Figura 9. Camiseta inteligente. Se compone de un sensor capacitivo, que actúa en la recolección y primer procesamiento de la información para la monitorización en tiempo real del ejercicio. Este sensor está integrado en un elástico ajustable colocado en el pecho del paciente, dando lugar a la camiseta. Ésta se comunica con una aplicación móvil, en principio, sin interfaz, mediante el protocolo ligero MQTT, estableciendo así una red de área corporal (WBSN) y permitiendo un bajo consumo de batería. [13] La camiseta inteligente dispone de un diseño modular apoyado en los siguientes elementos: 14 • Unidad de sensor. Se trata del módulo que recoge la señal monitorizada. Está formada por un sistema de electrodos y de condicionamiento de la señal. • Unidad de procesado. Se encarga del procesado de la señal para estimar la frecuencia respiratoria y los datos de actividad física. • Unidad de comunicación. Es el módulo encargado de la comunicación con la aplicación móvil. Utiliza MQTT y Bluetooth. La API de la que dispone el biosensor provee una capa de abstracción entre el terminal móvil y la camiseta inteligente, facilitando así la monitorización de la actividad física. La API está constituida por un conjunto de módulos funcionales que se encargan de la gestión de los eventos relacionados con la información recogida por el dispositivo. Estos módulos son los siguientes: [14] • Módulo de monitorización respiratoria, que notifica periódicamente los datos asociados a la respiración del paciente. • Módulo de actividad física, el cual notifica periódicamente la información asociada a la realización de actividad física del paciente en condiciones normales o realizando algún ejercicio en particular. El proyecto se centra en el módulo de actividad física. Esta unidad tiene tres modos de funcionamiento, modo IDLE o inactivo, NORMAL y EXERCISE, en el cual se está ejecutando un ejercicio concreto. La periodicidad con la que se reciben los datos viene dada por un periodo de muestro. Figura 10. Modos de funcionamiento del módulo de actividad física de la camiseta y los respectivos métodos para pasar de uno a otro. 2.4.3 Postman Echo Postman Echo es un servicio que permite probar un cliente REST realizando simples peticiones de la API, todo ello a través de un entorno sencillo y muy visual. Proporciona diferentes tipos de peticiones (GET, POST, PUT, entre otras), varios mecanismos de autenticación y otro tipo de utilidades. [15] Además, ofrece un apartado visual para las peticiones y las respuestas dadas por el servidor, así como las cabeceras que van junto con el mensaje. 15 Figura 11. Funcionamiento de Postman Echo para una supuesta petición al servidor de postman-echo.com. Fuente: [15] El funcionamiento de Postman Echo es el siguiente. Primero, se debe escribir la dirección web de la API a la que se desea acceder y el tipo de petición que se va a realizar. También, es importante incluir las cabeceras necesarias y el contenido del mensaje necesario para la petición de información. Una vez realizado esto, se envía la petición al servidor de la API, el cuál la recibe y devuelve una respuesta al usuario. Postman Echo recibe la respuesta y la muestra al usuario en su interfaz, permitiendo que la interacción sea simple y rápida. Figura 12. Interfaz de Postman Echo tras una petición GET hecha a Orion Context Broker. 16 2.4.4 Visual Studio Code Visual Studio Code es un editor de código fuente desarrollado por Microsoft y basado en Electron, un framework que se utiliza para implementar aplicaciones Node.js. Incluye soporte para la depuración, control integrado de Git, resaltado de sintaxis, finalización inteligente de código, fragmentos y refactorización de código. [16] También es personalizable, por lo que los usuarios pueden cambiar el tema del editor, los atajos de teclado y las preferencias. Es gratuito y de código abierto. Este editor es compatible con varios lenguajes de programación, pues incluye soporte para JavaScript, TypeScript y Node.js, además de tener un gran número de extensiones para otros lenguajes tales como C++, C#, Java, Python, PHP, Unity… También ofrece una interfaz al usuario bastante interesante, pues tenemos la posibilidad de abrir varias terminales en él y de ver a la izquierda de la pantalla todos los ficheros que componen el proyecto. Figura 13. Interfaz de Visual Studio Code. 2.5 Tecnologías usadas para el Servicio Web 2.5.1 Angular Angular es un framework para aplicaciones web desarrollado en TypeScript, de código abierto, mantenido por Google, que se utiliza para crear y mantener aplicaciones web de una sola página. Tiene como objetivo aumentar las aplicaciones basadas en navegador, implementando el Modelo Vista Controlador (MVC), en un esfuerzo para hacer que el desarrollo y las pruebas sean más fáciles.[17] La versión utilizada en este proyecto es la de Angular 7. 17 Figura 14. Logo de Angular. La biblioteca obedece a las directivas de los atributos personalizados al leer HTML que los contiene y une las piezas de entrada o de salida de la página a un modelo representado por las variables estándar de JavaScript. Está basado en clases de tipo Componentes, cuyas propiedades son las usadas para hacer el binding de los datos, permitiendo el routing, es decir, el acceso a un sistema de navegación en nuestra aplicación. Algunas de las principales características de Angular son las siguientes: • Velocidad y rendimiento. Angular convierte las plantillas en código altamente optimizado para las máquinas virtuales de JavaScript actuales, es universal, es decir, ejecuta la primera vista de aplicación en Node.js, PHP y otros servidores para renderizado, obteniendo así de forma casi instantánea solo HTML y CSS; y permite la división automática de códigos, con el objetivo de que los usuarios solo carguen el código necesario para el procesamiento de la vista solicitada en cada momento. • Productividad. Permite la fácil creación de vistas gracias a las plantillas simples y potentes que ofrece. También Angular CLI proporciona las herramientas de línea de comandos que ofrecen una forma fácil de crear componentes y servicios, así como obtener una previsualización del proyecto web y realizar tests de prueba. Por supuesto, también ofrece sugerencias de código inteligente, detección y corrección rápida de errores. • Historia completa del desarrollo. Permite un intuitivo seguimiento de los proyectos gracias a Git, además de la posibilidad de realizar pruebas unitarias con Karma y pruebas end-to-end con Protractor de forma rápida y estable. 2.5.1.1 TypeScript TypeScript es un lenguaje de programación de código abierto desarrollado por Microsoft, que cuenta con herramientas de programación orientada a objetos, lo cual facilita el desarrollo de grandes proyectos. [18] Puede ser usado para desarrollar aplicaciones JavaScript que se ejecutarán en el lado del cliente o del servidor (Node.js), pues extiende la sintaxis de JavaScript. Por lo tanto, cualquier código escrito en éste debe funcionar sin problemas. Figura 15. Logo de TypeScript. 18 El compilador de TypeScript está escrito asimismo en TypeScript, compilado a JavaScript y con Licencia Apache 2. Los ficheros de definición que contienen información sobre los tipos de librerías JavaScript existentes son también soportados por TypeScript. Esto permite a otros programas usar los valores definidos en los ficheros como si fueran entidades TypeScript de tipado estático. Poder definir los tipos durante el tiempo de diseño ayuda a evitar errores en tiempo de ejecución, como pasar el tipo de variable incorrecto a una función. Los tipos básicos admitidos por TypeScript son: • String: Define una cadena de caracteres. • Number: Tipo de dato que representa un número. • Boolean: Representa un tipo de dato de verdadero o falso. • Array: Es un tipo de dato estructurado que almacena una colección de elementos. • Tuple: Se trata de un tipo similar al Array, pero con un número fijo de elementos. • Enum: Es una enumeración de elementos. • Any: Se trata de una variable que puede ser de cualquier tipo. Es útil cuando no se sabe que variable va a devolver una librería externa. • Void: Indica que la función no devuelve nada. • Never: Representa el tipo de valores que nunca se producen. 2.5.1.2 HTML HTML es el estándar que sirve de referencia para la elaboración de páginas web en sus diferentes versiones. Define una estructura básica y un código HTML para la definición de contenido de una página web, como texto, imágenes, videos o juegos. Está estandarizado por el World Wide Web Consortium (W3C), organización dedicada a la estandarización de casi todas las tecnologías ligadas a la web, sobre todo en lo referente a su escritura e interpretación. Se considera el lenguaje web más importante siendo su invención crucial en la aparición, desarrollo y expansión de la World Wide Web (WWW). Además, se trata del estándar que se ha impuesto en la visualización de páginas web y el que todos los navegadores actuales han adoptado. [19] Fue inventado en 1991 por Tim Berners-Lee, incluyendo en su diseño inicial la descripción de 18 elementos fundamentales de HTML, de los cuales 13 aun existen en HTML4, pero no fue hasta 1993 que la IETF lo reconoció formalmente, mediante la publicación de una proposición para una especificación de HTML. Actualmente, existe la versión HTML5 publicada en 2014. El desarrollo de aplicaciones web mediante el lenguaje HTML se basa en la diferenciación. Para añadir un elemento externo a la página se debe hacer una referencia a la ubicación de dicho elemento mediante texto, no incrustarse directamente en ella. Así se consigue que la página web contenga solamente texto, mientras que la tarea de unir los elementos e interpretar el código para visualizar la página final recae sobre el navegador web utilizado. Al ser un estándar, HTML tiene como objetivo ser un lenguaje que permita que cualquier web pueda ser interpretada por cualquier navegador de la misma forma, independientemente de su versión. Sin embargo, a lo largo de sus distintas versiones, se han incluido y suprimido multitud de características con el fin de hacer más eficiente su interpretación en los distintos dispositivos y plataformas. Esto obliga a los desarrolladores a producir parches que los navegadores deben incorporar en sus nuevas versiones. Es por ello que los navegadores deben estar actualizados para interpretar correctamente las páginas web, lo que obliga a los desarrolladores a tener que aplicar técnicas y cambios en la visualización de los mismos, así como a corregir problemas de visualización e incluso de interpretación del código. Por estos motivos, aún existen diferencias al interpretar una misma página web dependiendo del navegador que se esté utilizando. 19 HTML se basa en una estructura compuesta por elementos, que tienen dos propiedades principales: atributos y contenido, cada una de ellas con ciertas restricciones para que el documento HTML se muestre válido. Cada elemento tiene normalmente una etiqueta de inicio y otra de cierre, encontrándose entre ellas el contenido, aunque hay algunos elementos tales como <br> (salto de línea), que no necesitan contenido ni etiqueta de cierre. También, este lenguaje propone un marcado estructural que, aunque no define cómo se mostrarán los elementos, la mayoría de navegadores web lo han estandarizado así. En cuanto a los atributos, la mayoría de ellos son pares nombre-valor separados por un signo de igual “=” y escritos en la etiqueta de comienzo de un elemento, justo después del nombre del mismo. Normlamente, los valores se encuentran entre comillas dobles o simples, exceptuando algunos tipos. Las etiquetas HTML básicas son:[20] • <html>: Define el nicio del documento e indica al navegador que lo que sigue a esa etiqueta será código HTML. • <script>: Permite la inclusión de un script en la web. • <head>: Define la cabecera del documento HTML. Dentro de ella podemos encontrar: <title>, <style>, <link>, entre otras. • <body>: Define el contenido principal o cuerpo del documento. Dentro de ella es posible encontrar numerosas etiquetas, tales como <h1> a <h6>, que representan encabezados de título con distinta relevancia, <table>, para usar tablas, <div>, para hacer una división a la página, útil para usarla conjuntamente con CSS, o <img>, para incluir una imagen en la web, entre otras. Figura 16. Código escrito en HTML. Este lenguaje puede ser creado y editado con cualquier editor de texto, tanto Gedit, Emacs, Sublime Text, Visual Studio Code, como con aquellos básicos, como pueden ser el Bloc de Notas de Windows, Wordpad, Notepad++, entre otros. 2.5.2 Bootstrap Se trata de una biblioteca multiplataforma que define un conjunto de herramientas de código abierto para el diseño de servicios y aplicaciones web, proporcionando un apartado visual atractivo al usuario. Contiene plantillas de diseño con tipografía, formularios, tablas, botones y otros elementos basados en HTML, CSS y, algunos, en JavaScript. Bootstrap hace que el diseño de la web sea compatible con distintos dispositivos, sin tener que hacer grandes cambios. La versión utilizada en este proyecto es Bootstrap4.[21] 26 Estado Analizado. Comentarios - Tabla 15. Requisito de información número 1. ID: Req_Inf_002 Almacenamiento de los datos de progreso de actividad física Versión 1.0 Descripción Al usar el Servicio Web se debe almacenar la información disponible en el Orion Context Broker en una base de datos. Importancia Media Prioridad Alta Estado Analizado. Comentarios - Tabla 16. Requisito de información número 2. 3.1.2.2 Requisitos de reglas de negocio En este subapartado se especifica qué reglas de negocio debe respetar el sistema, evitando que se incumplan durante su funcionamiento. ID: Req_Neg_001 Uso de API NGSI de FIWARE Versión 1.0 Descripción Deberá de utilizarse la API ya proporcionada por FIWARE para las tareas de envío y recepción de datos en la comunicación con el Context Broker. Importancia Alta Prioridad Alta Estado Analizado. Comentarios Puede utilizarse indistintamente tanto NGSIv1 como NGSIv2. Tabla 17. Requisito de reglas de negocio número 1. 27 ID: Req_Neg_002 Uso de API de Firebase Versión 1.0 Descripción Deberá de utilizarse la API ya proporcionada por Firebase para las tareas de envío y recepción de datos en la comunicación con la Realtime Database. Importancia Alta Prioridad Alta Estado Analizado. Comentarios - Tabla 18. Requisito de reglas de negocio número 2. ID: Req_Neg_003 Uso de API propia de la camiseta inteligente Versión 1.0 Descripción Deberá de utilizarse la API ya proporcionada por el equipo de desarrollo de la camiseta inteligente para el envío de mensajes entr el Agente IoT y la camiseta. Importancia Alta Prioridad Alta Estado Analizado. Comentarios - Tabla 19. Requisito de reglas de negocio número 3. 3.1.3 Requisitos no funcionales A continuación, se procede a especificar las condiciones que se le imponen al sistema relacionadas principalmente con aspectos de calidad, algunas de las cuales influyen en la arquitectura del sistema. 3.1.3.1 Requisitos de fiabilidad ID: Req_Fia_001 Máximo tiempo de inactividad continuada del agente IoT 10 minutos Versión 1.0 Descripción Las actualizaciones en la aplicación para mejorar los servicios ofrecidos a los usuarios no deben afectar a la calidad de servicio percibida por el usuario, por lo cual queda acotado el tiempo de inactividad, que no podrá superarse en el 99% de los casos. Importancia Alta 28 Prioridad Media Estado Analizado. Comentarios - Tabla 20. Requisito de fiabilidad número 1. ID: Req_Fia_002 Máximo tiempo de inactividad continuada del servicio web 10 minutos Versión 1.0 Descripción Las actualizaciones en la aplicación para mejorar los servicios ofrecidos a los usuarios no deben afectar a la calidad de servicio percibida por el usuario, por lo cual queda acotado el tiempo de inactividad, que no podrá superarse en el 99% de los casos. Importancia Alta Prioridad Media Estado Analizado. Comentarios - Tabla 21. Requisito de fiabilidad número 2. 3.1.3.2 Requisitos de eficiencia ID: Req_Efi_001 Tiempo medio de respuesta inferior a 500ms. Versión 1.0 Descripción El usuario debe recibir por pantalla los mensajes enviados por la camiseta con un retraso medio inferior a 500ms. Importancia Alta Prioridad Media Estado Analizado. Comentarios - Tabla 22. Requisito de eficiencia número 1. ID: Req_Efi_002 Tiempo máximo de respuesta inferior a 1s. Versión 1.0 Descripción El usuario debe recibir por pantalla los mensajes enviados por la camiseta en un tiempo inferior a 1s. 29 Importancia Alta Prioridad Media Estado Analizado. Comentarios - Tabla 23. Requisito de eficiencia número 2. 3.1.3.3 Requisitos de portabilidad ID: Req_Por_001 Compatibilidad con las versiones inferiores de Android Versión 1.0 Descripción La aplicación móvil del Agente IoT debe ser compatible con las versiones de Android 6.x (Marshmallow) y superiores. Importancia Media Prioridad Media Estado Analizado. Comentarios - Tabla 24. Requisito de portabilidad número 1. ID: Req_Por_002 Compatibilidad con las últimas versiones de los navegadores Google Chrome, Mozilla Firefox y Safari. Versión 1.0 Descripción El servicio web debe mantener la compatibilidad con las últimas versiones de los navegadores Google Chrome, Mozilla Firefox y Safari. Importancia Media Prioridad Media Estado Analizado. Comentarios Esto es conseguido al usar Angular, pues se encarga de que sea compatible con la última versión de los navegadores. Tabla 25. Requisito de portabilidad número 2. 30 3.1.3.4 Requisitos de seguridad ID: Req_Seg_001 Acceso por contraseña a base de datos Versión 1.0 Descripción Se pretende que la base de datos no sea accesible por nadie más que el desarrollador, es por ello que se propone el uso de un usuario y una contraseña para el acceso a la misma. Importancia Media Prioridad Media Estado Analizado. Comentarios Esto se consigue al usar Firebase, pues para acceder a la Realtime Database hace falta autenticarse mediante el usuario de Google. Tabla 26. Requisito de seguridad número 1. 3.1.3.5 Requisitos de integración del sistema ID: Req_Int_001 Integración de base de datos en servicio web Versión 1.0 Descripción La base de datos debe de estar correctamente integrada en el servicio web, con el objetivo de que se pueda guardar y consumir información de ella. Importancia Alta Prioridad Media Estado Analizado. Comentarios - Tabla 27. Requisito de integración número 1. 3.2 Diseño del mapeo Este apartado define el diseño realizado en cuanto a la definición y reutilización de entidades para su envío al Orion Context Broker de FIWARE, identificando los elementos de cada mensaje a enviar, así como la estructura de los mensajes enviados, en la versión NGSIv1 utilizada de la API. 3.2.1 Mensajes para Orion Context Broker Los mensajes enviados al Context Broker son entidades de datos, cuya creación es una de las bases de las soluciones desarrolladas con FIWARE. Las entidades contienen la información de contexto a enviar a Orion, y 31 debe de seguir una estructura determinada dependiendo de la API escogida. En nuestro caso, para hacer actualizaciones en el Context Broker, se ha usado NGSIv1. La estructura de las entidades a enviar de la versión 1 de NGSI se compone de tres campos iniciales: • “type” es el modelo de entidad a enviar. Define qué tipo de información se va a describir después y no es único. • “isPattern” describe si el usuario quiere que el ID escrito sea una expresión regular con la que luego poder obtener muchos elementos. • “id”, que identifica la entidad creada. Es único. Seguidamente, se deben especificar los atributos que se le quiere dar a la entidad. Cada atributo debe tener un nombre y un valor. Además, debe especificarse el tipo de variable que es. Así, si se va a escribir un número entero como valor del atributo, se deberá especificar que es un integer; si el valor del atributo de trata de una cadena deberá identificarse como string; y lo mismo con las demás variables. Por último, debe indicarse la acción de actualización que queremos que se realice. Tenemos varias posibilidades: [28] • Append. Se usa para la creación de entidades y atributos y para la actualización de atributos en entidades existentes. • AppendStrict. Se usa para la creación de entidades y atributos en entidades existentes, pero no modifica atributos ya existentes. • Update. Modifica atributos existentes, pero no crea nuevas entidades ni atributos. • Replace. Esta acción reemplaza atributos en entidades existentes. • Delete. Es usada para eliminar atributos en entidades existentes o para eliminar entidades. La opción escogida en todas las entidades utilizadas del proyecto es “append”, pues se quiere crear las entidades en un primer momento y, posteriormente, estar actualizando sus atributos. La respuesta dada por el Context Broker al realizar la actualización de la información correctamente vendrá dada por una entidad llamada “contextResponses”, que indica el tipo de entidad, el valor del campo “isPattern” y su identificador, así como los atributos de la entidad, sin indicar el valor de cada uno. Además de la información de contexto, devuelve el estado del mensaje. En el caso de haberse realizado la actualización correctamente, contendrá el código “200”. En la Figura 19 se puede ver un ejemplo de respuesta del Context Broker. En cuanto a las peticiones de información almacenada en Orion, en este proyecto se ha utilizado NGSIv2, que permite hacer las peticiones GET de las entidades de una forma sencilla, accediendo a “/v2/entities/” y añadiendo el id de la entidad que se quiere obtener. Haciendo uso de esta versión de la API, no se requiere cuerpo del mensaje en la petición, facilitando así el proceso. 3.2.1 Definición y reutilización de entidades de FIWARE La entidad principal que se ha creado es la que contiene datos de la actividad física, a partir de la información recogida y enviada a la aplicación móvil por la camiseta inteligente. El tipo de esta entidad es “PhysicalActivity” y su id “PhysicalActivity” más el nombre del paciente y la fecha en la que se han tomado los datos, esto es así para poder tener información actualizada de la actividad física de cada paciente en la fecha que se ha realizado, sin que se sobreescriban los datos. El campo “isPattern” se ha dejado en “false”, pues no requiere utilizarse como expresión regular. 32 Figura 19. Respuesta de Orion al updateRequest de la entidad “Person”. En cuanto a los atributos, se han mapeado los mismos existentes en los mensajes recibidos, adaptándolos a la estructura de las entidades de NGSIv1, y se ha añadido el nombre del usuario que utiliza la camiseta. Así, tenemos los siguientes: • “accumulates_metabolic_expenditure”. Se trata del gasto calórico total del paciente. Es una variable de tipo “float”. • “instant_metabolic_expenditure”. Es el gasto calórico instantáneo en el momento en el que se envía el mensaje. También se trata de un “float”. • “repetitions”. Es el número de repeticiones realizadas del ejercicio. Se trata de una variable de tipo “integer”. • “user”. Es el usuario que utiliza la camiseta. En la figura 20 se puede observar un ejemplo de la entidad de tipo “PhysicalActivity” enviada al OCB. 33 Figura 20. Ejemplo de entidad de tipo “PhysicalActivity”. Se ha creado también una entidad secundaria para identificar al paciente y tener almacenado información útil para el seguimiento del mismo. Ésta es de tipo “Person” y tiene como id el nombre del usuario de la camiseta. Como puede observarse en la figura 21, los atributos contienen los datos que se quieren almacenar de él: la edad, la altura (en centímetros) y el peso (en kilos). Figura 21. Ejemplo de entidad de tipo “Person”. 34 Uno de los aspectos que se ha podido aprovechar en cuanto al almacenamiento de datos en el Context Broker es la reutilización de entidades ya creadas. En este caso, se ha decidido utilizar las entidades de “Device”, para identificar la camiseta inteligente, y “Alert”, para mostrar alertas. La entidad “Device” identifica a la camiseta inteligente mediante los atributos “description”, que realiza una breve descripción del dispositivo, “macAddress”, que contiene la dirección MAC de la camiseta, y “name”, el nombre del dispositivo, como se puede observar en la figura 22. Figura 22. Ejemplo de entidad de tipo “Device”. La otra entidad reutilizada es “Alert”, la cual avisa al usuario de que ha gastado más de 500 kcal con el objetivo de que realice un descanso. Como atributos, se han escogido los siguientes: “category”, que indica que la información es relacionada con la salud, “description”, que contiene el mensaje de alerta para el paciente, y “severity”, que indica que la intención del mensaje es informacional. En la figura 23 se puede ver un ejemplo de esta entidad. 3.3 Desarrollo del Agente IoT en la aplicación móvil El elemento principal del trabajo es el Agente IoT que recoge información de la API de la camiseta inteligente y lo mapea a las entidades FIWARE definidas en el apartado 3.2.2. Este agente se ha llevado a cabo dentro de una aplicación móvil de Android, desarrollada en Android Studio. La estructura de la parte de la solución que se detalla en este apartado se encuentra esquematizada en la figura 24. 35 Figura 23. Ejemplo de entidad de tipo “Alert” Esta aplicación se ha dividido en dos vistas para el usuario. En primer lugar, debe aparecer una pantalla de registro, en la cual el paciente pueda registrar sus datos y mandarlos en la entidad “Person” al Context Broker. Una vez toque el botón de Comenzar, la aplicación debe mostrar la otra pantalla, en la cual se muestran los mensajes enviados en un ScrollView. Para ello, se ha dividido la aplicación en dos actividades, Registro y MainActivity, correspondiéndose con cada vista, respectivamente. Para la interfaz gráfica, cada actividad tiene su layout correspondiente, en el cuál se define el apartado visual de la aplicación. Figura 24. Solución parcial correspondiente al Agente IoT. 42 Debajo de estos datos, justo después de la información de registro, se encuentra la tabla de Progresión Reciente, que muestra un historial del progreso realizado en la actividad física del paciente que se ha introducido en el formulario. La información de esta tabla se actualiza cada vez que se ha usado el servicio web y podemos observar un ejemplo de ella en la figura 36. Figura 36. Tabla de progresión reciente del servicio web y datos de registro del paciente. Este componente utiliza las funciones de los servicios DataService, para la conexión con FIWARE, y BbddService, para la comunicación con Firebase. En primer lugar, al iniciarse la página todos los datos se encuentran inicializados a 0. Esto se hace así para evitar el error de ‘undefined is not an object’, que ocurre cuando un elemento no se ha inicializado correctamente. Una vez introducido el nombre del paciente en el formulario, éste es pasado como argumento a la función mostrarInfo, la cual se suscribe a dos funciones de DataService: searchUserInfo, para obtener los datos de registro del paciente, y searchKcal, para mostrar la información de actividad física del mismo. La información devuelta por searchKcal es usada como contenido de una variable de tipo Post, la cual sirve como argumento de las funciones que se conectan con Firebase. Este tipo de variable ha sido creado en el archivo Post.js con el objetivo de mandar la información deseada a la base de datos del servicio. Se compone de una id, los datos de actividad física y el nombre del paciente. Además, tiene una clave que sirve para su almacenamiento en la base de datos y que obtiene un valor automáticamente al enviar la información a Firebase. Este tipo de dato creado se muestra en la figura 37. Figura 37. Tipo de dato Post. Seguidamente, con la variable de tipo Post completa, se llama a la función postKcalInfo de BbddService para su almacenamiento en la Realtime Database de Firebase. Aquí se barajó la posibilidad de realizar una comparación entre los campos “id” de los elementos y comprobar si ya existía información de actividad física del paciente en esa misma fecha, actualizándola en ese caso o creando un elemento nuevo en el contrario. Esto no se ha hecho así pues para ello habría que suscribirse al método snapshotChanges al llamar a la función getKcalInfo de DataService. Este método se encarga de devolver un objeto con los datos de la tabla cada vez que se actualiza su información. Entonces, al hacer la comprobación dentro de esta suscripción y, una vez comprobado, una creación de un elemento nuevo para la base de datos, el método se volvía a ejecutar, pues se había actualizado la información de la base de datos. Por ello, volvían a almacenarse elementos ya guardados, incluso sobreescribiendo otros anteriores. Otra limitación es que no se podían añadir varios registros de actividad física del mismo día y el mismo paciente, pues se sobreescribiría el anterior, al tomar ésta como una actualización. Es por estas dos limitaciones que se ha decidido almacenar la información recibida del Context 43 Broker siempre como un nuevo elemento. Se ha dejado como trabajo futuro una actualización que permita sobreescribir esa información en Firebase. Por último, se llama a la función mostrarProgreso (Figura 38), encargada de mostrar la tabla de progreso de actividad física del paciente, registrado en Firebase. Para ello, se suscribe al método snapshotChanges, explicado en el párrafo anterior, de la función getKcalInfo de BbddService, que devuelve los elementos almacenados en la base de datos. Estos elementos son recorridos mediante un bucle forEach, completando la tabla de progreso reciente con los datos del paciente. Para que solo se muestren los datos de ese paciente, esta función recibe como argumento el nombre del mismo y, antes de actualizar la tabla de progreso, se compara este nombre con el del elemento de Firebase recorrido en ese momento. Si coinciden, se trata del paciente del que se desea obtener la información, actualizándose así el registro. Figura 38. Función mostrarProgreso. 3.4.1.1 Servicio DataService El servicio DataService es el encargado de la comunicación con el Orion Context Broker, importando para ello HttpClient. Se compone de tres funciones: • searchKcal: Realiza la petición GET al Context Broker con la versión de la API NGSIv2 para obtener los últimos datos de actividad física del paciente registrados en ese día. Recibe como argumento el nombre del paciente introducido en el formulario para así sólo obtener sus datos. • searchUserInfo: Similiar a la anterior. Obtiene los datos de registro del paciente almacenados en FIWARE. También recibe como argumento el nombre del mismo. • getDate: Es una función auxiliar que devuelve la fecha. Es útil para la id buscada en la petición GET de searchKcal. En el intercambio de mensajes con Orion, CORS (Cross-Origin Resource Sharing) bloqueaba las peticiones GET a este destino. Esto se intentó solucionar habilitando CORS al iniciar el Context Broker, pero no terminaba de funcionar. Se cree que este apartado de FIWARE está aún en desarrollo y que en próximas versiones estará disponible. Mientras tanto, se ha habilitado un proxy, que permite el intercambio de mensajes entre el servicio web y el Context Broker, encontrándose su configuración en el archivo proxy.conf.json. 3.4.1.2 Servicio BbddService Este servicio se encarga del intercambio de información entre la aplicación web y la Realtime Database de Firebase, incorporando para ello los elementos necesarios del módulo de AngularFire2. Está compuesto por dos 44 funciones: • getKcalInfo: Devuelve la lista de la información de actividad física almacenada en la base de datos de Firebase. • postKcalInfo: Se encarga de crear una nueva instancia en la base de datos con la información obtenida del Context Broker, la cual se pasa en un objeto de tipo Post como argumento de la función. Hace uso del método push de AngularFirelist para el envío. Este método es un ejemplo de la fácil integración de Firebase en Angular, pues el envío se realiza de una forma sencilla y rápida. Se puede observar el código de la función en la figura 39. Figura 39. Función postKcalInfo. 3.4.2 Componente About Este componente secundario se corresponde con una nueva vista a la principal, accesible en la pestaña About desde el menú de navegación. Se encarga de imprimir un resumen de la funcionalidad del servicio web con objeto de informar al usuario, luego solamente está desarrollado en código HTML. Bajo la descripción realizada se encuentra la imagen de “Powered by FIWARE”, como se puede ver en la figura 40. Figura 40. Servicio web en su vista secundaria, correspondiente al componente About. 45 3.5 Pruebas y validación Para la comprobación de las funcionalidades de la solución desarrollada y su posterior validación se han llevado a cabo varias pruebas, entre ellas las que se detallan a continuación. Para la conexión del Agente IoT con FIWARE, se comprobó el correcto intercambio de mensajes imprimiendo la respuesta del Context Broker por consola, ante un mensaje con contenido de actividad física enviado por la aplicación móvil. Se utilizó Postman como complemento a esto, haciendo peticiones GET a las entidades almacenadas en Orion. En un principio, no había respuesta, luego no se estaba enviando correctamente. Tras comparar el mensaje enviado con los ejemplos disponibles en la documentación de FIWARE [5], se llegó a la conclusión de que el formato de este mensaje no coincidía exactamente con el de los ejemplos y que necesitaba unos muy leves cambios para que fuera aceptado por el Context Broker. Seguidamente, se solucionó el problema cambiando esos detalles que no permitían el correcto envío, produciéndose así la respuesta ContextResponses y el almacenamiento de la información en el Context Broker. Otro aspecto que se ha observado es la actuación de la aplicación de Android a largo tiempo. Se vio que la aplicación fallaba cuando llegaba a un número de mensajes muy alto en el ScrollView. Es por ello que se ha introducido una variable contadora “evitaBloqueoMensajes” a la función onActivityExerciseMode. Esta variable cuenta el número total de mensajes que aparecen en el ScrollView y, cuando llega a más de 500 mensajes, lo vacía borrando los mensajes que aparecen en ese momento y volviendo a mostrar los nuevos mensajes desde arriba. Así, la aplicación no se sobrecarga de mensajes y puede seguir ejecutándose indefinidamente. En cuanto al servicio web, se comprobó el correcto almacenamiento de la información en la Realtime Database ejecutando el servicio y observando en la consola de Firebase los datos almacenados. Al principio, no se conseguía el almacenamiento de la información. Se estuvo observando la ejecución del código y se comprobó que el método Push nunca se ejecutaba, sino que la ejecución se paraba justo antes. Se observó también en la consola del navegador, que daba error en algunos objetos de tipo any, diciendo que eran “undefined”, aunque ya tenían contenido pues se podía imprimir sus datos por pantalla correctamente. Este error no se solucionó tras varios intentos, luego se exploró la opción de cambiar la base de datos a MySQL, aunque la integración de Angular con Firebase es mejor y permite una interacción más sencilla. Tras bastante tiempo investigando, se inicializaron las variables que, según la consola, eran undefined, con los formatos que recibirían de las funciones una vez llamadas estas, evitando así que la consola las diera por “undefined” y las reconociera como el tipo que realmente eran. Una vez realizados estos cambios, la Realtime Database almacenaba correctamente toda la información y se imprimía por pantalla el progreso realizado en actividad física por el paciente. 3.6 Ejecución de la solución completa Para establecer la solución completa desarrollada en el sistema, en primer lugar hay que tener desplegado el OCB en CentOs, en nuestro caso una máquina virtual. Una vez está funcionando, se iniciará la aplicación en su primera vista, en la cual el paciente debe ingresar sus datos de registro para comenzar a enviar mensajes. Esta vista se puede ver en la figura 41. Al tocar el botón de “Comenzar”, si se han introducido los datos correctamente, se pasará a la segunda vista de la aplicación (Figura 42), la cual muestra los mensajes enviados a FIWARE en un ScrollView. En caso contrario, se mostrará un mensaje Toast avisando al usuario de que debe introducir sus datos correctamente. 46 Figura 41. Ejecución del Agente IoT: Vista de la actividad Registro. Figura 42. Ejecución del Agente IoT: Vista de la actividad MainActivity. 47 Ahora ya se tendría información almacenada en el Context Broker, que puede ser accedida por el servicio web. Así, se puede acceder a “localhost:4200” para usar el servicio en el navegador. La primera vista mostrada al usuario se observa en la figura 43. Figura 43. Ejecución del Servicio Web: Vista principal al acceder al servicio. Se pide que se introduzca en el formulario el nombre del paciente para comenzar a recibir los datos del OCB. Una vez introducido y presionado el botón de “Mostrar datos”, se realizan las peticiones anteriormente explicadas y se muestran los datos de actividad física del paciente, así como sus datos de registro y la tabla de progreso reciente, como se observa en la figura 44. Figura 44. Ejecución del Servicio Web: Vista principal una vez introducido el nombre del paciente. Así, los nuevos datos obtenidos de actividad física se habrán actualizado en la Realtime Database de Firebase, 48 como podemos ver en la figura 45. Figura 45. Ejecución del Servicio Web: Base de datos de Firebase actualizada. Además, en la barra de navegación, puede seleccionarse la pestaña de “About” para obtener la vista informativa descrita en el apartado 3.4.2. Ésta se puede observar en la figura 46. Figura 46. Ejecución del Servicio Web: Vista secundaria informativa. 49 4 CONCLUSIONES Y LÍNEAS FUTURAS n la realización de este proyecto se ha conseguido integrar la camiseta inteligente desarrollada por el Grupo de Ingeniería Biomédica de la ETSI en la plataforma de IoT abierta FIWARE mediante el agente desarrollado, permitiendo almacenar los datos de forma automática para que así otros sistemas puedan disponer de ella. Como añadido, se ha desplegado un servicio web que acompaña al agente para proporcionar una solución completa a los objetivos del trabajo. Así, se ofrece una propuesta atractiva para mejorar el seguimiento de los pacientes en sus tratamientos, monitorizando la actividad física realizada y permitiendo el fácil acceso a profesionales sanitarios que necesiten conocer esta información, en cualquier momento y lugar. Además, se ha investigado a fondo el Internet of Things y la plataforma FIWARE, junto con las numerosas posibilidades que ofrece para el desarrollo de soluciones de IoT, así como otras nuevas tecnologías tales como Angular para el desarrollo de servicios web o la base de datos Firebase, que permite una sencilla interacción con los elementos almacenados y una buena integración con las aplicaciones web desarrolladas, en este caso, en Angular. Una vez se ha finalizado el proyecto, se ha observado que FIWARE es una plataforma idónea para el desarrollo de soluciones de IoT, permitiendo un fácil despliegue de sus componentes y proporcionando una API sencilla de usar. Angular es una tecnología que no conocía y que volvería a utilizar en el desarrollo de servicios web, ya que no me ha resultado de demasiada complicación y, junto con Bootstrap, ofrece un apartado visual muy bueno al usuario. Sin embargo, intentaría usar otra base de datos en lugar de Firebase pues, aunque tiene una buena integración con Angular, también he observado algunas carencias que no tienen las bases de datos con las que he trabajado durante el grado. No obstante, existen algunas ideas relacionadas con el proyecto que no se han podido realizar y que seguirían mejorando la solución desarrollada. Estos detalles finalmente no se realizaron debido a la falta de tiempo disponible, teniendo que acotar el trabajo por la extensión del mismo. Entre ellas, destacamos las siguientes: • Vista para la muestra de información de actividad física en la aplicación móvil. La aplicación móvil muestra los mensajes enviados al Context Broker. Esta idea se trata de implementar una nueva vista que muestre la información de actividad física al usuario que utiliza la camiseta inteligente también en su móvil. En este proyecto se ha optado por hacerlo en un servicio web para completar la solución planteada, permitiendo al personal médico acceder a los datos. Además, de esta forma se ha conseguido investigar más tecnologías, aparte del diseño de aplicaciones móviles. • Actualización de los elementos en Firebase que tengan la misma id y sus datos sean diferentes, en lugar de la creación de uno nuevo. Como ya se ha comentado, se obtuvo un comportamiento inusual y descontrolado de la base de datos al intentar proporcionar una funcionalidad de actualización de datos de actividad física que se hubieran realizado el mismo día con información diferente, en lugar de la creación de nuevos elementos. Esto ocurría debido a la creación o actualización de entidades dentro de E El 90% del éxito se basa simplemente en insistir. - Woody Allen - 50 la suscripción al método snapshotChanges, el cual devuelve una vista de los elementos almacenados en la base de datos de Firebase cada vez que cambian. Entonces, una vez creado o actualizado un elemento, terminaba volviendo a entrar en la función, realizando lo mismo un número aleatorio de veces. Finalmente, se optó por crear entidades con los datos obtenidos del Context Broker, sin consultar si ya había datos de actividad física del mismo día realizada por el mismo paciente. Esto también tiene la ventaja de que se puede registrar información de ejercicio físico realizado en dos momentos distintos del día, sin sobreescribirse. No obstante, se cree interesante que, como actualización, se pueda realizar la función explicada sin perder esta ventaja. • Impresión de una gráfica de progreso reciente en la aplicación web. Se trata de imprimir los datos de progreso del paciente, almacenados en la Realtime Database de Firebase, en una gráfica, en lugar de una tabla, dando así un aspecto más visual al usuario y permitiendo que sea más sencillo observar el progreso del paciente. Para llevar a cabo esta idea, primero es necesario realizar la anterior propuesta, pues sólo tiene sentido mostrar una gráfica cuando se tiene un único dato por día de cada paciente. 51 58 REFERENCIAS [1] Estrategia mundial sobre régimen alimentario, actividad física y salud. Organización Mundial de la Salud. [Consultado el 4 de julio de 2019]. Disponible en: https://www.who.int/dietphysicalactivity/pa/es/ [2] Izquierdo IM, Ibáñez J, Antón M, Cebollero P, Cadore E, Casas Herrero A, López Chicharro J, VicenteCampos D, Vicente-Rodríguez G, Gómez-Cabello A, Casajus J, Pérez Ruiz M, Herrero F, San Juan Ferrer A, Zamorano Cauto R. Ejercicio Físico es Salud. Prevención y tratamiento de enfermedades mediante la prescripcion de ejercicio físico. 2014. Disponible en: https://www.researchgate.net/publication/267752299_Ejercicio_Fisico_es_Salud_Prevencion_y_tratami ento_de_enfermedades_mediante_la_prescripcion_de_ejercicio_fisico [3] Página web oficial de FIWARE. [Consultado el 12 de agosto de 2019] Disponible en: https://www.fiware.org [4] Rayes A, Salam S. Internet of Things From Hype to Reality The Road to Digitization. Cham: Springer; 2017. Disponible en: https://fama.us.es/discovery/fulldisplay?docid=alma991013067530004987&context=L&vid=34CBUA_ US:VU1&search_scope=all_data_not_idus&tab=all_data_not_idus&lang=es [5] Evans D. Internet of Things. La próxima gran evolución de Internet lo está cambiando todo. Cisco IBSG. Abril 2011. [Consultado el 24 de julio de 2019] Disponible en: https://www.cisco.com/c/dam/global/es_es/assets/executives/pdf/Internet_of_Things_IoT_IBSG_0411FI NAL.pdf [6] What is FIWARE?. FIWARE Foundation. 2019. [Consultado el 25 de julio de 2019] Disponible en: https://www.fiware.org/developers/ [7] Presentación “Usando FIWARE y datos de contexto”. Fiware Zone. 2019. / [8] Celesti A, Fazio M, Galán Márquez F, Glikson A, Mauwa H, Bagula A, Celesti F, Villari M. How to Develop IoT Cloud e-Health Systems Based on FIWARE: A Lesson Learnt. 2011. [9] Orion Context Broker (OCB). Laboratorio Nacional de Internet del Futuro. FIWARE. 2018. [Consultado el 14 de agosto de 2019] Disponible en: https://fiwaretraining.readthedocs.io/es_MX/latest/ecosistemaFIWARE/ocb [10] Página web de MongoDB. [Consultado el 14 de agosto de 2019] Disponible en https://www.mongodb.com/es [11] La eSalud, referencia en eHealth en español. COM SALUD. 2016. [Consultado el 15 de agosto de 2019] Disponible en: https://laesalud.com/que-es-esalud/ [12] Android Studio. Wikipedia, la enciclopedia libre. [Consultado el 15 de agosto de 2019] Disponible en: https://es.wikipedia.org/wiki/Android_Studio [13] Naranjo-Hernández D, Talaminos-Barroso A, Reina-Tosina J, Roa LM, Barbarov-Rostan G, Cejudo- 59 Ramos P, Márquez-Martín E, Ortega-Ruiz F. Smart Vest for Respiratory Rate Monitoring of COPD Patients Based on Non-Contact Capacitive Sensing. 2018. [14] Manual de usuario de la camiseta inteligente. Grupo de Ingeniería Biomédica de la ETSI. 2018. [15] Documentación de Postman. [Consultado el 16 de agosto de 2019] Disponible en: https://docs.postmanecho.com/?version=latest [16] Visual Studio Code. Wikipedia, la enciclopedia libre. [Consultado el 16 de agosto de 2019] Disponible en: https://es.wikipedia.org/wiki/Visual_Studio_Code [17] Angular. Wikipedia, la enciclopedia libre. [Consultado el 17 de agosto de 2019] Disponible en: https://es.wikipedia.org/wiki/Angular_(framework) [18] TypeScript. Wikipedia, la enciclopedia libre. [Consultado el 17 de agosto de 2019] Disponible en: https://es.wikipedia.org/wiki/TypeScript [19] HTML. Wikipedia, la enciclopedia libre. [Consultado el 17 de agosto de 2019] Disponible en: https://es.wikipedia.org/wiki/HTML [20] Lista de etiquetas HTML 5.2. Páginas web HTML y hojas de estilo CSS. [Consultado el 17 de agosto de 2019] Disponible en: http://www.mclibre.org/consultar/htmlcss/html/html-etiquetas.html [21] Bootstrap. Wikipedia, la enciclopedia libre. [Consultado el 18 de agosto de 2019] Disponible en: https://es.wikipedia.org/wiki/Bootstrap_(framework) [22] Página web de Bootswatch. [Consultado el 18 de agosto de 2019] Disponible en: https://bootswatch.com [23] Tamplin J. Firebase expands to become unified app platform. Google. 2016. [Consultado el 19 de agosto de 2019] Disponible en: https://firebase.googleblog.com/2016/05/firebase-expands-to-become-unifiedapp-platform.html [24] Documentación. Firebase. Google. [Consultado el 19 de agosto de 2019] Disponible en: https://firebase.google.com/docs Último acceso: 19 Agosto 2019. [25] Cetiner Y. Presentación "Firebase Services". 2016. [Consultado el 19 de agosto de 2019] Disponible en: https://www.slideshare.net/Yasinetiner/firebase-services [26] Firebase Authentication. Firebase. Google. [Consultado el 19 de agosto de 2019] Disponible en: https://firebase.google.com/docs/auth [27] Firebase Realtime Database. Firebase. Google. [Consultado el 19 de agosto de 2019] Disponible en: https://firebase.google.com/docs/database [28] Update action types. FIWARE. [Consultado el 22 de agosto de 2019] Disponible en: https://fiwareorion.readthedocs.io/en/master/user/update_action_types/index.html [29] Instalación Context Broker. FIWARE. [Consultado el 30 de agosto de 2019] Disponible en: https://fiware-orion.readthedocs.io/en/latest/admin/install/index.html