Proyecto Fin de Carrera

Transcripción

1 Proyecto Fin de Carrera E.T.S.I. de Informática I.T.I de Sistemas Universidad de Málaga Autora: María José Morón Fernández Directores: D. José María Álvarez Palomo D. Eduardo Casilari Pérez 1

2 1. Introducción 2. Metodología Proceso Unificado: Particularización 3. Diseño e implementación 4. Pruebas realizadas 5. Conclusiones y Líneas futuras 2

3 Introducción Bluetooth Nodo de Control GPRS/ UMTS OBJETIVO: Desarrollar un prototipo de un sistema de Telemonitorización Inalámbrico de Pulsioximetría (TeMiP) Personal de Asistencia Internet Aplicación de Control y Monitorización Pulsioxímetro Bluetooth WLAN WPAN Nodo de Control: NC Servidor de Control Central: SCC Aplicación de Control y Monitorización: ACM Servidor de Control Central Centro Hospitalario 3

5 Metodología Proceso Unificado: Introducción Fuente: I. Jacobson, G. Booch, y J. Rumbaugh. The Unified Software Development Process. Addison-Wesley Professional, February

6 1. Fase INICIAL: Metodología Proceso Unificado: Particularización (I) Flujo de trabajo de Requisitos: En una versión inicial del DGR: Se ha descrito el problema a resolver y, también el producto. Se ha descrito el perfil de usuario y su entorno, especificando dos modos de funcionamiento: Modo remoto Modo local Se han identificado requisitos funcionales y no funcionales Se ha esbozado el modelo de casos de uso, completado en la fase de elaboración. Flujo de trabajo de Diseño: Se ha definido la arquitectura candidata, especificando los principales subsistemas y las interfaces Se ha refinado el DGR, incluyendo una descripción del entorno de despliegue 6

7 Metodología Proceso Unificado: Particularización (II) Interfaz Tecnología de Comunicación Protocolo de Comunicación Pulsioxímetro Nodo de Control Bluetooth RFCOMM Nodo de Control Servidor Remoto / GPRS / UMTS HTTP Servidor Remoto Aplic. Consulta / Ethernet HTTP 7

8 Metodología Proceso Unificado: Particularización (III) 2. Fase de ELABORACIÓN: Flujo de trabajo de Requisitos: Se han detallado los casos de uso, utilizando diagramas de interacción e identificando relaciones entre ellos Flujo de trabajo de Diseño: Se ha refinado la arquitectura: SCC: Integrado por dos componentes web, comunicados por JMS ACM: Implementada como un Applet Flujo de trabajo de Implementación y Prueba: Obtención de la línea base de la arquitectura: 1ª iteración: Requisitos funcionales del componente «NC» asociados al «Modo Local» 2ª iteración: Transmisión de datos al servidor 3ª iteración: Consulta de datos desde la aplicación «ACM» 8

9 Metodología Proceso Unificado: Particularización (IV) 3. Fase de CONSTRUCCIÓN: Flujo de trabajo de Requisitos: Revisión de los requisitos de la aplicación «ACM» GUI prevista en la fase anterior no adecuada. Flujo de trabajo de Diseño: Modificación del diseño de la GUI de aplicación «ACM»: Applet JWS. Flujo de trabajo de Implementación y Prueba: Funcionalidad requerida para: 1ª iteración: Configuración de parámetros desde la aplicación «ACM». 2ª iteración: Monitorización / Control de todos los pacientes conectados. 3ª iteración: Esta última iteración se ha limitado a: Mejorar la GUI de la aplicación «ACM» Optimizar la comunicación «NC» «NC-SCC» 4. Fase de Transición: No aplicable 9

11 TeMiP: Arquitectura Nodo de Control: MIDLET «NC» Aplicación de Control y Monitorización: Aplicación JWS Servidor de Control Central: Una aplicación J2EE 1.4 de dos niveles (two-tier): Nivel de cliente J2EE, en el que se ha ensamblado la aplicación JWS desarrollada para el subsistema «ACM» Nivel de componentes web: Dos servlets: comunicados mediante JMS: modelo Pub/Sub. «NC-SCC» y «ACM-SCC» 11

