Procesador de eventos en entorno IoT de FIWARE para la supervisión remota de la actividad física

Equation Chapter 1 Section 1 Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Procesador de eventos en entorno IoT de FIWARE para la supervisión remota de la actividad física Autor: Pablo Romero Escot Tutor: Jorge Calvillo Arbizu Dpto. Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2020 iii Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Procesador de eventos en entorno IoT de FIWARE para la supervisión remota de la actividad física Autor: Pablo Romero Escot 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, 2020 v Trabajo Fin de Grado: Procesador de eventos en entorno IoT de FIWARE para la supervisión remota de la actividad física Autor: Pablo Romero Escot 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, 2020 El Secretario del Tribunal vii A mi familia A mis amigos A mis maestros ix Agradecimientos Antes de comenzar con mi Trabajo de Fin de Grado, quiero agradecer a todas las personas que han estado junto a mí estos cuatro años, las cuales han sido un gran apoyo siempre y han contribuido a que esta etapa de mi vida sea inolvidable. En primer lugar, quiero dar las gracias a mi familia, a mi padre, a mi madre, a mis hermanos. Las personas que más han influido en que sea como soy hoy en día. No tengo palabras para expresar como me siento al pensar en cómo me habéis apoyado, animado y ayudado siempre. Estos años, más alejado de casa, me han hecho madurar y darme cuenta de todo el esfuerzo que hacéis para que mi única preocupación sea formarme. Gracias por siempre creer y confiar en mí. En segundo lugar, quiero agradecer a todos los amigos que me ha dado esta carrera, a Jesús, Fernando, Ana, Daniel, Sergio, José… y muchos otros que dejo sin nombrar, pero están en mi cabeza al recordar estos años. Personas fantásticas, con las que he compartido estos increíbles años, apoyándonos, ayudándonos y animándonos siempre. Personas con las que primero compartía clases, con las que charlaba entre una clase y otra, luego compartíamos un rato tomando café o comiendo juntos, con las que haces planes una vez acaban las clases, con las que he compartido tantísimas risas y buenos momentos… Personas que echaré de menos en mi día a día… Recordar todas las cosas que hemos pasado juntos me provoca un poco de añoranza, pero sé que siempre encontraremos un hueco para reunirnos todos y pasárnoslo genial, como siempre hemos hecho. Por otro lado, quiero agradecer a Irene el inmeso apoyo que me ha dado siempre, animándome y motivándome cuando más lo necesitaba, empujándome a dar siempre lo mejor de mí, aunque yo mismo pensara que no podía más. Capaz de sacarme una sonrisa hasta en los peores momentos. Te has convertido en un modelo a seguir para mí y me has convertido en una mejor persona. Por último, me gustaría agradecer a todos los profesores que me han aportado algo durante este proceso, de cada uno de ellos he aprendido algo, y han contribuido a formarme un poco más, tanto personal como profesionalmente. En especial, a mi tutor Jorge Calvillo, por ayudarme a cerrar esta etapa de la mejor manera posible, cuyos consejos y ayuda han sido fundamentales para la realización de este trabajo. Gracias por estos años tan especiales, a todos, gracias. Pablo Romero Escot Sevilla, 2020 3.3.3 Entidades FIWARE 40 3.3.4 Procesador de eventos 45 3.4 Visualización 48 3.4.1 Despliegue y configuración de Freeboard 48 3.4.2 Configuración de las fuentes de datos 49 3.4.3 Configuración de los widgets 52 3.4.4 Dashboard 55 3.5 Escenarios 57 4 Conclusiones y líneas futuras 79 4.1 Conclusiones 79 4.2 Líneas futuras 80 Anexo A: Instalación y despliegue de los componentes fiware 83 A.1 Instalación de Docker 83 A.2 Instalación de MongoDB 85 A.3 Instalación de Orion Context Broker 86 A.4 Instalación de Perseo 87 Anexo B: Instalación y despliegue de Freeboard 91 B.1 Instalación de Freeboard 91 Anexo C: Instalación y despliegue del servidor FHIR 95 C.1 Instalación de Apache Tomcat 95 C.2 Instalación del servidor FHIR 97 Referencias 99 Glosario 101 xvii ÍNDICE DE TABLAS Tabla 1-1. Análisis y búsqueda de información 5 Tabla 1-2. Análisis y diseño del procesador de eventos 5 Tabla 1-3. Implementación del procesador de eventos 6 Tabla 1-4. Implementación de la interfaz visual 6 Tabla 1-5. Implementación del sistema de historia clínica 7 Tabla 1-6. Pruebas y validación 7 Tabla 1-7. Documentación 7 Tabla 1-8. Resumen planificación 8 Tabla 2-1. Definición Patient.identifier 23 Tabla 2-2. Definición Patient.active 23 Tabla 2-3. Definición Patient.name 23 Tabla 2-4. Definición Patient.telecom 24 Tabla 2-5. Definición Patient.gender 24 Tabla 2-6. Definición Patient.birthDate 24 Tabla 2-7. Definición Patient.deceased[x] 24 Tabla 2-8. Definición Patient.address 25 Tabla 2-9. Definición Patient.managingOrganization 25 Tabla 2-10. Definición Observation.identifier 26 Tabla 2-11. Definición Observation.basedOn 26 Tabla 2-12. Definición Observation.parOf 26 Tabla 2-13. Definición Observation.status 26 Tabla 2-14. Definición Observation.category 27 Tabla 2-15. Definición Observation.code 27 Tabla 2-16. Definición Observation.subject 27 Tabla 2-17. Definición Observation.effective[x] 27 Tabla 2-18. Definición Observation.value[x] 28 Tabla 2-19. Definición Observation.note 28 Tabla 2-20. Definición Observation.device 28 xix ÍNDICE DE FIGURAS Figura 1-1. Arquitectura del sistema 4 Figura 2-1. Evolución del número de dispositivos IoT conectados en todo el mundo. Fuente: [9] 10 Figura 2-2. Logo de FIWARE 10 Figura 2-3. Esquema básico del procedimiento de una Smart Solution 11 Figura 2-4. Estructura de una entidad de contexto. Fuente: [12] 12 Figura 2-5. Representación JSON de una entidad NGSI 12 Figura 2-6. Representación JSON de una entidad NGSI en modo “keyValues” 13 Figura 2-7. Estructura-comunicación del Orion Context Broker. Fuente: [13] 13 Figura 2-8. Estructura de una notificación por defecto 15 Figura 2-9. Estructura de funcionamiento de Perseo. Fuente: [14] 16 Figura 2-10. Estructura de una regla en Perseo. Fuente: [14] 17 Figura 2-11. Logo de MongoDB 20 Figura 2-12. Logo de FHIR 21 Figura 2-13. Estructura de un recurso FHIR 22 Figura 2-14. Logo de HAPI FHIR 29 Figura 2-15. Logo de Freeboard 29 Figura 2-16. Logo de VMware Workstation 30 Figura 2-17. Logo de Ubuntu 18.04 LTS 30 Figura 2-18. Logo de Docker 31 Figura 2-19. Comparativa estructura contenedores Docker frente a máquina virtual. Fuente: [32] 31 Figura 2-20. Logo de Postman 32 Figura 2-21. Interfaz gráfica de Postman 33 Figura 3-1. Esquema de la plataforma 36 Figura 3-2. Página principal del servidor FHIR 37 Figura 3-3. Solicitud de creación de un recurso Patient 38 Figura 3-4. Recurso Patient obtenido del servidor FHIR 39 Figura 3-5. Cabecera HTTP de las peticiones a componentes FIWARE 41 Figura 3-6. Modelo de entidad tipo “PhysicalActivity” 41 Figura 3-7. Ejemplo de entidad de tipo “Alert” 43 Figura 3-8. Ejemplo de entidad de tipo “PhysicalActivity” 44 Figura 3-9. Actualización de una entidad de tipo “PhysicalActivity” 45 Figura 3-10. Suscripción de Perseo-FE a OCB 47 Figura 3-11. Modificación para recibir notificaciones correspondientes a entidades concretas 47 Figura 3-12. Configuración fuente de datos correspondiente a la entidad “PhysicalActivity” 50 Figura 3-13. Configuración fuente de datos correspondiente a un tipo de alertas 51 Figura 3-14. Panel de control de Freeboard 52 Figura 3-15. Widget tipo “Text” correspondiente al nombre completo del paciente 52 Figura 3-16. Widget tipo “Gauge” correspondiente a la frecuencia cardíaca 53 Figura 3-17. Widget tipo “Time series” correspondiente a la frecuencia cardíaca 54 Figura 3-18. Widget tipo “HTML” correspondiente a la descripción de una clase de alarma 54 Figura 3-19. Representación mediante combinación de HTML y una fuente de datos 55 Figura 3-20. Dashboard 56 Figura 3-21. Regla para detectar una situación de riesgo leve a través de la frecuencia cardíaca 57 Figura 3-22. Actualización correspondiente a una situación de riesgo leve 58 Figura 3-23. Email enviado a un paciente que se encuentra en una situación de riesgo leve 58 Figura 3-24. Entidad actualizada debido a la activación de la regla “FrecCardiacaRiesgoLeve” 58 Figura 3-25. Regla 1 para detectar una situación de riesgo grave a través de la frecuencia cardíaca 60 Figura 3-26. Actualizaciones correspondientes a una situación de riesgo grave 61 Figura 3-27. Email enviado al paciente – Regla “FrecCardiacaRiesgoGraveConsecutivo” 61 Figura 3-28. Email enviado al médico responsable – Regla “FrecCardiacaRiesgoGraveConsecutivo” 61 Figura 3-29. Recurso creado por la activación de la regla “FrecCardiacaRiesgoGraveConsecutivo” 62 Figura 3-30. Consulta realizada en el servidor FHIR 63 Figura 3-31. Resultado de la consulta en el servidor FHIR 63 Figura 3-32. Entidad actualizada por la activación de la regla “FrecCardiacaRiesgoGraveConsecutivo” 63 Figura 3-33. Regla 2 para detectar una situación de riesgo grave a través de la frecuencia cardíaca 64 Figura 3-34. Serie de actualizaciones correspondientes a una situación de riesgo grave 66 Figura 3-35. Email enviado al paciente – Regla “FrecCardiacaRiesgoGraveVentana” 67 Figura 3-36. Email enviado al médico responsable – Regla “FrecCardiacaRiesgoGraveVentana” 67 Figura 3-37. Recurso creado por la activación de la regla “FrecCardiacaRiesgoGraveVentana” 67 Figura 3-38. Entidad actualizada por la activación de la regla “FrecCardiacaRiesgoGraveVentana” 68 Figura 3-39. Regla para detectar una tendencia a un posible riesgo 68 Figura 3-40. Serie de actualizaciones que indican una tendencia a un posible riesgo 69 Figura 3-41. Email enviado a un paciente para alertar sobre una tendencia a un posible riesgo 70 Figura 3-42. Entidad actualizada debido a la activación de la regla “FrecCardiacaRiesgoTendencia” 70 Figura 3-43. Regla para detectar un posible riesgo mediante el gasto calórico instantáneo 71 Figura 3-44. Actualizaciones que indican una situación de riesgo ligada al gasto calórico instantáneo 72 Figura 3-45. Email enviado al paciente para alertar sobre el incremento de gasto calórico instantáneo 72 Figura 3-46. Recurso creado por la activación de la regla “GastoCaloricoInstantaneo” 73 Figura 3-47. Entidad actualizada debido a la activación de la regla “GastoCaloricoInstantaneo” 73 Figura 3-48. Regla para la monitorización diaria del gasto calórico acumulado 74 xxi Figura 3-49 Actualizaciones que darían lugar a la activación de la regla “GastoCaloricoAcumulado” 75 Figura 3-50. Email enviado al paciente para notificarle que no ha cumplido su objetivo diario de kcal 75 Figura 3-51. Recurso Observation creado por la activación de la regla “GastoCaloricoAcumulado” 75 Figura 3-52. Entidad actualizada debido a la activación de la regla “GastoCaloricoAcumulado” 76 Figura 3-53. Regla para detectar comportamiento anómalo en un dispositivo 76 Figura 3-54. Actualizaciones con valores anómalos 77 Figura 3-55. Email enviado al paciente para informar sobre errores en el dispositivo 77 Figura 3-56. Email enviado al servicio técnico para informar sobre fallos en un dispositivo 78 Figura A-1. Comprobación de la correcta instalación de Docker 84 Figura A-2. Arranque del cliente mongo de MongoDB 85 Figura A-3. Logs generados por MongoDB 86 Figura A-4. Comprobación del correcto arranque de OCB 87 Figura A-5. Configuración necesaria para el email correspondiente a Perseo 89 Figura A-6. Comprobación del correcto arranque de Perseo Core 89 Figura A-7. Comprobación del correcto arranque de Perseo-FE 89 Figura B-1. Pantalla de inicio de Freeboard 92 Figura B-2. Agregación de un plugin a Freeboard 93 Figura B-3. Visualización del nuevo plugin en Freeboard 94 Figura C-1. Página de inicio de Tomcat 97 Figura C-2. Pantalla de inicio del servidor FHIR 98 1 INTRODUCCIÓN n este primer capítulo se podrá conocer la motivación que promovió la realización de este trabajo, así como los objetivos que se pretenden alcanzar con éste. También, se comentará la solución que se ha llevado a cabo, así como la planificación que ha tenido lugar, junto con una comparación entre la estimación temporal realizada para cada actividad y el tiempo real que ha conllevado finalmente. 1.1 Motivación La práctica regular de actividad física juega un papel fundamental para el mantenimiento y mejora de la salud, aportando beneficios fisiológicos, psicológicos y sociales. Además, reduce el riesgo de padecer enfermedades como hipertensión arterial, diabetes mellitus y diversos tipos de cáncer [1]. No solo eso, también se aplica como tratamiento en la lucha contra diversas enfermedades como por ejemplo el deterioro cognitivo. Por el contrario, la inactividad física es el cuarto factor de riesgo de mortalidad en todo el mundo, estando relacionada con el desarrollo de enfermedades como la obesidad, problemas cardiovasculares y sus factores de riesgo [2]. Una de las características de la actividad física como tratamiento, es que su realización se suele llevar a cabo principalmente fuera del entorno médico y depende del propio paciente. Esto puede conllevar una peor adherencia a los tratamientos, así como complicar el seguimiento por parte de los profesionales sanitarios. Ante esta situación, sería conveniente disponer de un sistema de monitorización el cual capte información de la actividad que está realizando el paciente, la procese de forma automática y permita que esté a disposición del personal sanitario para su consulta de una forma sencilla. Esto permitiría monitorizar a los pacientes en tiempo real y seguir la evolución que están teniendo a lo largo del tratamiento. El Grupo de Ingeniería Biomédica de la Universidad de Sevilla ha desarrollado una camiseta inteligente para la monitorización de la actividad física de los pacientes y un Agente IoT, implementado en el teléfono móvil, que hace de intermediario entre el dispositivo sensor y la plataforma IoT FIWARE. FIWARE es una plataforma de código abierto que permite manejar y analizar en tiempo real, cantidades masivas de información de cualquier tipo, automatizando procesos y haciéndolo de manera escalable. Permite que dicha información se encuentre disponible en cualquier momento y que el acceso a ella sea controlado. También dispone de una amplia biblioteca de componentes, llamados Generic Enablers (GE), que proporcionan capacidades muy diversas y además son compatibles entre ellos. La solución desarrollada, si bien recoge la E Si un problema tiene solución, no hay por qué preocuparse. Si no tiene solución, preocuparse no sirve de nada. - Proverbio chino - Introducción 2 información de actividad del paciente y la envía a la plataforma, no facilita aún que dicha información esté disponible para el personal sanitario o sea procesada de manera automática. Por ello, partiendo de la situación actual donde nos encontramos, en la que la información del paciente es recogida y enviada a FIWARE, con este proyecto se busca desarrollar, ante la gran cantidad de información a manejar por parte de los profesionales sanitarios, un sistema de monitorización que alerte de forma automática en caso de que tengan lugar una serie de eventos. Este sistema, además, permitirá registrar observaciones periódicas, de la actividad que está realizando el paciente en su domicilio, en un servicio de historia clínica, de forma que puedan ser de interés para revisiones futuras por parte de profesionales. Esto evitaría la acumulación de grandes cantidades de información, que se pueden producir durante la monitorización, permitiendo tener un almacenamiento persistente sólo con la información realmente importante. Por otra parte, otra motivación del proyecto es facilitar el seguimiento del tratamiento en el paciente, por parte del personal sanitario, mediante una interfaz visual, haciendo accesible dicha información, de forma sencilla, en cualquier momento y lugar. Por último, una motivación extra de este trabajo ha sido poder averiguar y aprender más sobre unas tecnologías que están teniendo un impacto muy importante en la actualidad y van a tener un impacto incluso mayor en un futuro cercano. 1.2 Objetivos El primer objetivo de este proyecto es la creación de un sistema que permita procesar una gran cantidad de datos de monitorización de actividad, comparándolos con una serie de reglas, para así conseguir una detección temprana de eventos de interés. Se incluye la opción de que cualquier usuario autorizado puede acceder a la información, y acceder/modificar los patrones de detección de una forma segura y simple. Este objetivo puede ser desglosado en: ▪ Análisis de la plataforma FIWARE y sus diferentes componentes: Ya que va a ser la plataforma sobre la que se van a manejar los datos, es importante conocer bien cómo funciona, como interactúan sus componentes y qué servicios pone a nuestra disposición. ▪ Análisis de la solución de partida, tanto de la camiseta inteligente como del agente IoT. ▪ Modelado de datos: Mapeo de los datos a manejar en entidades, cuyos campos deben ser conocidos por los diferentes componentes del sistema para poder acceder a su contenido. ▪ Diseño de comportamientos de interés: Definición de patrones que van a constituir un evento de interés, el cual va a conllevar una acción. ▪ Diseño de las acciones a realizar como consecuencia de la sucesión de eventos. ▪ Desarrollo de la solución completa: despliegue de los diversos componentes e interconexión de ellos. ▪ Evaluación de la solución con diferentes escenarios. Como segundo objetivo, se llevará a cabo el desarrollo de una interfaz visual (que denominaremos dashboard) que permita el seguimiento remoto y supervisado de la información de monitorización por parte del personal autorizado. Este podrá observar todos los parámetros de interés del paciente y ver cómo varían a lo largo del tiempo. Este segundo objetivo se puede descomponer en: ▪ Estudio y comparación de las diferentes tecnologías disponibles para el desarrollo del dashboard. ▪ Desarrollo del dashboard y los componentes que lo forman. ▪ Integración con la plataforma FIWARE para poder recolectar los datos. El dashboard permitirá al usuario visualizar los datos que va recibiendo el sistema desde el dispositivo de actividad física, realizar análisis de forma más sencilla y poder tomar decisiones en base a estos. Como tercer objetivo, se realizará un análisis del estándar FHIR (Fast Healthcare Interoperability Resources), con el fin de registrar en un sistema de historia clínica, los eventos de interés que han sido captados por el procesador de eventos remotos. Este objetivo se puede dividir en: ▪ Análisis de los recursos que pone a nuestra disposición FHIR y de sus características. ▪ Mapeo de los datos que se manejan en FIWARE en dichos recursos. ▪ Despliegue del servidor FHIR e interconexión con la plataforma FIWARE. 1.3 Antecedentes El punto de partida de este proyecto es el Trabajo Fin de Grado: “Agente IoT de FIWARE para el control de un dispositivo de monitorización de actividad física” de Rafael Díaz Fernández [3], realizado en 2019. En este proyecto se desarrolla un Agente IoT en una aplicación móvil, el cual recibe datos de seguimiento del estado de un paciente, de una camiseta inteligente, y los envía a Orion Context Broker. La camiseta inteligente realiza una monitorización de la actividad física, obtiene una estimación del gasto metabólico y la frecuencia cardíaca. Además, se desarrollaba un servicio web mediante Angular, para poder observar la información almacenada en FIWARE. En este proyecto, se han realizado una serie de mejoras con respecto al sistema anteriormente comentado, y se han añadido nuevas funcionalidades, mediante el uso de un procesador de eventos complejos, el cual permite analizar, de manera automática, la gran cantidad de datos que se manejan, y actuar rápidamente en caso de que se den eventos de interés, marcados por una serie de reglas. Ciertos eventos quedarán registrados en un sistema FHIR, para poder llevar a cabo un control de la evolución del paciente. Además, se ha sustituido el servicio web por una interfaz visual desarrollada en Freeboard, la cual permite una monitorización más clara de los datos, así como una representación que facilita la obtención de conclusiones de una forma más sencilla. 1.4 Descripción de la solución La arquitectura de la solución escogida es la siguiente: Estado del arte 10 Figura 2-2. Logo de FIWARE Figura 2-1. Evolución del número de dispositivos IoT conectados en todo el mundo. Fuente: [9] Entre las grandes ventajas que aporta esta tecnología podemos mencionar la automatización de procesos, ahorrando tiempo y esfuerzo. Por otra parte, permite la recolección de datos, en tiempo real, de forma que dicha información esté al alcance de cualquier persona en cualquier parte del mundo. Además, permite aumentar la velocidad en el análisis de datos y facilitar su seguimiento, lo que junto a la gran cantidad de datos que nos ofrece, nos permite llevar a cabo mejores tomas de decisiones. Debido a sus grandes ventajas, el IoT se está extendiendo en todos los ámbitos de la vida cotidiana, por ejemplo, con el uso de smartwatches o en la domótica de casas automatizadas. El ámbito empresarial es el principal consumidor de esta tecnología, ya que sectores como el transporte o la agricultura se ven beneficiados por las características que IoT les ofrece a través del despliegue de sensores en los procesos o vehículos. En el sector sanitario su uso está aumentando considerablemente, ya que se está utilizando para conocer el estado de los pacientes de forma más precisa, incluso cuando están fuera del hospital, facilitando su seguimiento y permitiendo automatizar ciertos procesos. En la actualidad exiten diferentes plataformas que implementan el paradigma IoT, una de las más importantes es FIWARE. 2.2 FIWARE FIWARE es una plataforma de software abierto, surgida de la colaboración público-privada entre la Comisión Europea y la industria europea, iniciada en 2011, y que sigue en continuo crecimiento. Su principal objetivo es construir un ecosistema abierto y sostenible en torno a estándares de plataformas de software públicas, e impulsadas por la implementación de herramientas que faciliten el desarrollo de nuevas aplicaciones inteligentes, en múltiples sectores. FIWARE apuesta por el desarrollo colaborativo de “Smart-solutions” y por tecnologías como Internet de las Cosas (IoT), Cloud Computing y Open Data [10]. Figura 2-3. Esquema básico del procedimiento de una Smart Solution FIWARE quiere impulsar un estándar que describa cómo recopilar, gestionar y publicar información de contexto, y adicionalmente aporta elementos que permiten explotar esta información una vez recopilada. También resuelve, de manera sencilla, cómo capturar información procedente de redes de sensores, aunque se comuniquen usando diferentes protocolos y lenguajes IoT. En ese sentido es capaz de resolver la complejidad de tratar la información recogida por los sensores y traducirlos a un lenguaje común [11]. Esta plataforma se basa en el uso de componentes estándar de dominio público llamados Generic Enablers. El más importante es el Orion Context Broker, el cual brinda una función fundamental en cualquier solución inteligente: permite administrar la información de contexto, realizar actualizaciones, y brinda acceso a dicha información. El resto de Generic Enablers están desarrollados en torno a este componente, englobados en las siguientes categorías [11]: ▪ Interfaz con Internet de las Cosas (IoT), robots y sistemas de terceros, para capturar actualizaciones sobre infomación de contexto y traducir las actuaciones requeridas. ▪ Gestión, publicación y monetización de datos de contexto/API, brindando soporte para el control de uso y la oportunidad de publicar y monetizar parte de los datos de contexto administrados. ▪ Procesamiento, análisis y visualización de información de contexto implementando el comportamiento inteligente esperado de las aplicaciones y/o ayudando a los usuarios finales a tomar decisiones inteligentes. 2.2.1 NGSIv2 NGSI (Next Generation Service Interface) es un protocolo desarrollado por la OMA (Open Mobile Alliance), que se basa en una API RESTful para comunicarse mediante peticiones HTTP. Su principal aplicación es administrar todo el ciclo de vida de la información de contexto, incluidas las actualizaciones, consultas, registros y suscripciones [12]. Se entiende por información de contexto aquella información relevante sobre algún parámetro en un instante dado, procedente de diferentes fuentes de datos. La comunicación entre los distintos componentes que forman parte de la plataforma FIWARE se lleva a cabo mediante NGSI. Actualmente, en FIWARE funcionan conjuntamente dos versiones de esta API: NGSIv1 y NGSIv2. La versión 2 incorpora más funcionalidades, además, está sustituyendo progresivamente a la versión 1, siendo compatible en los componentes donde funciona esta primera versión. Además, los nuevos componentes se están desarrollando para la segunda versión. Por estos motivos, se ha decidido realizar este proyecto haciendo uso de NGSIv2. Este protocolo define: Estado del arte 12 Figura 2-4. Estructura de una entidad de contexto. Fuente: [12] Figura 2-5. Representación JSON de una entidad NGSI ▪ Un modelo de datos para la información de contexto, basado en el concepto de “entidades de contexto”. ▪ Una interfaz de datos de contexto para intercambiar información, por medio de operaciones de consutas, suscripciones y actualizaciones. ▪ Una interfaz de disponibilidad de contexto, para intercambiar información sobre cómo obtener la propia información de contexto. 2.2.1.1 Modelado de la información de contexto Los principales elementos que componen el modelo de datos NGSI son las entidades, los atributos y los metadatos. Primero tenemos las entidades. Una entidad puede representar cualquier cosa, ya sea física o lógica, como por ejemplo un sensor o una persona. Cada entidad tiene un campo type, tipo, el cual está pensando para describir el tipo de cosa representado por la entidad. Además, tiene un campo id, que junto a type, permite identificar de forma única una entidad. Cada entidad esta formada por una serie de atributos. Cada uno de ellos tiene un nombre, un tipo, un valor y un conjunto opcional de metadatos asociados. El nombre describe que propiedad representa dicho atributo. El tipo del atributo representa el tipo de valor NGSI correspondiente al valor del atributo. Por último, encontramos su valor actual y, opcionalmente, metadatos que describen propiedades del atributo, como puede ser su precisión o quién es el proveedor de dicha información. Los metadatos están formados por 3 campos: un nombre, que describe el papel del metadato, un tipo, que proporciona que tipo de valor NGSI se está usando, y el propio valor actual de dicho metadato. Una entidad se representa por un objeto JSON, mediante la siguente sintaxis: Figura 2-7. Estructura-comunicación del Orion Context Broker. Fuente: [13] Figura 2-6. Representación JSON de una entidad NGSI en modo “keyValues” Existen otros tipos de representaciones, como la simplificada o la parcial. Además, la especificación de cada operación incluye detalles sobre qué representación se espera como entrada, o qué representación se proporcionará como salida. En este proyecto se hace uso, en la parte correspondiente a la interfaz gráfica, de un tipo de representación llamada representación simplificada modo “keyValues”. En este modo se representan los atributos de la entidad en parejas nombre-valor, excluyendo información sobre el tipo y los metadatos. También incluye información sobre el identificador y tipo de la entidad. 2.2.2 Orion Context Broker El principal y único componente obligatorio de cualquier plataforma o solución “Powered by FIWARE” es Orion Context Broker (OCB). Como se ha comentado anteriormente, Orion implementa la API REST NGSIv2, la cual permite administrar todo el ciclo de vida de la información de contexto, incluidas actualizaciones, consultas, registros y suscripciones, basando su comunicación con otros componentes del sistema en mensajes HTTP [13]. OCB permite la publicación de información de contexto por elementos llamados “productores de contexto”, de forma que dicha información publicada se encuentre disponible para otros elementos, llamados “consumidores de contexto”, las cuales están interesados en recibir esta información. El servidor OCB siempre está escuchando en un puerto, que por defecto es el 1026, pero se puede modificar. Para almacenar el estado actual de sus entidades, OCB usa la base de datos MongoDB, pero no se almacena información histórica de sus cambios. Si se quisiera conseguir esto, habría que utilizar una base de datos externa. Estado del arte 14 El principio fundamental en el que se basa el Context Broker es el de lograr una disociación total entre productores y consumidores de contexto. Los productores de contexto publican datos sin saber ni quién, ni dónde, ni cuándo consumirán dichos datos publicados. Por otro lado, los consumidores de contexto obtienen información de su interés sin saber qué productor ha sido quien lo ha publicado. Por ello, no se necesita una conexión entre ambas partes. Además, los consumidores pueden suscribirse a la información de contexto, para que cuando ocurra alguna condición, como por ejemplo una actualización de los valores de los atributos de una entidad, reciban una notificación con dicha actualización. 2.2.2.1 Suscripción Una petición de suscripción se representa mediante un objeto JSON con los siguientes campos: ▪ description: se emplea para que el cliente introduzca una breve descripción de la suscripción. Su uso es opcional. ▪ subject: describe qué entidades se ven afectadas por dicha suscripción y bajo qué condiciones. A su vez, está formado por los campos: entities y condition. entities define qué entidades están involucradas en la suscripción y se compone de: • id o idPattern: identificador de la entidad afectada, o patrón de entidades afectadas. Son incompatibles, es decir, no se pueden usar ambos en la misma suscripción. • type o typePattern: tipo de la entidad, o patrón de tipo al que afectará. Al igual que el campo anterior, no se pueden usar ambos en el mismo objeto. condition define el “disparador” para la suscripción. Contiene el campo attrs, el cual almacena una lista de nombres de atributos. Una modificación en el valor de alguno de estos atributos activaría una notificación. Si este campo está vacío significa que, cualquier cambio en un atributo de las entidades afectadas, desencadenaría una notificación. ▪ notification: describe la notificación que va a ser enviada por OCB en caso de que se cumplan las condiciones de la suscripción. Está compuesto de: • http: contiene el subcampo url, donde se indica a qué URL se van a enviar las notificaciones. Solo se puede incluir una URL por suscripción. • attrs o exceptAttrs: attrs define el conjunto de atributos que serán incluidos en el mensaje de notificación. En caso de que este vacío, significa que todos los atributos de la entidad serán incluidos. exceptAttrs define el conjunto de atributos que serán excluidos del mensaje de notificación, es decir, se incluirán todos los atributos de la entidad menos los que aparezcan en esta lista. • attrsFormat: especifica cómo deben ser representadas las entidades en las notificaciones. Es opcional y por defecto su valor es “normalized”. • metadata: define el conjunto de metadatos que se deben incluir en los mensajes de notificación. ▪ expires: indica la fecha de vencimiento de la suscripción, a partir de la cual se ignora, manteniéndose aún almacenada en la base de datos, ya que es posible modificar su duración, actualizando este campo. Se especifica en formato ISO 8601. Si este campo no aparece, significa que la suscripción no tiene fecha de vencimiento, es decir, es permanente. ▪ throttling: indica el tiempo mínimo que debe pasar entre dos notificaciones consecutivas. Se mide en segundos. Figura 2-8. Estructura de una notificación por defecto 2.2.2.2 Notificación Una notificación está formada por dos campos: ▪ subscriptionId: referencia al identificador de la suscripción que originó dicha notificación. ▪ data: es un vector con los datos de la notificación en sí, es decir, los datos a enviar que han sido configurados en la suscripción, la cual ha provocado dicha notificación. Cada elemento del vector se corresponde a una entidad diferente. Como se ha comentado en el apartado de las suscripciones, la representación de las entidades depende del valor configurado en attrsFormat. En la Figura 2-8 se muestra un ejemplo de notificación. 2.2.3 Perseo Perseo [14] es un software de procesamiento de eventos complejos (CEP) basado en Esper, diseñado para ser totalmente compatible con NGSIv2. Al utilizar NGSIv2 como protocolo de comunicación para eventos, Perseo puede trabajar conjuntamente con Orion Context Broker. El principio de funcionamiento de Perseo se basa en escuchar eventos que provienen de la información de contexto, para así poder identificar patrones descritos por reglas, con el fin de reaccionar de inmediato a ellos mediante diversas acciones. Estado del arte 16 Figura 2-9. Estructura de funcionamiento de Perseo. Fuente: [14] Perseo recibe los eventos a través de un POST, el cual contiene la representación JSON del evento, y le aplica las reglas, expresadas en EPL, lenguaje de reglas de Esper. Esper es la biblioteca Java que contiene el motor de reglas y la lógica de procesamiento de eventos. Cuando un evento entrante activa una regla, los valores seleccionados por la expresión EPL se emplean para llevar a cabo la acción desencadenada. Perseo necesita interactuar con OCB, ya que es la fuente de eventos de las entidades que Perseo gestiona. Además, una de las posibles acciones que puede desencadenar Perseo, consiste en la actualización de una entidad de Orion, como detallaremos más adelante. Además, necesita de conexión con una base de datos MongoDB, ya que es donde almacenará las reglas configuradas, con las ejecuciones de acciones asociadas. Perseo está formado por dos componentes (ver Figura 2-9): ▪ Perseo-FE: es el “front-end” del procesador de eventos complejos. Es la parte encargada de procesar los eventos y reglas entrantes, almacenar las reglas y ejecutar las acciones. Además, registra la ejecución de acciones, para así controlar la frecuencia con la que se realizan dichas acciones. ▪ Perseo Core: es el “back-end” del CEP, el “motor de reglas”. Se encarga de comprobar los eventos entrantes de acuerdo con las reglas en EPL y de invocar a Perseo-FE si se debe llevar a cabo una acción. No tiene almacenamiento persistente. Las reglas se guardan en memoria y son actualizadas periódicamente por Perseo-FE. Las notificaciones enviadas por Orion Context Broker son procesadas por Perseo-FE antes de ser enviadas a Perseo Core como eventos. 2.2.3.1 Regla Mediante la aplicación de reglas, Perseo genera eventos “complejos” a partir de un evento entrante. En general consiste en una condición a cumplir y una acción resultante. Esta acción es siempre elegida de un conjunto preestablecido de acciones, como veremos en el siguiente apartado. Figura 2-10. Estructura de una regla en Perseo. Fuente: [14] Las reglas siguen una estructura JSON compuesta de tres campos obligatorios: ▪ name: define el nombre de la regla, y se utiliza como identificador de esta. Debe comenzar por una letra, y puede contener dígitos, guiones bajos y guiones. Su longitud máxima es de 50 caracteres. ▪ action: establece que acción debe realizar Perseo cuando se activa la regla. Se pueden establecer más de una acción en la misma regla, evitando así tener que duplicar una regla si queremos ejecutar más de una acción. ▪ text: contiene la declaración EPL que se enviará a Perseo Core, es decir contiene la regla propiamente dicha. Las reglas se expresan como una oración EPL. EPL (lenguaje de procesamiento de eventos) [15] es un lenguaje de dominio de Esper [16], el motor para procesar eventos utilizado en Perseo Core, que implementa y extiende del estándar SQL. EPL es un lenguaje declarativo creado para poder tratar con datos de eventos de alta frecuencia, que permite la consulta y el procesamiento de eventos en tiempo real, así como la posibilidad de añadir una “dimensión temporal” a esto. A continuación, se van a explicar algunas de las principales cláusulas que se utilizan en este lenguaje, con el fin de que más adelante se puedan entender mejor las expresiones EPL empleadas durante el desarrollo de este proyecto: ▪ select: se utiliza para especificar las propiedades a seleccionar de los eventos. Es obligatorio su uso. Mediante el símbolo “*” se indica que queremos seleccionar todas las propiedades. ▪ from: especifica la fuente de datos de la que va a provenir el evento. Se pueden indicar más de una fuente de datos, separándolas por comas, pero siempre debe aparecer al menos una, es decir, es obligatorio que aparezca en la expresión EPL. ▪ where: esta cláusula permite establecer las condiciones que deben cumplir los eventos entrantes para que se active la regla. Permite el uso de operadores como =. <, >, <=, >=, ¡=, <>, IS NULL, IS NOT NULL, y de combinaciones lógicas AND y OR. ▪ pattern: comprueba si se satisfacen una serie de condiciones sobre eventos de flujos de entrada, los cuales han de ser identificados de forma unívoca. Aparece en conjunto con la cláusula from, escribiéndose justo después de esta. ▪ and: operador lógico que requiere que tanto la expresión de su izquierda, como la de su derecha, se cumplan, para que este devuelva un valor verdadero. ▪ or: operador lógico que requiere que al menos una de las dos expresiones que aparecen a su lado se cumpla, para que este devuelva un valor verdadero. ▪ not: operador que retorna un valor verdadero si la expresión no se cumple. ▪ every: operador que se utiliza para controlar la coincidencia contínua de patrones. El patrón se dispara cada vez que se encuentre con un evento del tipo especificado. Si no se especifica este operador el patrón no seguirá buscando una vez se haya detectado la primera ocurrencia de ese tipo de evento. Estado del arte 18 ▪ win:length(size): esta cláusula permite llevar a cabo reglas que impliquen a un número de eventos, especificado dentro del paréntesis. Es decir, conforma una ventana de longitud móvil, deslizante, que extiende un número de elementos, obtenidos a partir de un flujo de eventos de entradas, permitiendo realizar cálculos a partir de ellos. ▪ win:time(time period): esta cláusula es similar a la anterior, pero la ventana en lugar de basarse en elementos, se basa en un intervalo de tiempo. Es decir, proporciona una ventana de tiempo móvil, que se extiende el intervalo de tiempo especificado hacia el pasado, en función de la hora del sistema, permitiendo realizar operaciones según los eventos obtenidos dentro de dicha ventana. ▪ regexp: comprueba si la expresión proporcionada coincide con el patrón configurado en el operador, devolviendo un valor verdadero en caso de que así sea, o un valor falso en caso contrario. Perseo funciona con cualquiera de las cláusulas EPL, pero con algunos matices: ▪ El nombre de la secuencia de la que vendrán los eventos es iotEvent. ▪ Es obligatorio el uso de la condición “type=<…>”, con el fin de evitar mezclar los diferentes tipos de entidades. ▪ Los atributos de la entidad se deben convertir a float en caso de que sean numéricos, o a string en el caso contrario. ▪ Todos los atributos de la notificación están disponibles como propiedades dinámicas del objeto de evento, ev. ▪ Es necesario un signo de interrogación para que EPL se refiera a valores dinámicos. ▪ Los metadatos también están disponibles para su uso. 2.2.3.2 Acción Cuando a Perseo le llega un evento que coincide con alguna de las reglas almacenadas en el motor de reglas, esa regla se activa. Perseo Core genera un evento complejo, utilizando para ello los parámetros añadidos en la instrucción select de la cláusula del EPL, y se lo envía a Perseo-FE, el cual ejecutará una acción, utilizando el evento generado como parámetro Como se ha comentado en el apartado anterior, las acciones a realizar se establecen mediante el campo action de la regla. Dentro del este campo, encontramos, obligatoriamente, el subcampo type, que puede tener uno de los siguientes valores [17]: ▪ update: actualiza uno o más atributos de una entidad dada, en el OCB especificado en la configuración de Perseo. ▪ sms: envía un SMS a un número establecido como parámetro de la acción, con un cuerpo de mensaje creado. ▪ email: envía un correo electrónico al destinatario establecido en los parámetros, con el cuerpo del correo configurado. ▪ post: realiza una solicitud HTTP a una URL proporcionada, con un cuerpo establecido en la configuración de la regla. ▪ twitter: envia un tweet, a través de una cuenta para la cual tiene permiso de acceso. Una acción, opcionalmente, puede tener un campo llamado interval, que representa el tiempo mínimo que debe transcurrir entre ejecuciones consecutivas. Se expresa en milisegundos y su objetivo es limitar la frecuencia con la que se ejecuta la acción. Es decir, una vez que se ejecuta la acción con éxito, no se volverá a ejecutar hasta que haya transcurrido ese período de tiempo como mínimo, descartando todas las solicitudes de ejecución que puedan llegar durante ese intervalo. Dentro de las posibles acciones que Perseo puede realizar, vamos a entrar en más detalle en tres de ellas, las que hemos aplicado durante el proyecto: email, post y update. Si la acción a realizar es de tipo email, tendremos que rellenar los diferentes campos que conforman el correo electrónico a enviar en caso de que se active: ▪ template: en este campo se introduce el cuerpo del email. ▪ parameters: dentro de este campo encontramos: • to: establece cuál es la dirección destino del correo electrónico. • from: establece el correo electrónico desde el cual va a ser enviado el email. • subject: indica el asunto del propio email. En cambio, si la acción a realizar es de tipo post, los campos que nos encontramos son: ▪ template: cuerpo de la solicitud HTTP. ▪ parameters: dentro de este campo se encuentran: • method: método HTTP a utilizar. Por defecto su valor es POST. • url: URL destino que va a tener la solicitud HTTP. • headers: objeto con los campos y valores, de los diferentes encabezados que se desea que tenga la solicitud. • qs: objeto con campos y sus correspondientes valores, para construir la cadena de consulta de la URL. • json: objeto que se enviará, en formato JSON, como cuerpo de la solicitud realizada. En caso de que esté presente, anula el valor del campo template. Por último, si la acción a realizar es de tipo update debemos cumplimentar los siguientes campos, localizados dentro del campo parameters: ▪ id: identificador de la entidad cuyos atributos se van a actualizar. Si no se indica, por defecto se usa el identificador de la entidad que activó la regla. ▪ type: tipo de la entidad a modificar. Por defecto se utiliza el tipo de la entidad que llevó a cabo la activación de la regla. ▪ version: versión NGSI a utilizar para llevar a cabo la actualización. Por defecto se utiliza NGSIv1. Para utilizar el formato NGSIv2 habría que establecer el valor de este atributo a 2. ▪ isPattern: indica si el id especificado es una expresión regular, con la que poder seleccionar más de un elemento. Por defecto su valor es “false”. Este campo sólo tiene efecto para NGSIv1, siendo ignorado si se aplica NGSIv2. ▪ attributes: conjunto de atributos que se van a modificar. Cada elemento de la lista debe contener los siguientes campos: • name: nombre del atributo. • value: nuevo valor que se desea establecer para dicho atributo. • type: tipo del atributo. Este campo es opcional, si no se indica, el tipo del atributo a actualizar no cambia. ▪ actionType: tipo de acción a realizar. Dispone de tres posibilidades: • APPEND: actualiza los atributos, si ya existen en la entidad, o los anexa a dicha entidad en el caso de que no existan. Es el tipo de acción establecida por defecto. Estado del arte 26 Tabla 2-10. Definición Observation.identifier Observation.identifier Cardinalidad 0..* Tipo Identifier Descripción Identificador de negocio único asignado a la observación. Destacamos la diferencia entre el identificador de negocio y el identificador lógico, comentada en el punto “2.5.1 Recursos”. Tabla 2-11. Definición Observation.basedOn Observation.basedOn Cardinalidad 0..* Tipo Reference (CarePlan | DeviceRequest | ImmunizationRecommendation | MedicationRequest | NutritionOrder | ServiceRequest) Descripción Refencia a un plan, propuesta u orden que, de formar parcial o total, cumple este recurso. Tabla 2-12. Definición Observation.parOf Observation.partOf Cardinalidad 0..* Tipo Reference (MedicationAdministration | MedicationDispense | MedicationStatement | Procedure | Immunization | ImagingStudy) Descripción Referencia a un recurso “mayor”, del cual la observación es un componente de este. Tabla 2-13. Definición Observation.status Observation.status Cardinalidad 1..1 Tipo code Descripción Indica el estado del valor de dicha observación. Los estados posibles son: “registered”, “preliminary”, “final” y “amended”. Tabla 2-14. Definición Observation.category Observation.category Cardinalidad 0..* Tipo CodeableConcept Descripción Código que clasifica, de forma general, la observación que se realiza según su tipo Tabla 2-15. Definición Observation.code Observation.code Cardinalidad 1..1 Tipo CodeableConcept Descripción Describe qué aspecto se representa mediante este recurso, es decir, que se observó. Tabla 2-16. Definición Observation.subject Observation.subject Cardinalidad 0..1 Tipo Reference (Patient | Group | Device | Location) Descripción Referencia al paciente, o grupo de pacientes, ubicación o dispositivo, del que trata la observación, y en cuyo registro se va a colocar esta. Este campo es importante, ya que una observación carece de valor si no se sabe de quién o de qué se trata. Tabla 2-17. Definición Observation.effective[x] Observation.effective[x] Cardinalidad 0..1 Tipo dateTime | Period | Timing | instant Descripción Tiempo, o periodo de tiempo, en el que la observación se ha llevado a cabo. Al menos una fecha debe estar presente, a no ser que la observación sea un informe histórico. Estado del arte 28 Tabla 2-18. Definición Observation.value[x] Observation.value[x] Cardinalidad 0..1 Tipo Quantity | CodeableConcept | string | boolean | integer | Range | Ratio | SampledData | time | dateTime | Period Descripción Información extraída como resultado de hacer la observación, en el caso de que la información tenga un valor simple Tabla 2-19. Definición Observation.note Observation.note Cardinalidad 0..* Tipo Annotation Descripción Comentarios sobre los resultados obtenidos con la observación. Puede incluir declaraciones generales sobre dicha observación, información sobre la fuente de esta, si es un dato relevante para poder interpretarla, o declaraciones sobre valores de resultados significativos, inesperados o poco confiables. Tabla 2-20. Definición Observation.device Observation.device Cardinalidad 0..1 Tipo Reference (Device | DeviceMetric) Descripción Referencia al dispositivo utilizado para obtener los datos de la observación. 2.5.2 HAPI FHIR HAPI (Health Application Programming Interface) FHIR [28] es una implementación completa del estándar HL7 FHIR, para la interoperabilidad de la atención médica, basada completamente en lenguaje de programación Java. Es una biblioteca Java de código abierto, que facilita un mecanismo incorporado para agregar las funcionalidades RESTful Server de FHIR a una aplicación software. Figura 2-14. Logo de HAPI FHIR Figura 2-15. Logo de Freeboard Su intención principal es proporcionar una forma flexible de agregar las capacidades que ofrece FHIR a todo tipo de aplicaciones. Para ello proporciona herramientas para crear servidores conforme a este estándar, para analizar, codificar y decodificar recursos FHIR, o para configurar un cliente, el cual permita recuperar y registrar recursos en un servidor FHIR externo. El servidor HAPI RESTful se basa en un servlet, por lo que se puede implementar con facilidad en cualquier contenedor compatible con servlet 3.0 +, como por ejemplo Jetty o Apache Tomcat. 2.6 Freeboard Freeboard [29] es una plataforma OpenSource, que nos permite la creación de paneles interactivos y visualizaciones en tiempo real, mediante una intuitiva interfaz. La creación de dashboards se lleva a cabo mediante la unión de diferentes widgets, los cuales son los encargados de mostrar los datos en tiempo real, de acuerdo con un tipo de representación. Además, presenta una arquitectura de complementos para crear fuentes de datos, de las cuales se van a obtener la información, y widgets, los cuales van a representar los datos. Freeboard, internamente, se encarga de conectar ambas partes. Una de sus principales características, es la capacidad de ejecutarse complemente en el navegador como una aplicación web estática de una sola página, sin la necesidad de un servidor. Freeboard proporciona un panel de configuración compuesto por una parte dedicada a Datasources donde se pueden agregar nuevas fuentes de datos al dashboard, así como ver/configurar las previamentes añadidas. Los widgets configurados podrán obtener los datos de las fuentes de datos que aquí aparezcan. Por otra parte, en el panel de configuración tenemos una parte dedicada a la agregación y configuración de paneles de visualización, con la posibilidad de configurar sus dimensiones y la opción de añadirles un título. En estos paneles de visualización se pueden añadir y configurar los widgets, que serán quienes finalmente se encarguen de representar los datos. Estado del arte 30 Figura 2-17. Logo de Ubuntu 18.04 LTS Figura 2-16. Logo de VMware Workstation 2.6.1 Configuración Datasources En el panel de configuración Datasources tenemos la opción de añadir nuevas fuentes de datos al dashboard. Para ello, primero tenemos que seleccionar qué tipo de fuentes de datos vamos a usar, obteniendo una serie de campos diferentes según el tipo que seleccionemos. A continuación, se van a explicar el significado de los campos que aparecen en el caso de seleccionar el tipo de fuente JSON, que será la que se va a usar en este proyecto, ya que es el formato en el que se van a obtener los datos de Orion Context Broker: ▪ Type: indica el tipo de fuente de datos que vamos a crear. Como se ha comentado, en este caso usamos el tipo JSON. ▪ Name: nombre con el cual vamos a referenciar a dicha fuente de datos. ▪ URL: en este campo se ha de indicar la URL de la cual vamos a obtener la información, es decir, la dirección a la cual Freeboard hará peticiones para poder obtener los datos periódicamente. ▪ Try thingproxy: permite activar o desactivar thingproxy, el cual es un proxy JavaScript que permite solucionar problemas relacionados con peticiones a servidores que no envían encabezados CORS o relacionados con peticiones HTTPS a recursos que no son HTTPS. ▪ Refresh every: establece con qué frecuencia se refrescarán los datos, en qué intervalo de tiempo se llevará a cabo la petición para obtener nuevos valores para los widgets. ▪ Method: indica qué tipo de petición se va a llevar a cabo. ▪ Body: en este campo se introduce el cuerpo de la petición. Sólo se rellenará en caso de que el método usado para la petición sea POST. ▪ Headers: en este campo se introducen las cabeceras que se quieran añadir en las peticiones que se van a realizar. 2.7 Recursos software En esta sección se detallan los recursos software empleados durante el proyecto. 2.7.1 VMware Workstation 14 player y máquina virtual “Ubuntu/Debian” Para el desarrollo de este proyecto se ha decidido utilizar el sistema operativo Ubuntu, en particular, Ubuntu 18.04.4 LTS, con kernel Linux 4.15.0-96-generic. Esta decisión se ha llevado a cabo en base a la compatibilidad de implementación, de los elementos que componen el proyecto con este sistema operativo. Para su uso se ha empleado VMware Player, creando una máquina virtual con dicho SO. Figura 2-18. Logo de Docker Figura 2-19. Comparativa estructura contenedores Docker frente a máquina virtual. Fuente: [32] 2.7.2 Docker Docker es un proyecto de código abierto que automatiza el despliegue de aplicaciones dentro de contenedores de software, proporcionando una capa adicional de abstracción y automatización de virtualización de aplicaciones, en múltiples sistemas operativos [30]. Docker empaqueta software en unidades estandarizadas llamadas contenedores, donde se incluye todo lo necesario para ejecutar una aplicación de forma independiente: código, entorno de ejecución, librerías, configuraciones y herramientas del sistema [31]. Esta tecnología ofrece un modelo de implementación basado en imágenes, lo cual permite compartir una aplicación, junto con todas sus dependencias, en varios entornos. Estas imágenes se convierten en contenedores cuando se ejecutan. Las máquinas virtuales ofrecen beneficios similares a los contenedores en temas de aislamiento y asignación de recursos, pero funcionan de forma diferente, ya que los contenedores virtualizan el sistema operativo en lugar del hardware. En este proyecto se va a emplear esta tecnología sobre una máquina virtual de Linux. Docker utiliza características de aislamiento de recursos del kernel Linux, tales como cgroups y espacios de nombre para permitir que contenedores independientes se ejecuten dentro de una sola instancia de Linux, evitando la sobrecarga de iniciar y mantener máquinas virtuales [30]. Estado del arte 32 Figura 2-20. Logo de Postman MongoDB, Orion Context Broker, Perseo-FE y Perseo Core van a ser ejecutados mediante el uso de contenedores Docker, debido a que facilita el proceso de instalación enormemente, eliminando la necesidad de instalar un gran número de dependencias por cada componente. Además, es la opción de instalación que la propia plataforma FIWARE recomienda de forma explícita. 2.7.3 Postman Postman es un entorno de desarrollo de APIs, que facilita el construir, probar, documentar, monitorizar y publicar documentación sobre ellas. Entre sus principales características, permite crear y enviar peticiones HTTP a servicios REST, mediante una interfaz gráfica muy intuitiva. Estas peticiones pueden ser guardadas e incluso, se pueden definir colecciones, para automatizar procesos, definiendo las variables a utilizar en las diversas peticiones [33]. Mediante la interfaz gráfica que ofrece, es posible configurar los diferentes parámetros que conforman una petición HTTP. Primero tenemos que seleccionar el tipo de petición a realizar, entre los diferentes tipos disponibles. Durante el proyecto se ha hecho uso de los tipos GET, POST y PATCH. A continuación, hay que introducir la URL a la cual va a ir dirigida. También nos permite configurar la petición mediante la introducción de parámetros, haciendo uso de la herramienta Params; y de diferentes cabeceras, mediante el uso de Headers. Además, podemos añadir un cuerpo al mensaje, aplicando para ello la herramienta Body. Una vez el mensaje está completo, se envía pulsando el botón Send, y nos aparece la respuesta a dicha petición totalmente desglosada [34]. En este proyecto se ha utilizado este recurso para crear y lanzar peticiones, con el fin de comunicarnos con los diferentes elementos que componen el sistema. Esto se ha llevado a cabo mediante el uso de peticiones HTTP en formato JSON a las diferentes APIs que aportan cada componente. Además, se ha empleado para simular las actualizaciones en los valores que recibiríamos por parte del agente IoT sobre el estado del paciente. Se ha creado una colección con todas las peticiones (o con su formato) que se emplean a lo largo del trabajo, lo que facilita montar el escenario y probar el sistema. Figura 2-21. Interfaz gráfica de Postman 2.7.4 Otras herramientas ▪ Apache Tomcat [35]: es un contenedor de servlets, el cual implementa las especificaciones Java Servlet, JavaServer Pages, Java Expression Language y WebSocket de Oracle Corporation. Proporciona un entorno de servidor web HTTP que puede ser usado en entornos con alto nivel de tráfico y alta disponibilidad. Dado que está escrito en Java, funciona con cualquier sistema operativo que disponga de la máquina virtual Java. ▪ Git [36]: sistema de control de versiones distribuido que permite rastrear cambios en el código fuente durante el desarrollo de software. Está diseñado para coordinar el trabajo que varias personas realizan sobre archivos compartidos, pero se puede usar para llevar un registro de los cambios en cualquier conjunto de archivos. A medida que se modifican los archivos, el sistema de control de versiones registra y guarda cada cambio, lo cual permite restaurar una versión anterior de estos en cualquier momento. Git sirve de base para muchos servicios, como GitHub y GitLab. ▪ Apache Maven [37]: herramienta para la construcción y administración de proyectos basados en Java. Utiliza un Project Object Model (POM) para describir el proyecto software a construir, sus dependencias de otros módulos y componentes externos, y el orden de construcción de los elementos. Su modelo de configuración de construcción se basa en un formato XML. ▪ Npm [38]: administrador de paquetes para el lenguaje de programación JavaScript, a través del cual podemos obtener fácilmente cualquier librería, lo cual nos permite agregar dependencias de forma simple, distribuir paquetes y administrar eficazmente tanto módulos como proyectos a desarrollar. Es el sistema de gestión de paquetes por defecto para Node.js. ▪ Grunt [39]: es un corredor de tareas de JavaScript, una herramienta utilizada para realizar automáticamente tareas que deben realizarse de forma rutinaria. Una de sus principales características es que ofrece la capacidad de agregar, ampliar y modificar tareas personalizadas, cada una con su conjunto de opciones de configuración modificables, en un archivo llamado Gruntfile, que posteriormente será el que se ejecute. Estado del arte 34 3 RESULTADOS ste capítulo aborda en detalle la solución llevada a cabo en este proyecto, junto con los resultados obtenidos. En primer lugar, describe el diseño de la plataforma desarrollada, los componentes que la componen y cómo se comunican entre ellos. A continuación, se describe cómo se ha llevado a cabo el despliegue de los diferentes elementos que conforman el sistema y cómo se ha realizado la conexión entre cada uno de ellos, es decir, se verá todo el proceso desde cero hasta la solución final elegida. Se mostrará el mapeo que se ha realizado de la información, en entidades FIWARE, y cómo se envía dicha información. Además, se explica cómo se ha realizado el dashboard mediante Freeboard, de qué manera se han configurado las distintas fuentes de datos y los widgets que componen la interfaz gráfica. Por último, se plantean una serie de escenarios que podrían suceder en un entorno real de monitorización de diferentes pacientes, para observar el potencial de la solución desarrollada y la amplia variedad de funcionalidades que nos ofrece. 3.1 Diseño de la plataforma En la Figura 3-1, podemos ver los diferentes componentes que forman el sistema desarrollado en este trabajo. En primer lugar, tenemos los agentes IoT (“publicadores” en la figura), los cuales son los encargados de recibir la información del estado del individuo a través de los dispositivos de monitorización, procesarla y enviarla a Orion Context Broker (OCB) en forma de entidades PhysicalActivity. Orion gestiona dichas entidades y cuando recibe nuevas publicaciones, se encarga de hacérselas llegar a aquellos componentes que previamente se han suscrito. En este caso, tenemos como suscriptor al procesador de eventos, Perseo, el cual podrá estar suscrito a todas las entidades de este tipo, recibiendo los datos de todos los pacientes que hagan uso de este tipo de entidades, o puede suscribirse sólo a aquellas entidades que le sean de interés, por ejemplo, un grupo de pacientes adscritos a cierto médico u hospital. Más concretamente, Perseo Front-End (FE) es el componente de Perseo suscrito a Orion. Perseo-FE se encarga de procesar las notificaciones que proceden del OCB, y una vez procesadas, de enviárselas a Perseo Core en forma de eventos. Además, se ocupa de procesar las nuevas reglas que llegan a Perseo, que indican qué condiciones en los eventos entrantes deben desencadenar algún tipo de acción, y si las reglas están bien estructuradas y sin errores, se encarga de almacenarlas en una base de datos MongoDB. E En cuestiones de ciencia, la autoridad de miles no vale más que el humilde razonamiento de un único individuo. - Galileo Galilei - Resultados 42 Como se puede ver en la Figura 3-6, los atributos que conforman la estructura de este tipo de entidades son los siguientes: ▪ instant_metabolic_expenditure: gasto calórico instantáneo ocasionado por la actividad física del paciente en el momento en el cual se envía el mensaje, medido en kilocalorías. Se representa mediante una variable de tipo “Float”. ▪ accumulates_metabolic_expenditure: representa el gasto calórico total, acumulado desde que comenzó el día hasta el momento. Al igual que el atributo anterior, se mide en kilocalorías y es representado mediante una variable de tipo “Float”. ▪ heart_rate: frecuencia cardíaca del paciente en el instante en el que se recogen los datos. Se mide en pulsaciones por minuto. Se representa mediante un atributo de tipo “Integer”. ▪ date: instante de tiempo en el que fueron recabados los datos que contiene la entidad. Se trata de un atributo de tipo “String” ▪ user: nombre completo del paciente, sobre el que tratan los datos. Se representa mediante un “String”. ▪ idPatient: guarda el identificador de referencia al recurso Patient, el cual representa al paciente en el servicio FHIR. Este campo permite establecer una correspondencia entre la entidad FIWARE asociada al individuo y el recurso FHIR que lo representa. Se trata de una variable de tipo “String”. ▪ email_IoTAgent: email asociado al dispositivo IoT, que el paciente está utilizando, desde el cual se envían los datos a Orion Context Broker. Se representa mediante un atributo de tipo “String”. ▪ email_medic: email asociado al médico o cuidador, el cual se encuentra a cargo de la persona a la que representa dicha entidad. Se trata de una variable de tipo “String”. Como se ha comentado en la sección “1.3 Antecedentes”, la camiseta inteligente realiza una monitorización de la actividad física, obtiene una estimación del gasto metabólico y la frecuencia cardíaca, de ahí el origen de los atributos instant_metabolic_expenditure, accumulates_metabolic_expenditure y heart_rate. Además, se ha definido una entidad secundaria con la que poder registrar los diferentes eventos de riesgo que puedan suceder. La finalidad de este tipo de entidades es que Perseo se convierta, de forma indirecta, en una fuente de datos para Freeboard, es decir, Perseo actualizará este tipo de entidades en Orion, en el caso de que se capte un evento de interés, y dichas entidades serán leídas periódicamente por Freeboard para su representación en la interfaz visual. Este procedimiento se detallará más adelante en la sección “3.4 Visualización”. La entidad secundaria será de tipo “Alert” y su identificador será una combinación entre el DNI del paciente y el evento al que hace referencia. Se compone de dos atributos: ▪ date: fecha del momento en el que han sido obtenidos los datos que dan lugar al evento de riesgo. Se representa mediante un “String”. ▪ description: descripción de la alerta que ha tenido lugar, junto a los datos que han dado lugar a esta. Se modela mediante una variable de tipo “String”. Dentro de este tipo de entidad, durante este proyecto se hará una división, según a qué se refiera el evento de riesgo, en cinco clases de alertas: ▪ Primer tipo, relacionadas con la frecuencia cardíaca. Dentro de este tipo, se han desglosado en tres clases: • Riesgo grave (id = DNI_FrecCardiaca_RGrave). • Riesgo leve (id = DNI_FrecCardiaca_RLeve). • Tendencia a un posible riesgo (id = DNI_FrecCardiaca_Tendencia). ▪ Segundo tipo, relacionadas con el gasto calórico instantáneo (id = DNI_GastoCalInstantaneo). ▪ Tercer tipo, relacionadas con el gasto calórico acumulado (id = DNI_GastoCalAcumulado). Figura 3-7. Ejemplo de entidad de tipo “Alert” Como se ha comentado anteriormente, en este proyecto se ha empleado NGSIv2 para el tratamiento de las entidades, por lo que las entidades son creadas mediante peticiones POST a la URL en la que se encuentra el servidor OCB más “/v2/entities”. Así, como en nuestro caso el servidor se encuentra en nuestro propio ordenador, la URL sería “http://localhost:1026/v2/entities”; añadiendo el cuerpo de la entidad a crear en el BODY de dicha petición. En el caso de que quisiéramos obtener información de una entidad ya creada, bastaría un realizar una petición GET a la URL anterior añadiendo el id de la entidad que queramos obtener. En este proyecto se emplea Postman para la realización de estas operaciones. Resultados 44 Figura 3-8. Ejemplo de entidad de tipo “PhysicalActivity” 3.3.3.2 Actualización El agente IoT, para enviar la información sobre el estado del paciente, realizará peticiones PATCH a la URL en la que se encuentra el servidor, más “/v2/entities/”, seguido del id de la entidad a modificar y por último “/attrs”. En nuestro caso, teniendo en cuenta que las actualizaciones de dicho agente se simulan mediante peticiones creadas en Postman, sería “http://localhost:1026/v2/entities/[id]/attrs”. Este agente se encargará de modificar la entidad de tipo “PhysicalActivity” asociada al paciente al que pertenece en ese momento. Concretamente, actualizará los atributos instant_metabolic_expenditure, accumulates_metabolic_expenditure, date y heart_rate de dicha entidad. Figura 3-9. Actualización de una entidad de tipo “PhysicalActivity” 3.3.4 Procesador de eventos Perseo posibilita la monitorización automática de elevadas cantidades de información, mediante un razonamiento basado en reglas predefinidas que buscan detectar el cumplimiento de determinados patrones y que definen cómo actuar en cada caso. Esto se está volviendo cada vez más necesario, ya que el ámbito de la eSalud avanza en el desarrollo de nuevos dispositivos con los cuales obtener cada vez más información de los pacientes, y el número de personas que hacen uso de estas tecnologías está en continuo crecimiento. Esto se traduce en cantidades mayores de información a manejar, inviables de analizar sin llevar a cabo una monitorización automática. 3.3.4.1 Despliegue de Perseo La instalación de Perseo [45] se divide en dos partes: Perseo-FE y Perseo Core, siendo necesario que se instale en primer lugar Perseo Core. Para que ambos componentes puedan funcionar correctamente es necesario tener instalado y ejecutándose MongoDB, ya que es la base de datos donde Perseo va a almacenar todas las reglas configuradas; y Orion Context Broker, ya que es el componente que va a proveer de eventos a Perseo. Para la instalación de Perseo Core se optó por descargar la imagen estable más reciente que proporciona el repositorio Docker e instalarla en un contenedor. En la configuración es necesario indicar que el puerto externo que va a utilizar Perseo Core no va a ser el esperado por defecto, es decir, el 8080. Esto es así debido a que el puerto 8080 nos presenta un problema de ocupación, ya que es el utilizado por Apache Tomcat para desplegar el servidor FHIR, por lo que no se puede utilizar dicho puerto como puerto exterior del contenedor. Ya que la estructura de Perseo Core exige utilizar dicho puerto, primero se optó por modificar el puerto de Apache Tomcat, lo cual en principio no fue problema, pero el servidor FHIR presentaba muchas complicaciones debido a dicha modificación, así que nos decidimos finalmente por modificar Perseo Core, aplicando unas de las capacidades que nos proporciona la instalación mediante Docker. Docker permite que un contenedor tenga “asignado” dos puertos, un puerto interior, utilizado dentro de la arquitectura Docker montada en el equipo, donde el espacio de puertos es diferente al del propio ordenador; y un puerto exterior, con el cual te puedes comunicar con el servicio que proporciona el contenedor desde el exterior, teniendo que estar dicho puerto libre en el equipo. Gracias a esta funcionalidad, exteriormente se asignó a Perseo Core un puerto que se encontraba libre, en nuestro caso el 8888, mientras que internamente a la estructura Docker, Perseo Core sigue utilizando el 8080. Resultados 46 Además, en la configuración de Perseo Core hay que configurar la dirección a la que debe dirigirse para poder comunicarse con Perseo-FE. La instalación de Perseo-FE, debido a que Perseo Core se instaló mediante Docker, haciendo uso de las capacidades que esta herramienta aporta, es necesaria llevarla a cabo mediante Docker, siguiendo un procedimiento similar. Se optó por descargar la imagen estable más reciente que nos pone a disposición el repositorio Docker, y la instalamos en un contenedor. En la configuración de Perseo-FE hay que conectar dicho contenedor con los contenedores que engloban a Perseo Core, a Orion y a MongoDB, así como configurar las variables de entorno necesarias para que se pueda comunicar correctamente con estos tres componentes. Además, es necesario configurar las opciones que permiten a este componente establecer una conexión con un servidor SMTP, en nuestro caso el servidor SMTP de Gmail, a través del cual pueda realizar el envío de correo electrónicos, indicando el usuario que va a utilizar Perseo-FE para ello junto a sus credenciales. Cuando se comprobó si Perseo-FE funcionaba correctamente, nos dimos cuenta de que la solicitud de conexión con el servidor SMTP se realizaba correctamente, pero Gmail denegaba el acceso. Leyendo información sobre el protocolo que sigue Gmail para dar acceso a diversas aplicaciones, descubrimos que, debido a sus políticas de seguridad, Gmail bloqueaba el acceso a Perseo-FE, impidiendo que funcionara correctamente. Esto se solucionó configurando el correo que tiene asignado Perseo-FE, de forma que permitiera el acceso a aplicaciones, catalogadas según Gmail, como poco seguras. Conviene destacar que, debido a los problemas asociados a los puertos de Perseo Core y el servidor FHIR, para conectar Perseo-FE con el servidor FHIR, no se puede usar cómo dirección del servidor la 127.x.x.x (localhost), aun estando el servidor FHIR en el mismo equipo que Perseo, ya que Perseo-FE debe poder discriminar que se trata de un destino externo a la arquitectura Docker montada, debido a que dentro de esta arquitectura, el puerto 8080 es utilizado por Perseo Core, mientras que externamente, ese puerto se utiliza para el servidor FHIR. Esto se soluciona especificando como dirección del servidor FHIR la IP asociada al propio equipo. 3.3.4.2 Suscripciones Como se ha comentado previamente, Perseo debe recibir todas las publicaciones relacionadas con la actividad física de los diferentes pacientes para poder analizar los datos que en esas entidades se manejan. Por ello, es necesario indicar al Orion Context Broker que notifique a Perseo, todos los cambios relacionados con las entidades de tipo “PhysicalActivity” que Perseo se está encargando de gestionar. Para llevar esto a cabo, hay que crear y enviar una suscripción a Orion indicando que debe notificar a Perseo- FE sobre los cambios que se produzcan en las entidades que Perseo está monitorizando. Perseo-FE se encargará de procesar dichas notificaciones y de hacérselas llegar a Perseo Core. La dirección a la cual enviamos la suscripción será “http://localhost:1026/v2/subscriptions”, mediante una petición POST, haciendo uso de Postman para ello (Figura 3-10). Figura 3-10. Suscripción de Perseo-FE a OCB Figura 3-11. Modificación para recibir notificaciones correspondientes a entidades concretas En este caso se ha configurado la suscripción de forma que se le envíe a la misma instancia de Perseo toda la información correspondiente a modificaciones de cualquier entidad de tipo “PhysicalActivity”, haciendo uso de “idPattern”:”.*”. Mediante idPattern podemos configurar que se monitorice el cambio de entidades cuyo id se rige por un patrón. Sería posible configurar que se envíen sólo notificaciones correspondientes a una serie de entidades, en el caso de que tuviéramos varias instancias de Perseo con las que balancear la carga, o de que simplemente sólo nos interesase la información realtiva a esas entidades, modificando la sección entities, dentro del campo subject (Figura 3-11). Resultados 48 Podemos observar cómo se ha creado la suscripción de forma que cualquier cambio en los atributos de frecuencia cardíaca, gasto calórico instantáneo, acumulado o en la fecha en la que fueron obtenidos (atributos que aparecen dentro del campo condition), desencadenará una notificación hacia Perseo-FE, más concretamente hacia el path “/notices” (campo url). Conviene remarcar que, aunque Perseo se encuentre en el mismo dispositivo que Orion y sea accesible desde la dirección 127.x.x.x (localhost), no se emplea esta como dirección IP de destino en la suscripción. Esto es así porque se ha realizado el despliegue de ambos componentes mediante Docker, como podemos ver en el Anexo A (“Instalación y despliegue de los componentes FIWARE”). Por ello se asigna como dirección IP destino, la IP asignada al contenedor de Perseo-FE, para que Orion sepa que se trata de un componente perteneciente a la arquitectura Docker montada y pueda comunicarse apropiadamente con él. Mediante el campo notification, además de configurar a qué dirección vamos a enviar la notificación, como hemos comentado, configuramos qué información va a contener dicha notificación. En este caso hemos configurado que se envíen todos los atributos que forman parte de la entidad y, además, el metadato previousValue, debido a que dicha información nos hará falta en Perseo, ya sea para la detección de reglas o para construir la acción en consecuencia. Por último, se ha establecido mediante el campo expires la fecha hasta la cual queremos que dicha suscripción se mantenga activa, y mediante throttling, el tiempo que debe transcurrir, al menos, entre dos notificaciones consecutivas, en este caso 1 segundo. 3.3.4.3 Reglas Las reglas que va a manejar Perseo son enviadas, mediante Postman, a Perseo-FE, componente que se encargará de procesarlas, y, en caso de que estén bien estructuradas, de almacenarlas en MongoDB y de hacérselas llegar periódicamente a Perseo Core. El path configurado en Perseo-FE para la recepción de las reglas es “/rules”. En nuestro caso, las reglas son enviadas mediante peticiones POST a la URL “http://localhost:9090/rules”, añadiendo el contenido de la regla a crear (condición a cumplir junto con la acción o acciones resultantes de su activación) en el BODY de dicha petición. 3.4 Visualización Con el objetivo de presentar una interfaz visual que permita llevar a cabo un seguimiento remoto de la evolución del paciente, y que proporcione una representación gráfica adecuada para los distintos parámetros, se ha optado por emplear Freeboard, herramienta que nos permite definir distintas fuentes de datos desde las cuales obtener información, así como proporciona una gran variedad de widgets, los cuales se pueden adaptar perfectamente a los aspectos que representan. A continuación, se va a mostrar la configuración realizada para obtener la interfaz gráfica utilizada en este proyecto. 3.4.1 Despliegue y configuración de Freeboard Para el despliegue de Freeboard [29] se ha hecho uso de las herramientas: Git, para clonar el repositorio oficial de Freeboad en nuestro ordenador, Node.js, npm y grunt, para la instalación de Freeboard y de todas las dependencias que necesita para su correcto funcionamiento. El primer paso es obtener una copia del repositorio oficial que proporciona Freeboard en GitHub, mediante la herramienta Git. Una vez clonado el repositorio, instalamos Freeboard, junto a todas las dependencias que necesita para su correcto funcionamiento, las cuales se encuentran definidas en el archivo package.json, dentro de la carpeta obtenida con la clonación, haciendo uso del gestor de paquetes npm para ello. A continuación, empleamos grunt, herramienta que, gracias al archivo Gruntfile.js, ejecuta una lista de tareas que se especifican en dicho archivo, terminando con la instalación de Freeboard. Ya sería posible arrancar Freeboard, pero para terminar con la configuración que deseamos para el proyecto, vamos a añadir antes un nuevo tipo de widget a Freeboard mediante el mecanismo de adición de plugins que proporciona este componente. Este widget proporciona una representación gráfica de los datos con respecto al tiempo. Para ello, primero clonamos el repositorio donde se encuentra el plugin, y de la carpeta obtenida, copiamos el archivo plugin_highcharts.js a la carpeta “plugins/thirdparty”, la cual se encuentra dentro de la carpeta donde desplegamos Freeboard. Por último, editamos el archivo index.html de la carpeta de Freeboard, agregando un enlace al complemento que hemos añadido, modificando para ello head.js(). Ya podemos arrancar y utilizar Freeboard, ejecutando para ello el archivo index.html mediante un navegador web. En nuestro caso se ha usado Mozilla Firefox. Podemos comprobar como gracias al nuevo plugin tenemos un nuevo modelo de representación gráfica llamado “Time series (Highcharts)”. En un principio, con esta configuración ya pudimos poner en funcionamiento el sistema, pero Freeboard no podía comunicarse correctamente con Orion. Analizando los registros que realizaba Orion y a través del análisis del tráfico de paquetes que se generaba, mediante Wireshark, nos dimos cuenta de que Freeboard intentaba comunicarse con OCB correctamente pero este rechazaba todas sus peticiones. Analizando la documentación que nos proporciona FIWARE sobre Orion en base a la información obtenida, nos dimos cuenta de que, por defecto, Orion tiene desactivado el intercambio de recursos de origen cruzado (CORS), lo cual era el motivo por lo que Freeboard no podía comunicarse con este componente. CORS es un mecanismo que permite al servidor Orion describir el conjunto de orígenes que tienen permiso para acceder a la información que este maneja, usando un navegador web. Por ello configuramos la opción “-corsOrigin -- ALL -corsMaxAge 600” de forma que iniciamos OCB con CORS habilitado para cualquier origen, con un tiempo de caché de verificación previa máximo de 10 minutos, permitiendo que Freeboard pudiera ya comunicarse con Orion [46]. En el Anexo B (“Instalación y despliegue de Freeboard”) se expone con más detalle cómo se ha llevado a cabo la instalación de este componente. 3.4.2 Configuración de las fuentes de datos La interfaz gráfica va a necesitar tantas fuentes de datos como entidades distintas se empleen en Orion Context Broker para el manejo de la información sanitaria relacionada con el paciente. En primer lugar, se va a configurar una fuente de datos con la que poder obtener la información referente a quién es el paciente que está siendo representado en el dashboard y los datos relativos a la actividad física que está realizando. Es decir, en primer lugar, se va a configurar una fuente de datos relativa a la entidad “PhysicalActivity” correspondiente al paciente en cuestión. Para ello, desde el panel de control de Freeboard debemos añadir un nuevo datasource y cumplimentar el formulario que nos aparece. Resultados 50 Figura 3-12. Configuración fuente de datos correspondiente a la entidad “PhysicalActivity” El significado de cada campo a rellenar ha sido explicado en la subsección “2.6.1 Configuración Datasources”. Debemos remarcar la importancia de escribir correctamente la URL, ya que va a ser la dirección con la que se va a comunicar Freeboard, y la importancia de las cabeceras “Fiware-service” y “Fiware-servicepath”. Estas cabeceras deben coincidir con las establecidas en la creación de las entidades, para que la obtención de las entidades sea posible, ya que se debe indicar el ámbito donde dicha entidad es accesible. De la misma manera, el usuario de la interfaz gráfica debe ver los eventos de riesgo que se están produciendo, que Perseo ha identificado y actuado en consecuencia. Por este motivo se ha desarrollado el tipo de entidad “Alert”. Como se ha comentado previamente, los eventos de interés que, durante este proyecto, se han elaborado con Perseo, se han clasificado en cinco clases de alerta. Por ello, debemos configurar cinco fuentes de datos más, cada una referida a una clase de alerta. A continuación, podemos ver cómo se lleva a cabo la configuración de la fuente de datos correspondiente a las alertas relacionadas con la frecuencia cardíaca, clasificadas como de riesgo grave. Figura 3-13. Configuración fuente de datos correspondiente a un tipo de alertas De la misma manera, añadimos las cuatro restantes clases de alertas. Al encontrarse todas las entidades en el mismo servidor Orion y en el mismo ámbito, lo único que varía en la configuración de estos datasources es la URL a la que se refiere cada fuente de datos: ▪ Para las alertas relacionadas con la frecuencia cardíaca, clasificadas como de riesgo grave: http://127.0.0.1:1026/v2/entities/12345678N_FrecCardiaca_RGrave?options=keyValues ▪ Para las alertas relacionadas con la frecuencia cardíaca, clasificadas como de riesgo leve: http://127.0.0.1:1026/v2/entities/12345678N_FrecCardiaca_RLeve?options=keyValues ▪ Para las alertas referidas a tendencias a posibles riesgos relacionados con la frecuencia cardíaca: http://127.0.0.1:1026/v2/entities/12345678N_FrecCardiaca_Tendencia?options=keyValues ▪ Para las alertas correspondientes con el gasto calórico instantáneo: http://127.0.0.1:1026/v2/entities/12345678N_GastoCalInstantaneo?options=keyValues ▪ Por último, para los eventos relacionados con el gasto calórico acumulado: http://127.0.0.1:1026/v2/entities/12345678N_GastoCalAcumulado?options=keyValues Una vez configuradas las fuentes de datos, en el panel de control de Freeboard, además de poder ver una lista con todos los datasources añadidos, podemos comprobar si la comunicación se ha establecido correctamente, observando si la fecha de actualización asociada a la fuente de datos se modifica periódicamente, en función del periodo de refresco establecido en la configuración del datasource. Resultados 58 Figura 3-22. Actualización correspondiente a una situación de riesgo leve Figura 3-23. Email enviado a un paciente que se encuentra en una situación de riesgo leve Figura 3-24. Entidad actualizada debido a la activación de la regla “FrecCardiacaRiesgoLeve” este tipo de riesgos, la cual será empleada para la visualización en Freeboard, como vimos en la sección “3.4 Visualización”. A continuación, vamos a ver un ejemplo de actualización, la cual, por su valor de frecuencia cardíaca (137 pul/min), va a activar la regla, llevándose a cabo las acciones descritas en esta: Podemos observar en la Figura 3-23 el email que se envía desde la dirección configurada en Perseo, con destino el email configurado en la entidad FIWARE relativa al paciente. En la Figura 3-24 se muestra la actualización de la entidad de tipo “Alert” correspondiente a este paciente, para este tipo de riesgo. 3.5.1.2 Detección de situación de riesgo grave mediante la frecuencia cardíaca Es posible que la frecuencia cardíaca aumente, superando el umbral de riesgo leve común a todos los pacientes, de forma que alcance unos valores más preocupantes. En estos casos, sería conveniente que el médico responsable fuera alertado de ello, para así poder analizar su caso más en profundidad, observar más de cerca la evolución que sigue el paciente o actuar en consecuencia, si fuera necesario. Además, es interesante que estos casos queden registrados en un servicio de historia clínica para su almacenamiento persistente, de forma que se mantenga un histórico con las observaciones de los diferentes pacientes, que puedan ser de interés para la revisión por parte de profesionales sanitarios. Como dichas alertas están asociadas a un riesgo mayor y, por consecuencia, a una respuesta de mayor magnitud, es apropiado que cada regla sea individual para cada paciente, es decir, que cada paciente tenga un umbral máximo personalizado, obtenido a través de parámetros como su estado físico, edad, historial médico, etc. Para estos casos, se han definido dos situaciones en las que se consideraría que el paciente se encuentra en una situación de riesgo grave: dos muestras consecutivas por encima del umbral, o tres o más superaciones del umbral en una ventana de cinco muestras. ▪ Dos muestras consecutivas por encima del umbral (Figura 3-25). En esta regla, de nombre “FrecCardiacaRiesgoGraveConsecutivo”, se configura como condición que, si dos muestras consecutivas superan el umbral de frecuencia cardíaca, personalizado para el paciente, en este caso de 150 pul/min, se activa la regla, desencadenando una serie de acciones. Para lograr detectar esto en Perseo se ha establecido como condición en la regla que, para su activación, el valor actual de frecuencia cardiaca y el valor de la muestra justamente anterior (heart_rate__metadata__previousValue), deben ser superiores al umbral, lo que es equivalente a decir que se han obtenido dos muestras consecutivas con valor superior al umbral. Para lograr esto se ha hecho uso del metadato previousValue, el cual incorporan todos los atributos de entidades FIWARE por defecto. Además, podemos observar cómo dicha condición, al ser personalizada para cada paciente, sólo podría ser activada si el identificador de la entidad de la cual se está recibiendo datos, coincide con la establecida para dicho paciente. El conjunto de acciones que desencadena dicha regla es: • Envío de un email con destino al paciente, para alertarle sobre su estado y aconsejarle que repose. • Envío de un email con destino al médico responsable de dicho paciente, para que tenga constancia de este hecho y pueda actuar en consecuencia. • Registro de este hecho en el sistema de historia clínica FHIR, haciendo uso para ello de un recurso Observation. • Actualización de la entidad asociada al paciente para situaciones de riesgo grave. Resultados 60 Figura 3-25. Regla 1 para detectar una situación de riesgo grave a través de la frecuencia cardíaca Figura 3-28. Email enviado al médico responsable – Regla “FrecCardiacaRiesgoGraveConsecutivo” Figura 3-27. Email enviado al paciente – Regla “FrecCardiacaRiesgoGraveConsecutivo” Ahora podemos observar una situación en la cual se llevaría a cabo la activación de dicha regla, y las acciones que esto provoca (Figura 3-26): Como resultado de estas actualizaciones, es decir, de la invocación de la regla, obtendremos los correos electrónicos que se muestran en las Figuras 3-27 y 3-28, así como la creación del recurso en la historia clínica FHIR (Figura 3-29), y la actualización de la entidad asociada a este paciente para este tipo de alertas (Figura 3-32). 1º Muestra 2º Muestra Figura 3-26. Actualizaciones correspondientes a una situación de riesgo grave Resultados 62 Figura 3-29. Recurso creado por la activación de la regla “FrecCardiacaRiesgoGraveConsecutivo” El significado de los campos que conforman este recurso ha sido explicado en el apartado “2.5.1.2 Recuso Observation”. Como se ha comentado en el apartado “3.3.4.1 Despliegue de Perseo”, la dirección destino de la petición de creación del recurso, aún estando el servidor FHIR en el mismo equipo que Perseo, no puede ser 127.x.x.x (localhost), ya que Perseo-FE debe poder discriminar que se trata de un destino externo a la arquitectura Docker montada, ya que dentro de esta arquitectura el puerto 8080 es utilizado por Perseo Core, mientras que externamente, ese puerto se utiliza para el servidor FHIR. Podemos ver cómo dicho recurso se engloba en la categoría de observaciones relacionadas con signos vitales (vital-signs), especificando que son datos relativos a la frecuencia cardíaca (código 8867-4 del estándar LOINC). También se puede observar cómo en dicho recurso hay una referencia al recurso tipo Patient que contiene toda la información relativa a “quién” es el paciente, al cual corresponde dicha información. Por último, contiene una descripción sobre lo ocurrido, junto con los valores que avalan a dicha alarma. Realizar la configuración de los recursos Observation de esta forma nos permitirá tener un registro más ordenado en el servidor FHIR, de forma que podamos hacer en el futuro consultas más complejas en este. Por ejemplo, gracias a los campos configurados en dicho recurso, podemos realizar consultas que permitan obtener los recursos Observation relativos a un determinado paciente, o que tratan de un cierto aspecto, como el gasto calórico acumulado, o que fueron registrados a partir de cierta fecha. A continuación, podemos observar un ejemplo donde se opta por obtener los registros de un determinado paciente, cuyo identificador es 105, relacionados con la frecuencia cardíaca, de ahí el code introducido, y que han sido registrados a partir del 24-05-2020 (Figura 3-30). Figura 3-32. Entidad actualizada por la activación de la regla “FrecCardiacaRiesgoGraveConsecutivo” Figura 3-30. Consulta realizada en el servidor FHIR Figura 3-31. Resultado de la consulta en el servidor FHIR En la Figura 3-31 se puede ver cómo el servidor también permite incluir en la búsqueda, los elementos que aparezcan referenciados dentros de los recursos Observation que se obtienen como resultado. En este caso, hemos seleccionado que aparezca el recurso Patient que corresponde a dicho paciente. Resultados 64 Figura 3-33. Regla 2 para detectar una situación de riesgo grave a través de la frecuencia cardíaca ▪ Tres o más superaciones del umbral en una ventana de cinco muestras: Para poder detectar si en un conjunto de cinco muestras, tres o más superan el umbral personalizado del paciente, se ha elaborado una regla, de nombre “FrecCardiacaRiesgoGraveVentana”, la cual crea una ventana deslizante, de tamaño 5, de muestras de la entidad identificada para dicho paciente, en la que según van llegando nuevas muestras de dicha entidad, van saliendo las más antiguas, siempre manteniendo cinco muestras en la ventana (“(id = \”12345678N\”).win:length(5)”). Cada vez que se introduce una nueva muestra, esta regla comprueba para cuántas muestras del conjunto, el valor de la frecuencia cardíaca es superior al umbral establecido, y si el número de muestras que lo cumple es superior a dos (tres o más), se llevan a cabo las acciones que en ella se describen. A continuación, podemos ver un ejemplo donde se activaría la regla, ya que tenemos tres muestras con un valor de frecuencia cardíaca superior al umbral (muestras 1, 3 y 5), dentro de la ventana (Figura 3-34). Resultados 66 Las acciones que realiza son similares a las de la anterior regla, pero variando la descripción que estas acciones contienen. 1º Muestra 2º Muestra 3º Muestra 4º Muestra 5º Muestra Figura 3-34. Serie de actualizaciones correspondientes a una situación de riesgo grave Figura 3-35. Email enviado al paciente – Regla “FrecCardiacaRiesgoGraveVentana” Figura 3-36. Email enviado al médico responsable – Regla “FrecCardiacaRiesgoGraveVentana” Figura 3-37. Recurso creado por la activación de la regla “FrecCardiacaRiesgoGraveVentana” Podemos ver cómo, al ser tanto la regla anterior como esta, dos reglas cuyo objetivo es detectar la misma situación de riesgo, la entidad que actualizan cuando se activan es la misma en ambos casos, entidad destinada a mantener información sobre una situación de riesgo grave relacionado con la frecuencia cardíaca. Resultados 74 Figura 3-48. Regla para la monitorización diaria del gasto calórico acumulado Por ello, esta regla, específica para cada usuario debido a que el objetivo es personalizado a este, se activa cuando el valor obtenido de gasto calórico acumulado es inferior al de la anterior muestra. Esto, al ser un campo en incremento constante, sólo ocurre cuando ha finalizado el día y por tanto se ha puesto a 0 dicho campo. Así, cada día, gracias a esta regla se crea un recurso FHIR con el gasto calórico generado e información sobre si el paciente ha cumplido, o no, con su objetivo particular. Además, se le envía un email al paciente indicándole esta información, y se actualiza la entidad asociada a este tipo de eventos. Mediante una estructura de control, if-else, se determina si el paciente ha cumplido su objetivo diario, o, por el contrario, no ha llegado a alcanzar dicho objetivo. En la Figura 3-49 podemos ver una secuencia de actualizaciones correspondientes a la última muestra de un día y a la primera muestra del día siguiente. Figura 3-51. Recurso Observation creado por la activación de la regla “GastoCaloricoAcumulado” Figura 3-50. Email enviado al paciente para notificarle que no ha cumplido su objetivo diario de kcal Como resultado de dichas actualizaciones, obtendríamos los resultados de las Figuras 3-50 y 3-51. Figura 3-49 Actualizaciones que darían lugar a la activación de la regla “GastoCaloricoAcumulado” 1º Muestra 2º Muestra Resultados 76 Figura 3-52. Entidad actualizada debido a la activación de la regla “GastoCaloricoAcumulado” Figura 3-53. Regla para detectar comportamiento anómalo en un dispositivo En el recurso creado, podemos ver cómo, además de indicar el gasto calórico generado por el paciente, contiene una descripción sobre si ha cumplido su objetivo diario o no, y cual es el valor de ese objetivo. Como en los casos anteriores, es englobado en la categoría relativa a signos vitales (vital-signs), pero se especifica que contiene datos referentes al gasto calórico acumulado (código 41979-6 del estándar LOINC). En el caso de que el usuario hubiera cumplido con su meta diaria de kilocalorías, los resultados habrían sido similares, pero indicando que sí se ha cumplido dicho objetivo diario. 3.5.1.6 Detección de comportamiento anómalo en el dispositivo Como todo sistema electrónico, el dispositivo puede llegar a deteriorarse o a comportarse de manera errónea, llegando a poder enviar valores anómalos al sistema, como por ejemplo un valor para la frecuencia cardíaca de “9cX” pulsaciones por minuto. Es conveniente que el propio sistema detecte automáticamente cuando se está produciendo un mal funcionamiento por parte de uno de los dispositivos e informe tanto al usuario que está haciendo uso de este, como a un servicio técnico, para que se solucione este problema lo antes posible. Figura 3-54. Actualizaciones con valores anómalos Figura 3-55. Email enviado al paciente para informar sobre errores en el dispositivo Perseo no permite evaluar de forma directa si los valores de los campos se corresponden con los tipos esperados, pero permite comprobar si dichos valores se rigen por un patrón. Por ello, se ha desarrollado la regla “EvaluaCampos”, la cual comprueba si el valor obtenido de frecuencia cardíaca está compuesto sólo por números, y si los campos de gasto calórico instantáneo y acumulado están compuestos sólo por números, con al menos un decimal. A continuación, podemos ver algunos ejemplos de actualizaciones que contienen valores anómalos y, por tanto, activarían dicha regla. Esta regla al activarse notifica al paciente de que el dispositivo está fallando, recomendándole que de momento deje de utilizarlo, y avisa a un servicio técnico, para que sea consciente de esto y pueda ponerse en contacto con el paciente para realizar la correspondiente reparación, si es posible. Resultados 78 Figura 3-56. Email enviado al servicio técnico para informar sobre fallos en un dispositivo 4 CONCLUSIONES Y LÍNEAS FUTURAS n este capítulo se van a tratar los principales aspectos que nos ha aportado la realización de este proyecto, así como se va a analizar lo aprendido para llevarlo a cabo y el resultado final obtenido. También, se van a analizar diferentes líneas futuras de desarrollo, las cuales ampliarían las funcionalidades de este proyecto o mejorarían algunos aspectos relacionados con este. 4.1 Conclusiones La solución desarrollada permite disponer de un sistema capaz de obtener información de la actividad física que está realizando un paciente y ponerla a disposición de otros componentes, mediante Orion Context Broker, lo que permite que Perseo lleve a cabo una supervisión en tiempo real de dicha información y pueda actuar en consecuencia según unas reglas preestablecidas. Gracias a las múltiples opciones que ofrece Perseo y el lenguaje EPL, lenguaje que aplica Perseo para la definición de las reglas, se pueden llevar a cabo todo tipo de casos de usos, con gran variedad de patrones y acciones en consecuencia. Además, debemos destacar que el potencial de estas herramientas permite procesar grandes cantidades de datos en tiempo real, requisito indispensable dentro del entorno sanitario, donde se manejan cantidades masivas de datos. Con respecto a Freeboard, proporciona una interfaz visual que facilita el seguimiento remoto del tratamiento en un determinado paciente, de forma que tenemos accesible dicha información en cualquier momento de forma sencilla. Esto lo realiza a través de una representación que se adapta a los parámetros que están siendo modelados, lo cual permite una visualización más adecuada, facilitando el obtener conclusiones a partir de los datos recolectados. Una de las grandes ventajas de esta solución es que, al haber aplicado herramientas de la plataforma FIWARE, hereda en cierto modo el carácter general que posee dicha plataforma, lo que permite que el sistema desarrollado pueda ser aplicado en cualquier otro tipo de escenario. Para lograr esto sólo habría que definir nuevos modelos de datos para la información de contexto que se aplica en dicho escenario, llevar a cabo la suscripción de Perseo a la información que va a manejar, y configurar el dashboard en Freeboard, de forma que pueda obtener los datos de interés y llevar a cabo su representación de la forma más adecuada. Además, se deberían configurar en Perseo las reglas que van a marcar la detección de eventos de interés, junto con las acciones asociadas a dichas reglas. E La imaginación es más importante que el conocimiento. Mientras que el conocimiento es limitado, la imaginación abarca el mundo entero, estimulando el progreso, dando a luz a la evolución. - Albert Einstein - Conclusiones y líneas futuras 80 La realización de este proyecto me ha servido para adquirir conocimientos sobre tecnologías que aún no conocía, así como para poner en práctica algunos conceptos adquiridos durante la carrera. He aprendido más sobre IoT y esto me ha llevado a indagar a fondo en FIWARE, una plataforma muy potente, que pone a nuestra disposición gran cantidad de componentes con diversas funcionalidades, fácilmente ensamblables, facilitando el desarrollo de soluciones que hacen uso de IoT, Cloud Computing o Big Data, entre otras cosas. Además, proporciona una amplia documentación sobre cada herramienta, permitiendo aprender sobre ellas rápidamente y de manera guiada. Esto me condujo a estudiar en profundidad el estándar NGSI, más en concreto, NGSIv2. En este estándar se basa la comunicación entre los diferentes componentes FIWARE. Se ha hecho hincapié en los conceptos de entidad, suscripción y notificación, conceptos en los que se basa Orion Context Broker, pieza fundamental en este proyecto. A su vez, el despliegue de los componentes de FIWARE me ha llevado a aprender más sobre Docker, una tecnología sobre la que había oído hablar, pero con la que no había trabajado antes. Docker es una tecnología cada vez más en auge, que permite el despliegue de componentes de forma mucho más simple y rápida, la cual me ha permitido montar el sistema de forma más sencilla, evitando problemas con las dependencias de cada componente. El trabajar con Perseo me llevó a investigar más profundamente sobre el procesamiento de eventos en tiempo real, y en cómo se llevan a cabo, conduciéndome a aprender sobre Esper, motor en el que se basa el procesamiento que se realiza en Perseo. Además, descubriéndome el lenguaje EPL, un lenguaje en parte similar a SQL, pero con muchas peculiaridades, para la definición de las reglas que nos permitirán la identificación de los eventos significativos. De la misma manera, conocer e indagar en el estándar FHIR me ha permitido dar unos primeros pasos en el ámbito de la eSalud, un ámbito que tiene un gran potencial en el futuro, ya que permitirá mejorar la eficacia del sistema sanitario, ahorrando costes y añadiendo mejores procedimientos en este sector. Este trabajo me ha servido para darme cuenta de la importancia de estar siempre en continua formación, ya que en el día a día van surgiendo proyectos que requieren de nuevas tecnologías, la cuales hay que aprender si se quiere poder llevar a cabo este. Por último, este proyecto ha sido una manera de reflejar algunos de los aspectos desarrollados durante estos años de carrera, no relacionados directamente con las Telecomunicaciones. Como por ejemplo la capacidad para planificar tareas de gran volumen a largo plazo, el ser constante, la capacidad para ser autodidacta y otros muchos, pero el más importante en mi opinión, la habilidad para obtener soluciones para los problemas que van surgiendo. 4.2 Líneas futuras En cuanto a posibles mejoras para este proyecto, con el objetivo de llevar su implementación a un entorno real, sería necesario dotar al sistema de mecanismos de seguridad, ya que se está haciendo uso de información sanitaria de diferentes pacientes, es decir, se trata de información “sensible”. En la situación actual, cualquier persona puede enviar peticiones a Orion Context Broker, pudiendo consultar datos para los cuales no debería tener acceso o, aún peor, pudiendo modificar los valores a su interés. Por ello es necesario la implementación de mecanismos que garanticen la autenticación de los usuarios, tanto de los que acceden para consultar información, como de los que realizan el envío de datos. Además, sería necesario realizar un cifrado de las comunicaciones para evitar que intermediarios no autorizados puedan obtenerla. El fin de estas mejoras es proveer al sistema de integridad, autenticidad, confidencialidad y disponibilidad de sus datos. El mismo caso ocurre con Perseo. En la actualidad, cualquier usuario puede crear reglas y acciones asociadas a ellas, que le permitan acceder a cierta información que, por su carácter confidencial, no deberían tener acceso, e incluso le permitan modificarlas. 81 Procesador de eventos en entorno IoT de FIWARE para la supervisión remota de la actividad física Algunos Generic Enablers de la plataforma FIWARE proporcionan ciertas funcionalidades para solucionar esto. Por ejemplo, AuthZForce proporciona una API para llevar a cabo decisiones de autorización basadas en unas políticas y en peticiones de autorización procedentes de PEPs, o Keyrock, que permite administrar la autenticación de usuarios y dispositivos, gestionar los perfiles de los usuarios registrados y preservar la privacidad de los datos sensibles. Por otra parte, otro aspecto interesante habría sido el desarrollo de una interfaz gráfica para el desarrollo de las reglas y de las acciones desencadenadas por el cumplimiento de estas. Es decir, el desarrollo de una interfaz visual que permita al personal autorizado crear diferentes reglas y acciones de forma más sencilla, sin necesidad de tener que manejar EPL, con las variantes que incluye Perseo. EPL puede ser un lenguaje un poco complejo al principio, que se puede llegar a comportar de manera inesperada si no se tienen los conocimientos suficientes. Con respecto al servicio FHIR, se ha empleado sólo una pequeña parte de los recursos y funcionalidades que dicho estándar ofrece. Sería buena idea en el futuro incluir más recursos para dotar al sistema de mayor volumen de información a manejar. Por ejemplo, recursos para poder hacer referencia al dispositivo utilizado por el paciente, para poder seguir el plan de cuidados que se le ha sido asignado, o para poder identificar al personal sanitario que se encuentra a cargo de él. Conclusiones y líneas futuras 82 83 Procesador de eventos en entorno IoT de FIWARE para la supervisión remota de la actividad física ANEXO A: INSTALACIÓN Y DESPLIEGUE DE LOS COMPONENTES FIWARE n este anexo se explica cómo instalar y desplegar, Orion Context Broker y Perseo, haciendo uso para ello de la tecnología Docker, por lo que habrá que realizar su instalación previamente. Mediante esta tecnología también se instalará MongoDB, base de datos necesaria para el correcto funcionamiento tanto de Orion como de Perseo. Debemos destacar que estos pasos se llevan a cabo en el sistema operativo Ubuntu, en particular en Ubuntu 18.04.4 LTS, con kernel Linux 4.15.0-96-generic. A.1 Instalación de Docker La instalación de Docker [42] se ha llevado a cabo usando el repositorio de Ubuntu, siguiendo los siguientes pasos: 1. Actualizar el sistema de gestión de paquetes apt: $ sudo apt-get update 2. Instalar los paquetes necesarios para permitir que apt pueda acceder a un repositorio a través de HTTPS: $ sudo apt-get install \ apt-transport-https \ ca-certificates \ curl \ gnupg-agent \ software-properties-common 3. Agregar la clave GPG oficial de Docker: $ curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add - E Anexo A: Instalación y despliegue de los componentes fiware 90 6. Podemos ver los logs que está creando Perseo durante su funcionamiento: $ sudo docker logs perseo_core $ sudo docker logs perseo_fe 91 Procesador de eventos en entorno IoT de FIWARE para la supervisión remota de la actividad física ANEXO B: INSTALACIÓN Y DESPLIEGUE DE FREEBOARD n este anexo se explica cómo instalar y desplegar Freeboard de forma local, para poder utilizarlo sin necesidad de usar el servicio web que el propio Freeboard ofrece, el cual requiere de una suscripción de pago para obtener algunas funcionalidades. También se expone cómo llevar a cabo la instalación de plugins en Freeboard, lo cual permite aumentar sus funcionalidades, incluso aportando nuevas funcionalidades hechas por los propios usuarios. En este caso, se va a añadir un nuevo tipo de representación, un nuevo tipo de widget, mediante este método. Conviene remarcar que estos pasos se llevan a cabo en el sistema operativo Ubuntu, en particular en Ubuntu 18.04.4 LTS, con kernel Linux 4.15.0-96-generic. B.1 Instalación de Freeboard El despliegue de Freeboard [29] se ha realizado siguiendo estos pasos: 1. Instalamos la versión más reciente de Git, Node.js y npm, haciendo uso del repositorio de Ubuntu. Además, es necesario llevar a cabo la instalación grunt: $ sudo apt-get install git $ sudo apt-get install nodejs $ sudo apt-get install npm $ sudo npm install -g grunt 2. Clonamos el repositorio oficial de Freeboard en nuestro ordenador: $ git clone https://github.com/Freeboard/freeboard.git 3. Nos movemos dentro de la carpeta que se ha creado con el comando anterior: $ cd freeboard E Anexo B: Instalación y despliegue de Freeboard 92 Figura B-1. Pantalla de inicio de Freeboard 4. Instalamos todas las dependencias que necesita Freeboard para su correcto funcionamiento, la cuales se encuentran definidas en el archivo package.json: $ npm install 5. Ejecutamos todas las tareas especificadas en Gruntfile.js: $ grunt 6. Ya sería posible arrancar y utilizar Freeboard. Para ello se ejecuta el archivo index.html, haciendo uso de un navegador web. En nuestro caso, hemos usado Mozilla Firefox. Ahora vamos a añadir un nuevo plugin a Freeboard, el cual nos proporciona una representación gráfica de los datos con respecto al tiempo. Para ello, realizamos lo siguiente: 1. Clonamos el repositorio donde se encuentra el plugin: $ git clone https://github.com/onlinux/freeboard-dynamic-highcharts-plugin 2. Copiamos el archivo plugin_highcharts.js del repositorio clonado, a la carpeta “plugins/thirdparty”, la cual se encuentra dentro de la carpeta donde desplegamos Freeboard: $ cp /freeboard-dynamic-highcharts-plugin/plugin_highcharts.js /freeboard/plugins/thirdparty 93 Procesador de eventos en entorno IoT de FIWARE para la supervisión remota de la actividad física 3. Editamos el archivo index.html de la carpeta donde desplegamos Freeboard, agregando un enlace al complemento, usando para ello head.js(): head.js( 'js/freeboard_plugins.min.js', 'plugins/thirdparty/plugin_highcharts.js', $(function() { //DOM Ready freeboard.initialize(true); }) Ya podríamos arrancar Freeboard y comprobar cómo, efectivamente, tenemos un nuevo tipo de widget, con el que llevar a cabo un nuevo modelo de representación gráfica. Figura B-2. Agregación de un plugin a Freeboard Anexo B: Instalación y despliegue de Freeboard 94 Figura B-3. Visualización del nuevo plugin en Freeboard 95 Procesador de eventos en entorno IoT de FIWARE para la supervisión remota de la actividad física ANEXO C: INSTALACIÓN Y DESPLIEGUE DEL SERVIDOR FHIR n este anexo se explica cómo instalar y desplegar un servidor FHIR, utilizando para ello HAPI FHIR JPA [40]. Para poder desplegarlo, previamente necesitamos tener instalado un contenedor web compatible con Servlet 3.0+. En este caso, se ha decidido por utilizar Apache Tomcat debido a que es la principal recomendación por la propia página de HAPI FHIR. Conviene comentar que estos pasos se llevan a cabo en el sistema operativo Ubuntu, en particular en Ubuntu 18.04.4 LTS, con kernel Linux 4.15.0-96-generic. C.1 Instalación de Apache Tomcat Para poder llevar a cabo la instalación del servidor FHIR, previamente vamos a llevar a cabo la instalación de Apache Tomcat en nuestro equipo [41], mediante los siguientes pasos: 1. Instalamos el paquete OpenJDK, el cual también es necesario para la instalación del propio servicio FHIR: $ sudo apt-get install default-jdk 2. Por motivos de seguridad, Tomcat debería ejecutarse como un usurio sin privilegios. Por ello, a continuación, creamos un nuevo usuario y grupo de sistema con el directorio de inicio en “/opt/tomcat”, que ejecutará el servicio de Tomcat: $ sudo useradd -m -U -d /opt/tomcat -s /bin/false tomcat Se aplica un shell “/bin/false” para que nadie pueda iniciar sesión con dicha cuenta. E Anexo C: Instalación y despliegue del servidor FHIR 96 3. Descargamos la versión de Tomcat que deseamos, en este caso la versión 9.0.34, desde su página oficial. Para ello, nos movemos al directorio “/tmp” y descargamos el archivo zip mediante wget. Una vez completada la descarga, extraemos el archivo zip y lo movemos al directorio “/opt/tomcat”: $ sudo apt-get install wget $ sudo apt-get install unzip $ cd /tmp $ wget http://apache.uvigo.es/tomcat/tomcat-9/v9.0.34/bin/apache-tomcat-9.0.34.zip $ unzip apache-tomcat-9.0.34.zip $ sudo mv apache-tomcat-9.0.34 /opt/tomcat/ Los dos primeros comandos se pueden omitir en caso de que estas herramientas ya se encuentren instaladas en el sistema. 4. El usuario que creamos anteriormente necesita tener acceso al directorio de Tomcat, por lo que cambiamos el propietario de dicho directorio: $ sudo chown -R tomcat: /opt/tomcat 5. Por último, hacemos que los scripts que se encuentra dentro del directorio bin sean ejecutables para nuestro usuario: $ sudo chmod +x /opt/tomcat/apache-tomcat-9.0.34/bin/*.sh 6. Ya estaría listo Tomcat. Para inciar el servidor solo habría que ejecutar el siguiente comando, el cual nos mostrará “Tomcat started” en caso de que se haya iniciado correctamente: $ /opt/tomcat/apache-tomcat-9.0.34/bin/startup.sh Podemos comprobar como realmente está funcionando, simplemente abriendo un navegador y accediento a la URL “http://localhost:8080/”. Si todo funciona de manera adecuada, nos aparecerá la página de inicio de Tomcat. 97 Procesador de eventos en entorno IoT de FIWARE para la supervisión remota de la actividad física Figura C-1. Página de inicio de Tomcat En el caso de que quisiéramos apagar el servidor, solo sería necesario ejecutar: $ /opt/tomcat/apache-tomcat-9.0.34/bin/shutdown.sh C.2 Instalación del servidor FHIR Como se ha indicado anteriormente, para la instalación y despliegue del servidor FHIR es necesario que previamente se haya realizado la instalación descrita en el punto anterior, de Apache Tomcat. Para instalar el servidor FHIR hemos seguido los pasos descritos a continuación: 1. Instalamos la versión más reciente de Git y de Apache Maven, haciendo uso del repositorio de Ubuntu. $ sudo apt-get install git $ sudo apt-get install maven También sería necesario tener instalado el Oracle Java (JDK), versión 8 como mínimo. Pero como previamente hemos instalado Apache Tomcat, ya contamos con esto. 2. Clonamos el proyecto de HAPI FHIR desde la página de Github a nuestro ordenador: $ git clone https://github.com/hapifhir/hapi-fhir-jpaserver-starter Anexo C: Instalación y despliegue del servidor FHIR 98 Figura C-2. Pantalla de inicio del servidor FHIR 3. Nos deplazamos hasta el directorio creado mediante el comando anterior, y dentro de este, creamos un archivo WAR que contiene la aplicación del servidor FHIR: $ cd hapi-fhir-jpaserver-starter $ mvn clean install Este comando generará un archivo con el nombre “hapi-fhir-jpaserver.war”, dentro del directorio “target”, el cual se encuentra dentro del directorio desde el cual hemos ejecutado dicho comando. 4. Por último, movemos el archivo “hapi-fhir-jpaserver.war” generado, al directorio “webapps”, situado dentro del directorio donde se encuentra Tomcat instalado: $ mv target/hapi-fhir-jpaserver.war /opt/tomcat/apache-tomcat-9.0.34/webapps Al ejecutarse Apache Tomcat, se generará la carpeta “hapi-fhir-jpaserver” dentro de la carpeta donde se encuentra este archivo WAR y podremos acceder desde un navegador a la dirección “http://localhost:8080/hapi-fhir-jpaserver/”. Así podemos comprobar como el servidor FHIR se encuentra en funcionamiento. REFERENCIAS [1] Ministerio de Sanidad, Consumo y Bienestar Social, «Actividad Física y Salud» https://www.mscbs.gob.es/ciudadanos/proteccionSalud/adolescencia/beneficios.htm [2] World Health Organization, «Global Health Risks. Mortality and burden of disease attributable to selected major risks» https://www.who.int/healthinfo/global_burden_disease/GlobalHealthRisks_report_full.pdf [3] Rafael Díaz Fernández, «Agente IoT de FIWARE para el control de un dispositivo de monitorización de actividad física». Escuela Técnica Superior de Ingeniería, Universidad de Sevilla, 2019 [4] Página oficial de la plataforma FIWARE, «Welcome to Orion Context Broker» https://fiwareorion.readthedocs.io/en/master/ [5] FIWARE - IOT - Stack, «Complex Event Processing (Perseo)» https://thinkingcities.readthedocs.io/en/release-v4.0/cep/index.html [6] Página oficial de HL7, «FHIR - RESTful API» https://www.hl7.org/fhir/http.html [7] Página oficial de Freeboard http://freeboard.io/ [8] NTS Solutions, «¿Qué es el Internet de las Cosas (IoT)?» https://www.nts-solutions.com/blog/que-es- iot.html [9] Statista, «Internet of Things - number of connected devices worldwide 2015-2020» https://www.statista.com/statistics/471264/iot-number-of-connected-devices-worldwide/ [10] Sergio García Gómez, Juan José Hierro, Luis Muñoz, Leonor Rodríguez Catalán, Gregorio Ambrosio, Andreu Ibáñez, Paula Llobet, «Fiware: Una plataforma abierta y estándar para Ciudades Inteligentes» https://www.esmartcity.es/comunicaciones/i-congreso-ciudades-inteligentes-fiware [11] Página oficial de FIWARE, «What is FIWARE?» https://www.fiware.org/developers/ [12] José Manuel Cantera Fonseca, Fermín Galán Márquez, Tobias Jacobs, «FIWARE - NGSIv2 Specification» https://fiware.github.io/specifications/ngsiv2/stable/ [13] Página oficial de FIWARE, «Orion Context Broker (OCB)» https://fiwaretraining.readthedocs.io/es_MX/latest/ecosistemaFIWARE/ocb/ [14] Página oficial de FIWARE, « Perseo Context - aware CEP» https://perseo.readthedocs.io/en/latest/ [15] Irene Sánchez Martín, «Herramienta Web para el modelado de consultas CEP (Complex Event Processing)». Escuela Técnica Superior de Ingeniería de Sistemas Informáticos, Universidad Politécnica de Madrid, 2015 http://oa.upm.es/39255/3/TFG_%20Irene_%20Sanchez_Martin.pdf [16] EsperTech, «Esper» http://www.espertech.com/esper/ [17] Página oficial de FIWARE, « Perseo Context - aware CEP - Plain rules» https://perseo.readthedocs.io/en/latest/API/plain_rules/ [18] Página oficial de MongoDB, «What is MongoDB?» https://www.mongodb.com/what-is-mongodb [19] GitHub, «Orion Context Broker» https://github.com/telefonicaid/fiware-orion/ [20] Página oficial de FIWARE, «Perseo Context - aware Complex Event Processing - Architecture» https://perseo.readthedocs.io/en/latest/architecture/architecture/ [21] Gustavo Caramelo «Historia clínica» http://www.salud.gob.ar/dels/entradas/historia-clinica [22] Página oficial de HL7, «FHIR» https://www.hl7.org/fhir/