Proyecto Fin de Grado
Grado en Ingeniería de las Tecnologías de Telecomunicación
Demostrador para el desarrollo de un sistema
distribuido de gestión de alarmas sanitarias sobre el servicio de distribución de datos (DDS)
Autor: José María Roldán Gil Tutor: Isabel Román Martínez
Departamento de Ingenería Telemática Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2014
Proyecto Fin de Grado
Grado en Ingeniería de las Tecnologías de Telecomunicación
Demostrador para el desarrollo de un sistema distribuido de gestión de alarmas sanitarias sobre el
servicio de distribución de datos (DDS)
Autor:
José María Roldán Gil
Tutor:
Isabel Román Martínez Profesora colaboradora
Dep. De Ingeniería Telemática Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2014
Proyecto Fin de Carrera: Demostrador para el desarrollo de un sistema distribuido de gestión de alarmas sanitarias sobre el servicio de distribución de datos (DDS)
Autor: José María Roldán Gil Tutor: Isabel Román Martínez
El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:
Presidente:
Vocales:
Secretario:
Acuerdan otorgarle la calificación de:
Sevilla, 2014
El Secretario del Tribunal
A mis padres, familia y amigos
vii
Agradecimientos
Con este proyecto pongo fin a mis primeros cuatro años en la Universidad de Sevilla. Siempre estaré agradecido a mis padres, por haberme enseñado a esforzarme para conseguir mis retos, lo que ha hecho que haya llegado a conseguir los logros que en mis años de vida he tenido, y por su apoyo todos los días. También a toda mi familia, en especial a mi tito Rafael que siempre quiso que yo estudiara Telecomunicaciones, y a mis amigos, tanto de Córdoba como de Sevilla.
Los profesores también han puesto de su parte en mi formación en la Escuela Superior de Ingeniería de Sevilla. En especial agradecer toda la ayuda que me ha dado Isabel Román, tutora de este proyecto, así como a Jorge Calvillo por todas las dudas resueltas.
José María Roldán Gil
2014
Resumen
En este proyecto se ha realizado un análisis de las posiblidades de utilizar el patrón de sistemas distribuidos publicador/suscriptor, destacable por la escalabilidad y la independencia entre los publicadores (emisores) y los suscriptores de información (receptores), para dar soporte a un sistema de monitorización remota de pacientes y gestión de alarmas sanitarias. Por otro lado se ha desarrollado un demostrador utilizando el estándar Data Distribution Service, que sigue este patrón y define una middleware base sobre la que construir el sistema. Esta middleware facilita las comunicaciones entre los nodos del sistema ocultando al programador gran parte de la complejidad inherente a la distribución.
En primer lugar se ha hecho un estudio de qué alarmas son útiles para el personal sanitario y cómo implementarlas utilizando esta tecnología, analizando qué facilidades aportan los mecanismos de suscripción y filtrado. De este modo una alarma tipo se define con una conjunción de suscripción más filtrado y/o procesado (cuando sea necesario). Así cada suscriptor puede personalizar las alarmas que desea recibir configurando sus suscripciones y estableciendo filtros sobre la información publicada. Como demostrador, se ha desarrollado una aplicación suscriptora que facilita la definición de la mayoría de alarmas identificadas en el estudio previo.
El usuario, a través de una interfaz gráfica de prueba, podrá seleccionar la información en la que esté interesado y establecer alarmas sobre ella, creándose y registrándose en la middleware el suscriptor necesario para recibirlas.
De este modo en un despliegue real se publicarán datos de monitorización desde los dispositivos adecuados y
por otro lado los actores interesados en la gestión de algún tipo de alarmas definirán las características de estas
alarmas a través de una GUI y se crearán, configurarán y ejecutarán los suscriptores adecuados para detectar
estas alarmas y lanzar los protocolos de actuación adecuados.
ix
Índice
Agradecimientos vii
Resumen viii
Índice ix
Índice de Tablas xi
Índice de Figuras xiii
Notación xv
1 Introducción 1
1.1 Motivación 1
1.2 Objetivo 1
1.3 Metodología 2
2 Metodología 3
2.1 Patrón Publicador/Suscriptor 3
2.2 Data Distribution Service 3
2.2.1 Especificación DDS 4
2.3 RTI DDS 10
3 Resultados 13
3.1 Análisis de DDS y RTI DDS. 13
3.2 Caso práctico de alarmas sanitarias 14
3.2.1 Taxonomía de alarmas sanitarias 14
3.2.2 Base del software 15
3.2.3 Especificación de requisitos 16
3.2.4 Diseño de la solución para el suscriptor de alarmas 27
3.2.5 Otros aspectos de la solución 33
4 Conclusiones 36
4.1 Conclusiones 36
4.2 Líneas futuras 36
Referencias 39
Anexo A: Javadoc API 41
xi
Í NDICE DE T ABLAS
Tabla 3-1: taxonomía de alarmas 15
Tabla 3-2: capas del sistema de alarmas 15
Tabla 3-3: Req01 Desarrollo de Alarma Umbral 17
Tabla 3-4: Req02 Desarrollo de Alarma Rango 17
Tabla 3-5: Req03 Desarrollo Alarma Memoria 17
Tabla 3-6: Req04 Desarrollo alarma Personalizada 18
Tabla 3-7: Req05 Alarma Persistencia 18
Tabla 3-8: Req06 Alarma Error 18
Tabla 3-9: Req07 Información de monitorización 19
Tabla 3-10: Req08 Mensaje de Alerta 19
xiii
Í NDICE DE F IGURAS
Ilustración 2-1: primeros conceptos de DDS 4
Ilustración 2-2: modelo servidor/cliente frente a DDS 4
Ilustración 2-3: Infraestructure Module 5
Ilustración 2-4: Domain Module 6
Ilustración 2-5: TopicDefinition Module 7
Ilustración 2-6: Publication Module 8
Ilustración 2-7Suscription Module 9
Ilustración 2-8: vista general de las clases 10
Ilustración 3-1: Diagrama de Casos de Uso 20
Ilustración 3-2: Paciente 20
Ilustración 3-3: Personal Sanitario 21
Ilustración 3-4: Técnico 21
Ilustración 3-5: Registrar usuario en el sistema. 21
Ilustración 3-6: Acceso al sistema. 22
Ilustración 3-7: Arrancar el sistema. 22
Ilustración 3-8: Establecer Alarma Error. 23
Ilustración 3-9: Establecer Alarma Ayuda. 23
Ilustración 3-10: Establecer Alarma Umbral. 24
Ilustración 3-11: Establecer Alarma Personalizada. 24
Ilustración 3-12: Establecer Alarma Persitencia. 24
Ilustración 3-13: Iniciar Lectura de datos. 25
Ilustración 3-14: Información permanente de pacientes. 25
Ilustración 3-15: Fiabilidad. 26
Ilustración 3-16: Usabilidad. 26
Ilustración 3-17: mantenibilidad. 27
Ilustración 3-18: seguridad. 27
Ilustración 3-19: diagrama de paquetes. 27
Ilustración 3-20: diagrama de clases del paquete aplicación. 28
Ilustración 3-21: diagrama de clases del paquete alarmas. 29
Ilustración 3-22: diagrama de clases del paquete listeners. 30
Ilustración 3-23: secuencia del método on_data_available en las clases ListenerXXXX 31 Ilustración 3-24: secuencia del método on_data_available en las clases ListenerMemoriaXXXX 31
Ilustración 3-25: diagrama de clases del paquete topics. 32
Ilustración 3-26: despliegue del suscriptor. 32
Ilustración 3-27: diagrama de despliegue. 33
Ilustración 3-28: interfaz de usuario. 33
Ilustración 3-29: diagrama de secuencia de ejecución de la interfaz. 34
Notación
DDS OMG CORBA OSI RTPS QoS
Data Distribution Service Object Management Group
Common Object Request Broker Architecture Open System Interconnection
Real Time Publish Subscribe Quality of Service
RTI DCPS PIM PSM DLRL API
Real-Time Innovations Inc.
Data-Centric Publish Subscribe Platform Independent Model Platform Specific Model
Data Local Reconstruction Layer
Application Programming Interface
1
1 I NTRODUCCIÓN
1.1 Motivación
n el sector de la sanidad la tecnología juega un papel importante. Son numerosas las aplicaciones y dispositivos que participan en procesos sanitarios, como pueden ser escáneres para realizar diferentes tipos de análisis a los pacientes, desfibriladores, ultrasonidos, resonancias magnéticas, monitorización, seguimiento del embarazo… El desarrollo de la tecnología ha favorecido el desarrollo de la medicina.
Respecto a la monitorización de pacientes lo más habitual es que el paciente se controle mediante la medida de una serie de variables que determinan su estado y que el médico y demás personal sanitario que esté interesado en esa información acceda a estos datos a través de monitores u otros dispositivos localizados cerca del paciente. Se trata de un proceso que está acotado en el espacio en el que se desarrolla. Sin embargo cada vez es más habitual encontrar sistemas de monitorización que permiten que los parámetros medidos se puedan consultar de forma remota.
Durante la monitorización el flujo de información generado puede llegar a ser bastante significativo, por lo que filtrar de forma automática esta información para considerar especialmente la más importante y crítica y para generar y manejar las alarmas pertinentes de forma eficaz puede permitir una mayor eficiencia de los sistemas de monitorización.
Sería deseable disponer de un sistema que permita un tratamiento “inteligente” de la información de monitorización, generando alarmas cuando sea necesario e informando de las mismas a los actores pertinentes, a través de las interfaces oportunas. Al mismo tiempo es deseable que este sistema sea robusto, fiable, fácilmente configurable y escalable, todo ello al menor coste posible.
1.2 Objetivo
El propósito principal de este proyecto es el desarrollo de un sistema de gestión de alarmas sanitarias obtenidas a partir de la monitorización de pacientes. Estos pacientes pueden estar en una localización diferente a la del personal encargado de su cuidado, que será el receptor de las alarmas. Además, la localización tanto de los pacientes como del personal sanitario no tiene por qué ser fija.
El sistema debe ser independiente de los dispositivos que utilicen los diferentes actores. En la parte del paciente, encontramos una gran variedad de aparatos para obtener los diferentes valores. Y el cuidador podría recibir las alarmas en el teléfono móvil a través de un mensaje o desde un ordenador recibiendo un correo electrónico o en cualquier otro medio de comunicación imaginable... De esta forma otro requisito será que el sistema sea independiente de la plataforma de los terminales utilizados.
El médico no está interesado en todo momento en toda la información obtenida de la monitorización, sólo en aquella que sea relevante en un instante (y contexto) determinado. Cada actor implicado en el cuidado de un paciente debe poder configurar las alarmas que está interesado en recibir así como el medio por el que desea recibirlas, en función de las características del paciente y del contexto.
Algunas alarmas deben generarse (y tratarse) en tiempo real, ya que pueden referirse a información crítica sobre el estado del paciente y del contexto.
Podemos resumir los objetivos:
· Monitorización de pacientes en tiempo real independientemente de su ubicación.
· Generación de alarmas a partir de la información de monitorización, alertando a los actores
E
Introducción
2implicados en su cuidado independientemente de la ubicación de los mimos.
· Posibilidad de configurar de forma personalizada diferentes tipos de alarmas.
· Independencia de plataformas usadas en la emisión y recepción de la información de monitorización y de las alarmas.
1.3 Metodología
La arquitectura esperada del sistema cumple con las características de un sistema distribuido. Formada por un conjunto de dispositivos, cada uno de ellos diferente desde el punto de vista de hardware y software, que estarán conectados a red para compartir datos.
Además, para cumplir con los objetivos se ha considerado adecuado elegir, de entre las tecnologías disponibles, una que siga el patrón publicador-suscriptor. Este patrón se emplea en aplicaciones software destinadas al intercambio de información entre sus nodos cumpliendo estas características: independencia entre publicador (emisor), suscriptor (receptor) y filtrado de mensajes.
El publicador no sabe ni está interesado en saber dónde y quién recibirá los datos enviados, siendo su tarea principal publicar la información con las características adecuadas (en tiempo, precisión, etc…).
Habitualmente esta información se publica en topics, que son el elemento que hace de unión entre ambos
extremos. Lo definimos como un flujo de datos que pertenecen al mismo tipo. El suscriptor se suscribirá a
ese topic y recibirá los datos publicados en el otro extremo de la comunicación. Existe la posibilidad de
suscribirse aplicando un filtro basado en el contenido del mensaje. De esta manera sólo aquellos datos que
cumplan la condición de filtrado llegarán a ese suscriptor.
3
2 M ETODOLOGÍA
2.1 Patrón Publicador/Suscriptor
El patrón Publicador/Suscriptor [1] es un patrón arquitectónico que destaca principalmente por facilitar la escalabilidad de la red. Es utilizado por las middleware orientadas a mensajes (MOM, Message Oriented Middleware). Los actores que intervienen en el proceso de comunicación son los publicadores, destinados a enviar los datos, y los suscriptores, que los reciben.
La escalabilidad se consigue porque los publicadores y suscriptores son independientes entre sí. Por un lado, un publicador enviará los datos sin saber quién los recibirá, dónde se encuentra ese receptor. El suscriptor se suscribirá a los datos que sean de su interés, recibiendo cada publicación realizada desde ese momento. Ambos actores se desentienden de la topología de la red.
En la suscripción, existe la posibilidad de aplicar filtros. Así, el suscriptor no recibirá la totalidad de mensajes publicados sino aquellos en los que está realmente interesado. Distinguimos dos tipos de filtrado: filtrado por topic y filtrado por contenido. En el primer caso, el suscriptor se suscribirá a un topic, definido como un canal lógico de información. Sólo le llegarán los mensajes que se publiquen en ese topic. Un suscriptor puede suscribirse a los topics que desee. En la otra forma, filtro basado en contenido, el suscriptor podrá establecer condiciones de filtrado que evaluarán el contenido de los mensajes. Si los datos del mensaje cumplen la condición, llegarán a la aplicación suscriptora. Lo más habitual es la combinación del filtrado basado en topic y en contenido.
Un ejemplo simple sería un publicador que envía los valores de la temperatura en una casa. Un suscriptor se suscribe al topic denominado “temperatura” y establece la condición de que la variable del topic temperatura tiene que ser mayor o igual que 30. El publicador envía sucesivas muestras cuyo valor es 25, por lo que el suscriptor no ha recibido nada. A continuación, se envía 26, 27, 28, 29, 30, 31… A partir de 30, los datos llegan a la aplicación receptora (es decir al suscriptor).
2.2 Data Distribution Service
Data Distribution Service (DDS) [2]es un estándar de middleware que sigue el patrón publicador/suscriptor para sistemas distribuidos centrados en datos en tiempo real. Este estándar es mantenido por el Object Management Group.
Antes de detallar DDS, hay que conocer qué es una middleware. Una middleware, o software de intermediación, es un software que se sitúa por encima del sistema operativo utilizado en sistemas distribuidos para facilitar las comunicaciones entre aplicaciones, que pueden ser de diferentes características como sistemas operativos o lenguajes de programación. Para el programador, por tanto, actúa como una capa de abstracción, de forma que éste puede diseñar su aplicación como si los procesos estuvieran corriendo en la misma máquina.
En el caso de DDS, se sitúa entre la capa de red y de aplicación del modelo OSI, simplificando y estandarizando el flujo de datos en sistemas distribuidos en tiempo real y proveyendo comunicaciones robustas y eficientes. Al hablar de aplicaciones distribuidas, por tanto, nos referimos a aquellas que se componen de procesos que interaccionan entre sí comunicándose a través de red. Habitualmente la middleware también provee una serie de servicios adicionales (nombrado, intermediación, persistencia…) que permiten aumentar la transparencia de esta distribución.
Siguiendo el patrón publicador/suscriptor, volvemos a encontrarnos con los conceptos de publicador para
enviar los datos y suscriptor para recibirlos. El topic será el canal en el que se publiquen los datos. De esta
forma, los publicadores publicarán muestras de ese topic y se distribuirán a los diferentes suscriptores que
previamente se han suscrito al topic. Un topic se identifica por un nombre y un tipo. Las aplicaciones
mantienen entre ellas un modelo de datos común, aunque cada una trabaja de forma autónoma.
Metodología
4Ilustración 2-1: primeros conceptos de DDS
Este modelo destaca por desacoplar sus componentes. Desacoplados en el espacio, ya que cada nodo de la red es independiente de los otros; en tiempo, debido a que la recepción de los datos no tiene que estar sincronizada con su escritura; desde el punto de vista de la plataforma, las aplicaciones no se preocupan del hardware, sistema operativo o presentación de los datos en el otro extremo de la comunicación; y de implementación, ya que DDS es un estándar y hay varias implementaciones que pueden operar entre sí. Desacoplando los nodos de la red una de las ventajas directas es la tolerancia a fallos, mejorando respecto al tradicional modelo de tipo cliente/servidor. En actividades críticas como emergencias, transportes o finanzas, es una característica a tener en cuenta. El hecho de que los elementos pueden entrar y salir del dominio en el que actúan en cualquier momento también mejora la escalabilidad del sistema.
Ilustración 2-2: modelo servidor/cliente frente a DDS
DDS proporciona mecanismos para una exhaustiva gestión de QoS, que permite controlar el comportamiento de cada entidad del sistema en aspectos como la duración y persistencia del servicio, presentación de datos, prioridad de envío, fiabilidad, latencia o recursos del sistema, entre otras.
Estas características de DDS hacen que sea factible desarrollar un sistema de alarmas sanitarias entre aplicaciones ejecutándose en múltiples dispositivos heterogéneos.
2.2.1 Especificación DDS
El estándar DDS se divide en dos niveles de interfaces: un primer nivel dedicado a especificar un servicio eficiente de envío de información a los destinatarios adecuados (Data-Centric Publish-Subscribe), y un segundo nivel opcional que tiene el objetivo de integrar el servicio con la capa de aplicación (Data Local Reconstruction Layer).
Data-Centric Publish-Subscribe está formado por la parte independiente de la plataforma (Platform Independent Model) y la parte específica de plataformas CORBA (OMG IDL Platform Specific Model). En el modelo independiente se define el verdadero funcionamiento de DDS: los elementos del sistema, la publicación, recepción, QoS… Mientras que la parte dependiente de la plataforma define la interfaz que la aplicación usará para interactuar con el servicio usando para ello IDL (Interface Description Language), mapeándose PIM a PSM.
El segundo nivel, Data Local Reconstruction Layer (DLRL) también se estructura en dos apartados: DLRL
Platform Independent Model y OMG IDL Platform Specific Model. El objetivo del modelo independiente es
proveer un acceso más directo a los datos intercambiados. DLRL ha sido diseñado para permitir a los
desarrolladores de las aplicaciones usar la mayoría de las funcionalidades que ofrece DLRL. El desarrollador
podrá describir clases de objetos con sus métodos, campos de datos y relaciones; adjuntar los campos de datos
a las entidades DCPS; manipular los objetos usando los constructores que activarán las entidades DCPS
Demostrador para el desarrollo de un sistema distribuido de gestión de alarmas sanitarias sobre el 5 servicio de distribución de datos (DDS)
adjuntas de manera correcta; gestionar esos objetos almacenados en la cache de objetos. Las características del mapeo DCPS-DLRL son las siguientes:
· No debe producirse una duplicación innecesaria de datos.
· El mapeo no debe degradar la eficiencia de una implementación.
· Debe ser flexible, aunque hay casos en los que la flexibilidad no es necesaria y añade información extra. Para esos casos, se define un mapeo por defecto.
Podemos distinguir mapeo de clases, de referencias de objetos, de atributos y de relaciones. DLRL define un conjunto de entidades, como CacheFactory, CacheBase, Cache, ObjectHome…
Respecto al modelo específico de plataforma, provee el mapeo a plataformas CORBA. Se describe a través de constructores IDL que pueden ser usados por la aplicación para interactuar con el servicio. También se especifica cómo la aplicación introduce sus clases y cómo añade indicaciones para generar las entidades DLRL y los constructores mejorados resultantes de aplicación.
DCPS Platform Independent Model
Esta capa es en la que se desarrollan los conceptos principales de la tecnología DDS. Cinco módulos estructuran el modelo: Infraestructure Module, Domain Module, Topic-Definition Module, Publication Module y Subscription Module.
Infraestructure Module: está formado por las clases Entity, DomainEntity, QoSPolicy, Listener, Status, WaitSet, Condition, GuardCondition, StatusCondition. Se trata de clases base para el sistema, de las que heredarán el resto. La clase Entity es la clase base para los elementos DomainParticipant, Topic, Publisher, DataWriter, Subscriber y DataReader. Las entidades soportarán QoSPolicy, Listener y Condition.
DomainEntity también es una clase base para las entidades excepto DomainParticipant, de esta manera se le otorga mayor categoría.
Ilustración 2-3: Infraestructure Module Fuente: OMG
Domain Module: formado por las clases DomainParticipant, DomainParticipantFactory,
DomainParticipantListener. La clase DomainParticipant permite establecer un dominio de comunicación entre
aplicaciones, aislando aquellas que no pertenecen a él. Podemos decir que un dominio es una red virtual entre
aplicaciones que se encuentran en él.
Metodología
6Ilustración 2-4: Domain Module Fuente: OMG
DomainParticipant puede crear y destruir Publisher, Subscriber y Topic. DomainParticipantFactory crea y destruye objetos DomainParticipant. Y DomainParticipantListener es el objeto Listener usado por DomainParticipant.
Topic-Definition Module: compuesto por TopicDescription, Topic, ContentFilteredTopic, MultiTopic,
TopicListener y TypeSupport. La información que identifica un topic permanece en los objetos
TopicDescription. Es una clase padre de Topic, ContentFilteredTopic y MultiTopic.
Demostrador para el desarrollo de un sistema distribuido de gestión de alarmas sanitarias sobre el 7 servicio de distribución de datos (DDS)
Ilustración 2-5: TopicDefinition Module Fuente: OMG
La clase Topic declara los datos de la forma más simple posible para ser publicados o suscritos. La clase ContentFilteredTopic es una especialización de Topic para realizar suscripciones más complejas. Se diferencia respecto a Topic en que lleva asociada una expresión de filtrado que aplicada a los datos hará que suscriptor reciba solo los valores que publicados que cumplan la condición. La otra clase es Multitopic, de carácter opcional. Está destinada al filtrado de los valores publicados provenientes de varios topics. Topic, al ser una entidad, puede tener asociado un objeto Listener, concretamente TopicListener.
Publication Module: formado por Publisher, DataWriter, PublisherListener, DataWriterListener.
Metodología
8Ilustración 2-6: Publication Module Fuente: OMG
El envío de datos se realiza a partir de los métodos de las clases Publisher y DataWriter. El objeto Publisher gestiona la actividad de varios DataWriter y se encarga de la distribución de los datos, y el objeto DataWriter es usado por la aplicación para indicar la presencia de un nuevo dato. El resto de clases son los correspondientes objetos Listener, PublisherListener y DataWriterListener, que más adelante se explicarán.
Subscription Module: formado por Subscriber, DataReader, DataSample, SampleInfo, SubscriberListener,
DataReaderListener, ReadCondition, QueryCondition.
Demostrador para el desarrollo de un sistema distribuido de gestión de alarmas sanitarias sobre el 9 servicio de distribución de datos (DDS)
Ilustración 2-7Suscription Module Fuente: OMG
De la misma forma que la publicación, la suscripción es definida con la asociación de un objeto Subscriber con los objetos DataReader. La entidad Subscriber tiene como finalidad la recepción de los datos publicados en el topic, indicando a la aplicación que los datos están disponibles en el objeto DataReader. El acceso a los datos se realiza a partir de los métodos de la clase DataReader “read”, “read_w_condition”, “take”,
“take_w_condition”. La diferencia entre read y take es que ejecutando read es la middleware la responsable del dato y permanecerá en la cola de recibidos, mientras que con take será responsable la aplicación, eliminándose del objeto DataReader. Si se usa <>_w_condition se estará realizando un filtrado de los datos en función de la condición previamente declarada. Para ello se utilizan las clases ReadCondition y QueryCondition asociándolas al respectivo objeto DataReader.
La clase SampleInfo almacena información identificativa de una muestra de datos. Por ejemplo, indica si la
Metodología
10muestra ha sido accedida o no mediante el método “read”, el estado de la muestra o varios contadores.
Ilustración 2-8: vista general de las clases Fuente: RTI
Respecto a la gestión de la calidad de servicio (QoS), se apoya en políticas individuales (objetos que heredan de QosPolicy). La calidad de servicio puede ser controlada en cada una de las entidades que se encuentran en el sistema (DomainParticipant, Publisher, Subscriber, Topic, DataWriter, DataReader). La calidad de servicio establecida en el lado publicador debe ser compatible con el receptor para desarrollar un envío correcto. DDS comprueba la QoS y la acepta si es válida, en caso contrario mantiene los valores existentes.
Algunos tipos de QoS son DURABILITY, HISTORY, RELIABILITY, DEADLINE, OWNERSHIP…
Por último, tanto Listener como Condition (junto a Wait-set) son dos mecanismos que permiten avisar a la aplicación de cambios de estado relevantes. Los diferentes estados dependen de la entidad, por ejemplo INCONSISTENT_TOPIC para Topic, DATA_ON_READERS para Subscriber o SAMPLE_REJECT para DataReader. Se dividen en dos tipos, Read communication status, grupo al que pertenecen solamente DATA_ON_READERS y DATA_AVAILABLE, y Plain communication statuses para el resto.
Si la aplicación necesita ser avisada de los cambios de estado de una entidad de forma asíncrona, hay que crear un objeto Listener y asociarlo a la entidad. Si se quiere que la aplicación espere a que sucedan cambios de estado, se asocia el objeto StatusCondition a WaitSet y se llama el método de wait() de WaitSet. Se bloqueará hasta que se cumpla la condición asociada o expire el temporizador.
2.3 RTI DDS
El estándar Data Distribution Service es implementado por varios fabricantes: RTI DDS, OpenSplice, tao- dds… Un sistema en el que estén presentes aplicaciones de varios fabricantes funciona de la misma forma que si son del mismo. Esta era una de las ventajas de utilizar el estándar DDS. El sistema de alarmas se ha desarrollado en RTI [3].
RTI implementa el estándar DDS publicador el OMG. Además, incluye algunas características que son extensiones de DDS. Principalmente, existen bastantes políticas de calidad de servicio que no están contempladas por el estándar: DATA_WRITER_PROTOCOL, MULTI_CHANEL, PUBLISH_MODE, TRANSPORT_UNICAST…
A continuación se exponen varios conceptos de esta tecnología para entender mejor el funcionamiento interno.
Envío de datos: el envío de datos puede llevarse a cabo de dos maneras. La primera es siguiendo una política
de best-effort. La red no garantiza que los datos lleguen a su destino. Los usuarios recibirán el mejor servicio
posible en ese momento, en función del estado de la red. Por el contrario, la otra forma de envío es el envío
Demostrador para el desarrollo de un sistema distribuido de gestión de alarmas sanitarias sobre el 11 servicio de distribución de datos (DDS)
fiable. Se garantiza la entrega de las muestras enviadas en el orden previsto. Para ello, se usa el protocolo RTPS (Real-Time Publish-Subscribe).
Este protocolo usa tres tipos de mensajes: datos, heartbeats y ACKNACKs. En los mensajes de datos se envía el valor de los datos transmitidos además de un número de secuencia que lo identifica. Los mensajes de tipo heartbeats indican al receptor los números de secuencia que debe de haber recibido, que responderá con un ACKNACK indicando el siguiente número de secuencia que espera. Tanto en el DataWriter como el DataReader hay una ventana de envío y de recepción, respectivamente. Según los envíos son asentidos se libera espacio de la ventana de envío. En la recepción no se libera el espacio hasta recibir el mensaje heartbeats y comprueba que los números de secuencia recibidos son los especificados.
Persistencia de los datos: existen tres mecanismos para conseguir la persistencia de datos: “durable writer history”, “durable reader state” y “data durability”. El primero, “durable writer history” permite a un DataWriter hacer persistente su historial. El segundo hace persistente el estado de los objetos DataReader recordando qué datos ya han sido recibidos. Por último, “data durability” permite a una aplicación configurar un DataWriter de manera que la información escrita por él persiste más allá de la vida de ese DataWriter. Un objeto DataReader puede suscribirse y recibir la información aunque no se esté ejecutando la aplicación del DataWriter. Para ello es necesario el paquete RTI Persistence Service.
Descubrimiento: cada DomainParticipant guarda información sobre los DataReaders y DataWriters que estén activos en el mismo dominio. Esa información hace posible la comunicación entre DataReader y DataWriter. El descubrimiento se desarrolla en dos fases: Simple Participant Discovery y Simple Endpoint Discovery.
Durante la fase Simple Participant Discovery se utiliza el protocolo Simple Participant Discovery Protocol (SPDP). La información de un DomainParticipant es distribuida a otros DomainParticipants incluyendo un identificador global del Domainparticipant, información sobre direcciones y puertos y QoS. Esta información es reproducida periódicamente para informar de cambios e indicar que está activo.
Para la segunda fase el protocolo usado es Simple Discovery Endpoint Protocol (SDEP). El objetivo es unir DataWriters con DataReaders. Como en la primera parte, hay un intercambio de mensajes hasta que cada DomainParticipant tiene toda la información sobre los participantes del mismo dominio y sus entidades.
Cuando se descubre un DataWriter o DataReader, se determina si la aplicación tiene la pareja. El emparejamiento entre la entidad local y la remota se produce si ambas tienen el mismo Topic, el mismo tipo de datos y políticas de QoS compatibles.
Plugins de Transporte: el núcleo de RTI DDS es independiente del protocolo de transporte utilizado. Utiliza una API para interactuar con los pluggins de transporte que la implementen y que serán encargados de realizar el envío y recepción de los mensajes. Los pluggins UDPv4, UDPv6 y memoria compartida están incluidos.
RTI ofrece una extensión de los pluggins, por ejemplo RTI Secure WAN Transport o RTI TCP Transport.
MultiChannels DataWriters: los DataWriter pueden ser configurados para enviar los datos a direcciones multicast, en función de filtros configurados en ellos. Cada vez que se escribe un nuevo dato, se aplican los filtros y se envía por la dirección multicast que haya cumplido la condición. En la parte receptora, si una aplicación se suscribe aplicando un filtro a un topic, sólo leerá la información en aquella dirección multicast que cumpla su criterio. Si está interesado en todos los datos, se suscribirá al conjunto de direcciones multicast de ese DataWriter. Usando direcciones multicast mejoramos el uso del ancho de banda de la red en situaciones en las que hay varios DataReaders interesados en diferentes subconjuntos de datos que provienen del mismo Topic.
Threading model: RTI utiliza varios hilos para desarrollar sus actividades. Encontramos un hilo dedicado a la base de datos que se crea en cada DomainParticipant. Esta base de datos almacenará información sobre las entidades creadas localmente y aquellas que son descubiertas remotamente. Su función consiste en purgar periódicamente la base de datos.
Otro hilo del sistema es el hilo de eventos. Comprobará periódicamente la condición asociada a un evento o un temporizador y lanzará el evento cuando se cumpla. Sólo maneja un evento en cada momento, por lo que implementa una cola para albergar todos los eventos que esté manejando.
Por último, encontramos los hilos de recepción, cuya misión es procesar los paquetes recibidos por la capa de
transporte. La cantidad de hilos de recepción existentes en un DomainParticipant dependerá de la calidad de
servicio configurada para DataWriter y DataReader y de la implementación del protocolo de transporte.
Metodología
12Gestión de problemas: la gestión de problemas se lleva a cabo a partir de mensajes. Dependiendo de la
configuración seleccionada, variará la cantidad de mensajes emitidos. Los tipos de configuración son, de
menor a mayor cantidad de información: SILENT, ERROR, WARNING, STATUS_LOCAL,
STATUS_REMOTE, STATUS_ALL.
13
3 R ESULTADOS
n este apartado se analiza qué falicidades puede aportar DDS para desarrollar un sistema de gestión de alarmas sanitarias y se realiza una primera implementación, a modo de demostrador, que permite configurar de forma personalizada diferentes tipos de alarmas y generando las alarmas configuradas en tiempo real.
3.1 Análisis de DDS y RTI DDS.
Una vez conocidas las características del estándar del OMG Data Distribution Service y de la implementación de la compañía RTI, es necesario analizar qué pueden aportar al desarrollo de un sistema de alarmas sanitarias.
Como ya sabemos, en un sistema DDS los elementos que se comunican son los publicadores y los suscriptores, relacionados a través de topics. Si identificamos cada elemento en el sistema de alarmas sanitarias, los publicadores serían los dispositivos que recogen y envían los datos de un paciente en una ubicación determinada. Un publicador puede entrar o salir del sistema en el momento que se considere oportuno. Por ejemplo, si se produce la llegada de un nuevo paciente, se encienden sus respectivos dispositivos y comienza la monitorización publicando los datos en los topics de información establecidos.
Desde el otro extremo de la comunicación, los actores implicados podrían suscribirse a los datos que les resulten interesantes, desde un dispositivo y ubicación diferentes. Aprovechando la capacidad de DDS de llevar a cabo una suscripción filtrada se pueden definir (o personalizar) alarmas. No toda la información es relevante en una monitorización para un suscriptor en concreto, las alarmas configuradas le permitirán actuar de la forma más conveniente y efectiva en el instante que sea necesario. DDS permite filtrar la información aplicando la sintaxis SQL utilizada en bases de datos. Prácticamente se cubren todas las necesidades para personalizar alarmas si el suscriptor filtra la información de un topic comparando el valor (o valores) publicado con valores de referencia. Los valores permitidos son ‘>’, ‘<’, ‘>=’, ‘<=’, ‘<>’, ‘=’ y ‘between’ o
‘notBetween’ para indicar rangos. Se pueden anidar varias condiciones con ‘and’ y ‘or’. Por ejemplo, una expresión sería temperatura >=38.5, o variable1>20 and variable2<25. Con la genstión de eventos que realiza DDS se podría, una vez que se ha recibido una muestra que cumple la condición, ejecutar el programa que contiene el protocolo de actuación ante la alarma. Podría ser desde enviar un correo electrónico a activar una señal luminosa o mostrar un mensaje por pantalla.
El uso de dominios en los objetos Participant permite aislar aplicaciones. Las publicaciones realizadas en un dominio concreto solo serán recibidas por los suscriptores que pertenezcan al mismo. De esta manera por ejemplo dos clínicas diferentes pueden utilizar el mismo sistema de alarmas ejecutándolo cada una en un dominio distinto. El dominio es de tipo ‘int’ de 32 bits, por lo que hay un rango de valores bastante amplio.
DDS es configurable gracias a la gestión de QoS que se aplica en cada uno de los objetos definidos. Se conseguiría priorizar el envío de unos datos frente a otros, para aquellas alarmas que fueran más críticas, o establecer el tiempo máximo entre dos envíos, entre otras configuraciones.
Sería interesante desde el punto de vista del personal sanitario conocer los topics disponibles para realizar la suscripción. Puede darse el caso de que un paciente sólo se le controle la respiración, publicando los datos en el topic “respiración”, y otro en estado más crítico que le controlen todas las variables, publicando en el topic
“respiración” y otros más. Esta información puede ser accedida a través de los topics que RTI ofrece para almacenar información de descubrimiento.
RTI ofrece tres topics internos en los cuales se publica la información obtenida en el descubrimiento en los cuales se publica la información obtenida en el descubrimiento de las entidades disponibles en el dominio.
Sería interesante desde el punto de vista del suscriptor conocer qué topics hay en el dominio y poder
E
Resultados
14suscribirse y configurar la alarma en el que más le interese. El sistema sería dinámico y la información se podría cambiar según las necesidades.
Estas características de DDS y su implementación en RTI facilitan el desarrollo de un sistema de aplicaciones distribuidas para la gestión de alarmas sanitarias.
3.2 Caso práctico de alarmas sanitarias
3.2.1 Taxonomía de alarmas sanitarias
Se trata de un resultado interesante ya que resume los tipos de alarmas fundamentales necesarias en una monitorización y cómo pueden ser implementadas de la forma más eficientemente posible usando directamente DDS o DDS y procedimientos adicionales.
TIPO DE ALARMA
DESCRIPCIÓN IMPLEMENTACIÓN EN DDS
EJEMPLO
UMBRAL Alarma generada al comparar el dato recibido con un valor umbral.
Sí, la clase ContentFilteredTopic permite expresiones de filtrado, usando los comparadores “<, <=,
>, >=, <>, =”.
Se reciben muestras de la temperatura de un paciente sólo si la temperatura >39ºC.
RANGO Alarma generada al salir o entrar el dato publicado en un rango de valores dado.
Sí, igual que Alarma Umbral, a través de una expresión de filtrado.
Se reciben muestras de temperatura sólo si hay muestras fuera del rango [35:39].
MEMORIA Alarma generada al comparar el último dato con muestras anteriores y cumplir una diferencia entre ambas.
No. Es necesario un algoritmo que implemente una cola FIFO para almacenar las últimas muestras recibidas.
Se recibe
información sobre la temperatura sólo si hay un aumento de la temperatura de 3 grados en las últimas
5 muestras
publicadas.
KEEPALIVE Alarma generada al no recibir un dato en un periodo de tiempo
Sí. Hay un tipo de QoS, denominada DEADLINE, que establece el tiempo máximo entre muestras enviadas. En el caso de que ese tiempo se supere entre dos envíos, se ejecuta el método
“on_requested_deadline_missed”
del Listener.
Una máquina envía un dato cada 20s, siendo 25s el máximo tiempo entre dos muestras.
El suscriptor es informado si se supera ese tiempo, por ejemplo se ha apagado por una subida de tensión en el edificio.
PERSONALIZADA Alarma
personalizada por una condición, que se
compara con
información
permanente (ej. Base
de Datos).
Complementa a otras
No. Tras recibirse la información sería necesario comprobar si el paciente cumple con la condición impuesta (utilizando los recursos externos a DDS necesarios).
Se genera alarma si la temperatura es mayor de 35ºC y el paciente tiene un tratamiento
intensivo.
Demostrador para el desarrollo de un sistema distribuido de gestión de alarmas sanitarias sobre el 15 servicio de distribución de datos (DDS)
alarmas.
SUMA Se genera alarma si se producen varias alarmas. Pueden ser varias alarmas de los tipos indicados.
Sí. La clase MultiTopic permite expresiones de filtrado que relacionan varios topics.
Se recibe
información sólo si la temperatura es mayor de 30ºC y el nivel de oxígeno mayor de 40mg.
PERSISTENCIA Se genera alarma si se producen varias alarmas consecutivas.
No. Sería necesario implementar un algoritmo que compruebe si el dato recibido (que cumple cierto criterio) es consecutivo respecto al anterior o N valores recibidos en M muestras consecutivas.
Alarma si en dos muestras
consecutivas la temperatura es superior a 40ª o en cinco muestras se producen tres alarmas.
BOTÓN Se genera alarma si se pulsa un botón.
Sí. Al pulsar el botón, se publica en el topic. Al recibir el dato el suscriptor, entiende que han pulsado el botón. El valor publicado no es relevante.
Al pulsar el botón de ayuda de un dispositivo de monitorización, se publica un ‘1’ en el topic y el suscriptor de suscribe a todos los valores ‘1’
publicados.
Tabla 3-1: taxonomía de alarmas
3.2.2 Base del software
Para el desarrollo del sistema de alarmas, se ha usado la librería DDS-Enable Framework, realizada por Alejandro Talaminos de la Universidad de Sevilla sobre RTI. El lenguaje de programación es Java.
Tabla 3-2: capas del sistema de alarmas
Utilizando este Framework se consigue un despliegue rápido de una aplicación DDS con una calidad de servicio por defecto. Las clases que forman el Framework son DataListener, DDS, DeadlineListener, ParticipantFW, PublisherFW, QoS, SubscriberFW, TopicBeanBase, TopicBeanInfo.
A partir de la clase ParticipantFW se crea un participante en un dominio determinado. Esta clase es de tipo Singleton. El participante permite crear los objetos publicador y suscriptor, representados por las clases PublisherFW y SubscriberFW. Para crear un topic con la información de nuestro interés, se crea una nueva clase heredando de TopicBeanBase. En el topic se podrán establecer los filtros a través del método
“addRestriction”. Para generar el listener que tomará el control del programa con la llegada de datos al topic,
Resultados
16se crea otra clase que herede de DataListener. Por último, con el método “write” del publicador se enviarán los datos y con “read” en el suscriptor se recibirán las publicaciones en el topic.
Por ejemplo, para publicar sería:
ParticipantFW participant = new ParticipantFW(1);
PublisherFW pub = participant.createPublisher();
TopicDato topic = new TopicDato();
topic.setDato(2);
pub.write(topic);
Para la suscripción:
ParticipantFW participant = new ParticipantFW(1);
SubscriberFW sub = participant.createSubscriber();
TopicDato topic = new TopicDato();
ListenerDato listener = new ListenerDato();
sub.write(topic,listener);
Thread.sleep(10000);
3.2.3 Especificación de requisitos 3.2.3.1 Introducción
Como aplicación práctica de Data Distribution Service, se ha desarrollado un software de alarmas sanitarias utilizando la librería creada por Alejandro Talaminos [4], que permite un desarrollo más simple sin entrar en configuración de la calidad de servicio, que se establece por defecto. Esto permitirá el intercambio de información entre publicadores y suscriptores desde ubicaciones diferentes.
Se ha definido un escenario de partida, de modo que el software deberá dar soporte a las necesidades de este escenario (recogidas en esta especificación de requisitos), aunque se pretende que éste sirva de referente para la elaboración de escenarios más complejos. Cada paciente dispone de un tensiómetro para medir la tensión arterial, un termómetro para la temperatura, un botón de ayuda para solicitar asistencia y un glucómetro para medir el nivel de glucemia en el caso de que padezcan diabetes. Además, los dispositivos generan mensajes de error en el caso de que se produzca algún fallo técnico en ellos. Esta será la información disponible.
Uno de los objetivos a largo plazo es facilitar a los médicos y demás personal sanitario la configuración de alarmas. En este proyecto se ha realizado un ensayo con la creación de una GUI sencilla que permite la configuración de alarmas de tipo; Ayuda asociada al topic Ayuda, Error para el topic Error y alarma Umbral, Rango y Memoria para los topics Temperatura, Glucemia Y Tensión Arterial.
3.2.3.2 Catálogo de Requisitos Generales
Req01 Desarrollo de Alarma Umbral
Versión <1.0> 26/06/2014
Dependencias
Descripción La Alarma Umbral permite filtrar información que sea mayor, menor, distinta o igual que un determinado umbral.
Importancia Alta
Demostrador para el desarrollo de un sistema distribuido de gestión de alarmas sanitarias sobre el 17 servicio de distribución de datos (DDS)
Estado Completado
Comentarios Se puede seleccionar el topic en el que se aplica.
Tabla 3-3: Req01 Desarrollo de Alarma Umbral
Req02 Desarrollo Alarma Rango
Versión <1.0> 26/06/2014
Dependencias
Descripción La Alarma Rango permite filtrar información que esté fuera o dentro de un rango establecido por un valor mínimo y máximo.
Importancia Alta
Estado Completado
Comentarios Se puede seleccionar el topic en el que se aplica.
Tabla 3-4: Req02 Desarrollo de Alarma Rango
Req03 Desarrollo Alarma Memoria
Versión <1.0> 26/06/2014
Dependencias
Descripción La alarma memoria guarda un determinado número de muestras y comprueba la diferencia entre la primera y la última para observar la evolución de los valores.
Importancia Alta
Estado Completado
Comentarios Se puede seleccionar el topic en el que se aplica.
Tabla 3-5: Req03 Desarrollo Alarma Memoria
Req04 Desarrollo Alarma Personalizada
Versión <1.0> 26/06/2014
Dependencias Req01, Req02, Req03
Resultados
18Descripción La alarma personalizada complementa las alarmas anteriores con una condición almacenada en una base de datos de pacientes.
En el caso de que la condición establecida de personalización sea igual a la almacenada en la base de datos de pacientes, hay alarma.
Importancia Alta
Estado Completado
Comentarios Se complementa con las alarmas Umbral, Rango y Memoria
Tabla 3-6: Req04 Desarrollo alarma Personalizada
Req05 Alarma Persistencia
Versión <1.0> 26/06/2014
Dependencias Req01, Req02
Descripción Si se producen dos alarmas consecutivas o tres en cinco alarmas consecutivas, se genera la alarma de persistencia.
Importancia Alta
Estado Completado
Comentarios
Tabla 3-7: Req05 Alarma Persistencia
Req06 Alarma Error
Versión <1.0> 26/06/2014
Dependencias
Descripción Recepción de los mensajes de error de los dispositivos.
Importancia Alta
Estado Completado
Comentarios
Tabla 3-8: Req06 Alarma Error
Req07 Información de monitorización
Demostrador para el desarrollo de un sistema distribuido de gestión de alarmas sanitarias sobre el 19 servicio de distribución de datos (DDS)
Versión <1.0> 26/06/2014
Dependencias
Descripción La información necesaria en el sistema será la temperatura, glucemia, tensión arterial, pulsado del botón de ayuda y mensajes de error de los dispositivos.
Importancia Alta
Estado Completado
Comentarios
Tabla 3-9: Req07 Información de monitorización
Req08 Mensaje de Alerta
Versión <1.0> 26/06/2014
Dependencias
Descripción Cuando se detecte una alarma, se mostrará un mensaje por pantalla indicándolo.
Importancia Alta
Estado Completado
Comentarios
Tabla 3-10: Req08 Mensaje de Alerta
Resultados
203.2.3.3 Diagramas de Casos de Uso
Ilustración 3-1: Diagrama de Casos de Uso
3.2.3.4 Diagramas de Casos de Uso: descripción de los actores
Actor01 Paciente
Versión <1.0> 26/06/2014
Dependencias
Descripción El paciente es el actor encargado de la publicación de los datos de monitorización a través de los dispositivos adecuados.
Comentarios
Ilustración 3-2: Paciente
Demostrador para el desarrollo de un sistema distribuido de gestión de alarmas sanitarias sobre el 21 servicio de distribución de datos (DDS)
Actor02 Personal sanitario.
Versión <1.0> 26/06/2014
Dependencias
Descripción El personal sanitario estará a cargo del cuidado de los pacientes, y podrá establecer las alarmas según sus objetivos.
Comentarios
Ilustración 3-3: Personal Sanitario
Actor03 Técnico
Versión <1.0> 26/06/2014
Dependencias
Descripción El técnico es el encargado de leer los mensajes de error publicados por los dispositivos y dar soporte a éstos. También podrá acceder a las configuraciones del resto de alarmas, aunque no sea de su interés.
Comentarios
Ilustración 3-4: Técnico
3.2.3.5 Diagramas de Casos de Uso: Especificación de Casos de Uso
CasoDeUso01 Registrar usuario en el sistema
Versión <1.0> 26/06/2014
Dependencias Precondición
Descripción El sistema debe estar restringido para que no todo el mundo pueda entrar.
PostCondición
Importancia Media
Estado No se ha implementado en la aplicación.
Comentarios
Ilustración 3-5: Registrar usuario en el sistema.
Resultados
22CasoDeUso02 Acceso al sistema (Autenticación)
Versión <1.0> 26/06/2014
Dependencias
Precondición CasoDeUso01 Registro
Descripción Un usuario registrado debe autenticarse para entrar en el sistema.
PostCondición
Importancia Media
Estado No se ha implementado en la aplicación.0 Comentarios
Ilustración 3-6: Acceso al sistema.
CasoDeUso03 Arrancar el sistema
Versión <1.0> 26/06/2014
Dependencias
Precondición CasoDeUso02 Autenticación
Descripción El usuario debe arrancar el sistema indicando el dominio en el que se encuentra la información y el tiempo que estará el sistema leyendo información.
PostCondición
Importancia Media
Estado Implementado
Comentarios Una línea de mejora sería eliminar ese tiempo.
Ilustración 3-7: Arrancar el sistema.
CasoDeUso04 Establecer Alarma Error
Versión <1.0> 26/06/2014
Dependencias
Precondición CasoDeUso04 Arrancar sistema
Descripción Al generar una Alarma Error se recibirán todos
los mensajes de error publicados en el topic
Demostrador para el desarrollo de un sistema distribuido de gestión de alarmas sanitarias sobre el 23 servicio de distribución de datos (DDS)
destinado a ello.
PostCondición
Importancia Alta
Estado Completado
Comentarios
Ilustración 3-8: Establecer Alarma Error.
CasoDeUso05 Establecer Alarma Ayuda
Versión <1.0> 26/06/2014
Dependencias Req01: alarma Umbral. Una Alarma Ayuda consiste en pulsar el botón de ayuda. Se implementa a través de una alarma umbral donde la condición de filtrado es boton = 1. Al pulsar el botón se publica valor ‘1’.
Precondición CasoDeUso04 Arrancar sistema
Descripción Al generar una Alarma Ayuda, se genera una alarma cada vez que el paciente pulsa el botón de ayuda.
PostCondición
Importancia Alta
Estado Completado
Comentarios
Ilustración 3-9: Establecer Alarma Ayuda.
CasoDeUso06 Establecer Alarma Umbral
Versión <1.0> 26/06/2014
Dependencias
Precondición CasoDeUso04 Arrancar sistema
Descripción La alarma rango se lanza si los datos recibidos cumplen el patrón basado en comparar el dato con un determinado rango (<,>,igual, distinto que el rango).
PostCondición
Importancia Alta
Resultados
24Estado Completado
Comentarios
Ilustración 3-10: Establecer Alarma Umbral.
CasoDeUso08 Establecer Alarma Personalizada
Versión <1.0> 26/06/2014
Dependencias
Precondición CasoDeUso05, CasoDeUso06, CasoDeUso07 Descripción Se le añade a la alarma una condición de
personalización, que se comparará con la información del paciente almacenada en la base de datos. Si son los mismos, se genera la alarma.
PostCondición
Importancia Alta
Estado Completado
Comentarios
Ilustración 3-11: Establecer Alarma Personalizada.
CasoDeUso09 Establecer Alarma Persistencia
Versión <1.0> 26/06/2014
Dependencias
Precondición CasoDeUso05, CasoDeUso06, CasoDeUso07 Descripción Al establecer una Alarma Persistencia, se
genera alarma si las alarmas indicadas en Precondición se producen dos veces consecutivas o tres veces de cinco consecutivas.
PostCondición
Importancia Alta
Estado Completado
Comentarios
Ilustración 3-12: Establecer Alarma Persitencia.
Demostrador para el desarrollo de un sistema distribuido de gestión de alarmas sanitarias sobre el 25 servicio de distribución de datos (DDS)
CasoDeUso10 Iniciar Lectura de Datos
Versión <1.0> 26/06/2014
Dependencias
Precondición CasoDeUso04 Arrancar sistema
Descripción Se inicia la lectura de los datos en los topics correspondientes.
PostCondición
Importancia Alta
Estado Completado
Comentarios
Ilustración 3-13: Iniciar Lectura de datos.
3.2.3.6 Requisitos de información del sistema
Req09 Información permanente de los pacientes.
Versión <1.0> 26/06/2014
Dependencias Req04, CasoDeUso08
Descripción Para la condición de personalización, es necesaria una Base de Datos con información permanente sobre los pacientes.
Datos específicos Algunos campos de la base de datos deben ser el nombre, el estado del paciente y el tratamiento que sigue.
Importancia Alta
Estado Simulado
Comentarios Se ha simulado una base de datos, en el sistema final debería ser un elemento externo.
Ilustración 3-14: Información permanente de pacientes.
3.2.3.7 Requisitos de fiabilidad del sistema.
Req10 Fiabilidad
Versión <1.0> 26/06/2014
Dependencias
Resultados
26Precondición
Descripción La información es muy importante al estar en juego la salud de los pacientes. Por lo tanto el envío de paquetes debe ser fiable configurable en la QoS.
Postcondición
Importancia Alta
Estado Según la configuración de las bibliotecas usadas: QoS por defecto utilizando envío fiable.
Comentarios
Ilustración 3-15: Fiabilidad.
3.2.3.8 Requisitos de Usabilidad
Req11 Interfaz de usuario
Versión <1.0> 26/06/2014
Dependencias Precondición
Descripción Los actores Personal Sanitario y Técnico necesitan un acceso al sistema de alarmas a través de una interfaz en la que por medio de botones y campos de texto se configuren las alarmas.
PostCondición
Importancia Alta
Estado Completado
Comentarios
Ilustración 3-16: Usabilidad.
3.2.3.9 Requisitos de mantenibilidad
Req12 Nuevos Topics en el futuro
Versión <1.0> 26/06/2014
Dependencias Req07
Precondición
Descripción La información que es monitorizada en el
Demostrador para el desarrollo de un sistema distribuido de gestión de alarmas sanitarias sobre el 27 servicio de distribución de datos (DDS)
sistema puede ser aumentada en el futuro ya que las alarmas no se limitan a un determinado topic si no que son configurables.
PostCondición
Importancia Media
Estado
Comentarios No es un requisito totalmente objetivo.
Ilustración 3-17: mantenibilidad.
3.2.3.10 Requisitos de seguridad
Req13 Autenticación en el sistema
Versión <1.0> 26/06/2014
Dependencias
Descripción El sistema debe estar restringido a aquellos actores que tengan permisos para acceder a la información de los pacientes y generar alarmas.
Es necesario autenticación
Importancia Media
Estado No realizado.
Comentarios
Ilustración 3-18: seguridad.
3.2.4 Diseño de la solución para el suscriptor de alarmas
El sistema de alarmas está formado por un conjunto de clases, las cuales se dividen en los paquetes
“gestorAlarmas”, “alarmas”, “listeners” y “herramientas”. A continuación se representan todas las clases y diferentes paquetes.
Ilustración 3-19: diagrama de paquetes.
Resultados
28Ilustración 3-20: diagrama de clases del paquete gestorAlarmas.
Demostrador para el desarrollo de un sistema distribuido de gestión de alarmas sanitarias sobre el 29 servicio de distribución de datos (DDS)
Ilustración 3-21: diagrama de clases del paquete alarmas.
Resultados
30Ilustración 3-22: diagrama de clases del paquete listeners.
Las clases del paquete listeners ejecutan el método on_data_available cuando se produce la llegada de una nueva publicación en el topic. Este método se sobreescribe para conseguir la funcionalidad deseada.
Las clases ListenerAyuda, ListenerGlucemia, ListenerTension y ListenerNumber ejecutan el algoritmo de la
figura 3-23 al recibir un nuevo dato.
Demostrador para el desarrollo de un sistema distribuido de gestión de alarmas sanitarias sobre el 31 servicio de distribución de datos (DDS)
Ilustración 3-23: secuencia del método on_data_available en las clases ListenerXXXX
Las clases ListenerMemoriaTemperatura, ListenerMemoriaGlucemia, ListenerMemoriaTension y ListenerNumber actúan según el diagrama de la figura 3-24.
Ilustración 3-24: secuencia del método on_data_available en las clases ListenerMemoriaXXXX
Resultados
32Ilustración 3-25: diagrama de clases del paquete topics.
El despliegue del sistema suscriptor de alarmas en un dispositivo sigue el siguiente esquema.
Ilustración 3-26: despliegue del suscriptor.