12 TeMiP: Funcionamiento NC NC-SCC ACM-SCC JWS-ACM HTTP-POST(Id Paciente, Id Sensor, Mode, Data) HTTP OK Publica TeMiP Topic Lee HTTP-GET(, Data Req) HTTP OK (Objeto «Mode») HTTP-POST(Id Paciente, Id Sensor, Mode, Data) HTTP OK (Cmd) HTTP-GET(Id Paciente, Cmd Req) Publica TeMiP Topic HTTP-GET(Id Paciente, Cmd Req) 12

13 Nodo de Control 13

14 Servidor de Control Central (I) NC-SCC acm_scc ACMServlet datanonin4100 Mode ACM-SCC ReaderJMS Mode1 Mode2 14

15 Aplicación JWS de Control y Monitorización 15

17 Subsistema «NC»: Paquete «bluetoothcomm»: Pruebas de Funcionamiento (I) Búsqueda de dispositivos con éxito. Fallo en la búsqueda de dispositivos. Establecimiento de la conexión con éxito. Fallo en el establecimiento de la conexión: Fallo en el establecimiento de la conexión: Dispositivo real: Clave incorrecta. Emulador del dispositivo: Servicio SPP no registrado. Cancelación del establecimiento de la conexión. Transmisión y recepción de vectores de bytes y de cadenas. Liberación de la conexión Bluetooth. Detección de la pérdida de la conexión Bluetooth. 17

18 Subsistema «NC»: Pruebas de Funcionamiento (II) Paquetes «nonin4100», «decodedatanonin4100» y «datanonin4100»: Configuración del modo de funcionamiento del dispositivo. Recepción y decodificación de datos. «Modo Local»: Cancelación del establecimiento de la conexión. Reconfiguración del modo de funcionamiento del pulsioxímetro. Cancelación de un procedimiento de reconfiguración. Subsistema «SCC»: El procesamiento de las peticiones HTTP GET y POST recibidas. El sistema de mensajería JMS. 18

19 Subsistemas «NC» «SCC»: Pruebas de Integración Conectividad: El punto de acceso predefinido no está disponible El S.O solicita al usuario que seleccione otro El servidor no está inicialmente disponible o se interrumpe la conexión durante la transferencia de datos Alerta de ERROR Transmisión de datos desde el «NC» al «SCC»: Transmitiendo una única trama en una petición HTTP POST Encapsulando en una petición HTTP POST todas las tramas almacenadas en el buffer Transmisión de comandos desde el «SCC» al «NC»: Modo de operación del pulsioxímetro: M1 M2, M2 M1 Periodo de transmisión: continuo 5 s 10 s, 10 s 5 s continuo. Subsistemas «ACM» «SCC» Subsistemas «NC» «SCC» «ACM» 19

20 Pruebas de Consumo (I) t = V max V min Δt Modo V max : 4,07 V V min : 3,58 V Tasa de Descarga ΔV (μv / s) Duración t (horas) Local: Sin la comunicación GSM activada 12,0 11,34 Local: Con la comunicación GSM activada 14,7 9,25 Remoto: Transmisión continua 57,4 2,37 Remoto: Transmisión periódica cada 10 s 51,0 2,67 Remoto: Transmisión continua con vaciado de buffer Remoto: Transmisión periódica cada 10 s con vaciado buffer 50,7 2,68 14,7 9,25 20

21 Modo Remoto: T =10 s Pruebas de Consumo (II) 4.1 Tasa de descarga respecto al tiempo (s) (ajuste mínimo!cuadrático) Y = 4,04! 5,10e!05X 4.1 Tasa de descarga respecto al tiempo (s) (ajuste mínimo!cuadrático) Y = 4,09! 1,47e!05X 4 2,67h ,25 h Voltaje (V) Voltaje (V) Tiempo (s) Tiempo (s) Sin vaciado de buffer Con vaciado de buffer Encapsulando todas las tramas almacenadas en el buffer en una única petición POST se logra una autonomía del mismo orden que la obtenida para el «Modo Local» con la comunicación GSM activada. 21

22 Pruebas de Rendimiento: Monitorización de 2 pacientes Modo Remoto: Transmisión continua!%#""?!@!$'&a!b!"a""cdce )*+,-.!5+!74890:+4+9;*8!/;.9!8<607+!,=9*,.!;6854>7*;.1!'%"" >!?!'&$@!A!"@""$$BC ()*+,-!4*!6378/9*3*8:)7!!.:-8!7;5/6*!+<8)+-!:5743=6):-0!'$""!%"""!'#"" )*+,-.!/,01!$#""!$""" ()*+,-!.+/0!'"""!&""!%""!$""!#""!#""!"!"!%"""!&"""!'"""!("""!$""""!$%""" 23,+4.!5+!, Paciente 1!"!"!#"""!$"""!%"""!&"""!'""""!'#""" 12+*3-!4*!+5*/637 Paciente 2 Tiempo transcurrido desde que la clase «NoninManager» del SCC publica el objeto de la clase «Mode2» hasta que la clase «CtrlPatient» lo obtiene para actualizar la vista correspondiente 22

24 Conclusiones (I) 1. Objetivo: Desarrollar un prototipo de un sistema de Telemonitorización Inalámbrico de Pulsioximetría (TeMiP), basado en una red WPAN Bluetooth: Red WPAN: Pulsioxímetro Bluetooth y un smartphone: Aplicación J2ME, «NC»: coordina la red WPAN, proporcionando dos modos de: Local y Remoto. Servidor SCC: Dos servlets «NC-SCC» y «ACM-SCC» comunicados mediante JMS: modelo Pub/Sub: Permite que, aunque la aplicación web no esté activa, no se pierden los datos que el componente «NC» esté retransmitiendo al servidor. Aplicación de Control y Monitorización: Aplicación JWS: Descarga e instala automáticamente la versión de la plataforma Java requerida, evitando conflictos con otras aplicaciones. Posibilidad de ejecución fuera del ámbito del navegador. Varias ventanas abiertas: una por cada uno de los pacientes monitorizados. 24

25 2. Metodología Proceso Unificado: Idónea para la construcción de este tipo de sistemas por su naturaleza iterativa /incremental. 3. Aplicación de patrones de diseño: MVC y STATE: Implementación más simple La legibilidad del código La simplificación de la labor de documentación Conclusiones (II) 4. Pruebas de consumo: En un terminal Nokia N95, se alcanza una autonomía de 9,25 h: T=10 s. Encapsulando en una única petición HTTP todos los paquetes acumulados en el buffer. 5. Pruebas de rendimiento: Un único destino (Topic), compartido por dos pacientes el retardo de transmisión extremo a extremo. 25

26 1. Integrar en la red WPAN más sensores biomédicos. 2. Enviar al servidor información de localización. 3. Añadir un modo de funcionamiento: «Modo Vigilancia». Líneas futuras 4. En «Modo Remoto», si se interrumpe la comunicación con el servidor: Conmutar a «Modo Local» y almacenar los datos. Al iniciar la aplicación: Transmitir los datos pendientes de envío. 5. Iniciar la aplicación «NC» de forma remota, por ejemplo, en respuesta a la recepción de un mensaje SMS. 6. Transferir la información comprimida y cifrada entre el servidor y la aplicación de monitorización. 7. Emplear un destino (Topic) por cada uno de los pacientes. 26

27 Proyecto Fin de Carrera E.T.S.I. de Informática I.T.I de Sistemas Universidad de Málaga Autora: María José Morón Fernández Directores: D. José María Álvarez Palomo D. Eduardo Casilari Pérez 27